Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

[Viktor Dukhovni <[e-mail]>]

> On Feb 26, 2018, at 9:26 AM, Paul Wouters <[e-mail]> wrote:
> 
> So it was decided to not use a full DNS packet format? And then since you
> miss the structure of the Answer Section and Additional/Authority
> Section, you require the "answer RR's" come first where you basically
> emulate an Answer Section?
> 
> Isn't that an indication that we should really use the wireformat of an
> entire DNS message here? Maybe some DNS library/tools people can chime
> in here to tell us if this matters much to them (assuming they are
> adding support for creating/consuming these chains of RRsets in wire
> format.
> 
> I am personally a little sad we cannot have a dig +chainquery command
> where we write out the entire answer packet format to a blob, to be loaded by
> the TLS server. And where a TLS client cannot just hand over the blob
> "as if it came in as a reply from a DNS server" to its DNS/cache
> receiving code path.

The latter would require compression support on the receiving side, which
has been specifically excluded so far.  I am not against making the data
more compact, though it is rather late in the process, but I have a more
pressing issue.

I think that as it stands, lack of authenticated denial of existence is
a *fatal* flaw in the protocol.  I just don't see a sufficiently practical
scenario in which this extension confers a useful security benefit.

Perhaps this draft should go back to the working group, to consider a new
protocol element, by which the server commits to support the extension for
a time that is substantially longer than the underlying DNS TTLs.  During
this time (suggested to be weeks or months, when in production after initial
testing), the server MUST support the extension and respond with EITHER a
valid TLSA RRset chain, or with a valid denial of existence.

The protocol, thus extended, can then be seen as a more robust form of key
pinning, in which pins are stored server-side, and only the fact that
pinning is expected is stored client-side (for any length of time, the
client may still do short-term caching of TLSA RRs based on the DNS TTL).

The protocol is still subject to downgrade (to PKIX) on first contact,
but is this a common element of all protocols that bootstrap security
on first use.  Indeed the WebPKI itself is largely TOFU as most certs
(which are predominantly DV certs) are issued by CAs based on rather
weak initial evidence.

-- 
	Viktor.



-- 
	Viktor.