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

[Viktor Dukhovni <[e-mail]>]

> On Feb 22, 2018, at 10:59 AM, Shumon Huque <[e-mail]> wrote:
> 
>>>> If there is a MitM, then this extension simply isn't negotiated.
>>>> That's pretty well understood.  I don't see why that requires special
>>>> mention.
>>> 
>>> Yeah, I agree Martin .. this is the same as with any other extension.
>> 
>> Actually, I don't think it is quite the same.
> 
> I meant same in the sense that if any extension is blocked then it
> can't be used. What the effect of that is depends obviously on what
> functionality the extension is providing. The TLS client can at least detect
> such blocking/stripping, and alert the application or fallback to something 
> else.
> 
> Have other TLS extension specs gone into the details of middlebox 
> impacts?

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).

The main exception to this limitation is that once DANE TLSA
records are obtained and cached (assuming there's a cache),
then they may protect against downgrade to PKIX-along for the
TTL of the previously obtained records, and if the cache is
"refreshed" periodically (prior to expiration) by a client
that continues to communicate with the server frequently
over newly negotiated connections, then it becomes difficult
for an MiTM to downgrade the communication to strip the DANE
TLSA extension, unless the MiTM certificates are stolen directly
from the server (rather than obtained fraudulently for a new key
controlled by the attacker).

The above exception will not be typical, so this extension is
useful to support DANE-TA(2)/DANE-EE(1) certificate usages, but
does not (when not mandatory) support PKIX-TA(0)/PKIX-EE(1), because
authenticated denial of existence is lost.

If some day (a decade or more from now if and when it is nearly
universally implemented by servers) the extension is made mandatory,
and requires authenticated denial of existence (or proof that the
server's domain is not signed), THEN it would reach parity with
direct DNSSEC lookups by the client, and its purpose would be
latency reduction, rather than overcoming DNSSEC opaque captive
portals...

-- 
-- 
	Viktor.