On Mon, Feb 26, 2018 at 12:19 PM, Viktor Dukhovni <vik...@dukhovni.org> wrote: > > 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.
Viktor, Is this a new realization you've recently arrived at? You've been commenting on this draft for a number of years now, and I have assumed that you were well aware of the lack of authenticated denial. In fact, there is text in the Intro section that declares that this protocol is unsuitable for SMTP/DANE precisely because it requires confirmation of the existence or not of the TLSA record - that text came about because of discussion with you. Several of us were well aware of this during the early days of the draft, but perhaps many folks did not fully appreciate the impacts until I elaborated on them last year, and added text that described the "adversary with fraudulently obtained PKIX credentials" attack. It is certainly a limitation/flaw. Whether or not it is fatal is debatable. What this means is that this protocol allows opportunistic use of DANE authentication, but guarantee of use needs mechanisms external to the protocol. Section 8 already describes several such mechanisms that could be employed. So, I think this topic is covered. This limitation also may not be applicable at all for green field TLS/DNSSEC applications that can require the use of the extension unconditionally. Having an authenticated denial mechanism would allow the TLS client to have an inband way to enforce DANE authentication if available. I suspect though that re-introducing a debate on this topic will lead us into an argument about what it means for a server to publish a TLSA record. Is it just a mechanism to use the DNSSEC to authenticate keys and certificates? Or is it also a policy signal that says DANE must be used? I do not think the latter idea has any consensus in the IETF currently. > 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. This is a rather substantial change proposal. It's worth considering, but I'd like to hear others chime in. But as I said, there are ways to use this spec and address some of the limitations outside the protocol today - you can cache and pin knowledge of TLSA existence, even without an in-protocol commitment, although the latter would be better. That may be good enough for the first iteration of the protocol. Note that extending the protocol to incorporate authenticated denial also means that the chain data would likey need a DNS response code. That's a stronger argument to move to a full DNS message format (I'll answer Paul Wouter's specific comments on that topic separately later). Shumon.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
