Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

[Shumon Huque <[e-mail]>]

On Thu, Feb 22, 2018 at 12:21 PM, Viktor Dukhovni <[e-mail]>
wrote:
>
>
> My comments are less about middleboxes (TLS-terminating corporate
> proxies trusted by the user's browser) and more about unwanted
> active MiTM attacks.  If the MiTM attacker has obtained WebPKI
> (PKIX) certificates for the destination, then this new extension
> will not protect the user even when the destination has TLSA
> records, because the server can deny their existence (not offer
> the extension) without proof.
>
> What makes this case different is that the naïve mental model
> of what it offers is support for DANE-based peer authentication
> equivalent to doing the DNSSEC lookups on the client end, but
> with DNSSEC tunneled via the server.
>
> Therefore, some text is probably warranted to disabuse the reader
> of such a naïve view.  What one gets with this extension, in the
> more typical cases in which DANE is not "mandatory", is not
> equivalent to enforcing DANE when it is published by the peer.
> Rather, what one gets is the ability to use DANE to authenticate
> sites that one might not otherwise be able to authenticate (no
> shared WebPKI trust-anchor).
>

Yes, I agree that some elaboration on this limitation of the protocol
is useful. In case you missed it, I do actually document the limitation
quite explicitly in Section 8, which I'll excerpt here:

   "This protocol currently provides no way for a server to prove that it
   doesn't have a TLSA record.  Hence absent whitelists, a client
   misdirected to a server that has fraudulently acquired a public CA
   issued certificate for the real server's name, could be induced to
   establish a PKIX verified connection to the rogue server that
   precluded DANE authentication.  This could be solved by enhancing
   this protocol to require that servers without TLSA records need to
   provide a DNSSEC authentication chain that proves this (i.e. the
   chain includes NSEC or NSEC3 records that demonstrate either the
   absence of the TLSA record, or the absence of a secure delegation to
   the associated zone).  Such an enhancement would be impossible to
   deploy incrementally though since it requires all TLS servers to
   support this protocol."

But perhaps it needs to feature more prominently in the document
rather than being buried in the context of a discussion about mandating
the use of this extension. The limitation exists independent of whether
a TLS application is trying to mandate things.

My suggestion is to move this discussion to the beginning of the
Security Considerations section, and then adding some of your
elaborating points, including a direct comparison with clients querying
DANE records themselves. It might also be worth a brief mention in the
Intro section that the protocol lacks authenticated denial and pointing
the reader/implementer to the Security Considerations section for more
details.

Shumon Huque