On 02/26/2018 11:20 AM, Viktor Dukhovni wrote: > >> On Feb 26, 2018, at 9:26 AM, Paul Wouters <p...@nohats.ca> 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.
It of course would not be a fatal flaw if the document was targeting Experimental status, but I do not have the sense that the authors wish to make that switch. > 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). There doesn't seem to be much interest in pinning-like schemes for TLS at this point (see also the "TLS server identity pinning" proposal from the SAAG/secdispatch session at IETF 100). And I do think the lack of authenticated denial of existence is something the WG was aware of during our earlier discussions, so it's unclear that there is a need to hold things up for this issue. -Benjamin > 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. > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
