Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

[Viktor Dukhovni <[e-mail]>]

> On Nov 5, 2018, at 8:01 AM, Benjamin Kaduk <[e-mail]> wrote:
> 
> Once we start talking about pinning of any sort, we move from this
> extension just being "transport some DNS records" into conveying some
> sort of additional semantics.

Transporting some bits *always* carries additional semantics, otherwise
why carry the bits.  For example, already in -07 there is clear text
specifying that the transported records can be cached for their DNS TTL,
and that once delivered DANE records should not be ignored on failure.

   https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07#section-6

   A TLS client making use of this specification, and which receives a
   DNSSEC authentication chain extension from a server, MUST use this
   information to perform DANE authentication of the server.  In order
   to do this, it uses the mechanism specified by the DNSSEC protocol
   [RFC4035] [RFC5155].  This mechanism is sometimes implemented in a
   DNSSEC validation engine or library.

   Clients MAY cache the server's validated TLSA RRset or other
   validated portions of the chain as an optimization to save signature
   verification work for future connections.  The period of such caching
   MUST NOT exceed the TTL associated with those records.  A client that
   possesses a validated and unexpired TLSA RRset or the full chain in
   its cache does not need to send the dnssec_chain extension for
   subsequent connections to the same TLS server.  It can use the cached
   information to perform DANE authentication.

That rather looks like semantics to me, much more than transport some bits.

> It seems that we have not really had a structured discussion about what
> semantics and information flows we might or might not want to convey in
> this extension (in one or both directions!), and I'm reluctant to consider
> adding such semantics without such a discussion.

I really don't think that at this juncture it is productive to wipe the
slate clean and consider all possible proposals, even ones that nobody
has put forward as yet.  Why would we want to do that.  There is clearly
just one primary contentious issue to resolve, and I rather think your
train of thought is a distraction from the issue at hand.

> If we accept the premise that the intention of DANE as relevant in this
> space is to allow the server to convey to the client the server's
> preferences for how the client should authenticate the server, we may also
> want to consider the case where a server operator wants to eventually get
> to a DANE-only state where it can ignore the web PKI.

Nobody is looking for this.  There's no point.  WebPKI certificates are
free (and worth every penny).  DANE adoption is far too light to even
begin to contemplate abandoning WebPKI, and we're probably two decades
away from being able to do that, by which point the quantum computer
apocalypse may have made many of the current designs moot.

> (There may not be
> many or any servers that actually end up wanting to do this, but it's not
> unreasonable to consider the possibility.)

It seems unreasonable to me, because no such signalling was for example
proposed for raw public keys or various PSK methods, etc.  And of course
the server operator can log the use of the extension and draw conclusions
about client support based on that, and the overall technology landscape.
There's no need to include this in the discussion.

> Similarly, the server may want to indicate things like:
> 
> (a) the server wants to be authenticated via DANE (yes, this is just the
>    contents of the DNS)

And any client with a decent network environment can just query the
DNS directly, and never use the extension and have the record hot
in the local cache.  So there's no need for anything to complicated
here.  We just need to provide as much of the downgrade-resistance
that DNSSEC gives automatically, also to clients that for some time
will be able to do DNSSEC.

> I deliberately am not trying to come to a conclusion in this message, as I
> am not confident that I have even come up with all the potential semantics
> worth thinking about, and I think that any motion in this space should only
> be taken with WG consensus.

I think at this point hypothetical semantics is not a helpful direction.
If you have a concrete proposal, that has merit in addition to or in
place of what has been proposed, please explain.  If there are problems
or lack of clarity with what has been proposed, please explain.

I very much fear that the only possible outcome of sky's-the-limit
brainstorming is paralysis.  Please try and focus on actual proposals.

> I would love to hear others' thoughts on what I am missing from the above
> lists, reasoning for/against including protocol elements to indicate
> the listed semantics, and whether/which existing protocol elements already
> convey which of the enumerated semantics.

The proposal on the table is to a minimal form of time-limited commitment
to the extension by mutual agreement between client and server, to address
downgrade attacks via extension stripping by attackers with unauthorised
WebPKI credentials.  This is need because while DNS lookups either deliver
the relevant DNSSEC data or clearly fail, the extension is optional and
failure to deliver it is a-priori not in any way anomalous.

We're just trying to address that gap.  If you can make a strong case
for addressing some additional gaps, or addressing this gap in a better
way, please do.  Once again, I'm very concerned that the direction you're
setting out on is counter-productive.

-- 
	Viktor.