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

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 07 Feb 2018 05:21:26 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-tls-dnssec-chain-extension-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Two minor, mostly editorial comments:

1) Intro (sec 2): " It also provides the
   ability to avoid potential problems with TLS clients being unable to
   look up DANE records because of an interfering or broken middlebox on
   the path between the client and a DNS server."
Is that actually a well-known problem (can you provide a reference?) or would
it be enough to say something like this: " It also provides the
   ability to avoid potential problems with TLS clients being unable to
   look up DANE records when DNS server is not reachable."

2) IANA Considerations should probably be updated.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 7 Feb 2018 21:27:44 -0500

On Wed, Feb 7, 2018 at 8:21 AM, Mirja Kühlewind <[email-masked]> wrote:

> Is that actually a well-known problem (can you provide a reference?)

Some folks (at Google and NLnet Labs if I recall; maybe others) have done
measurements to show this is an actual problem -- for a relatively small but
still non-trivial fraction of clients. We'll try to see if we can dig up
specific
references to documents that could be cited.

or would
>    look up DANE records when DNS server is not reachable."

Your rewording of this sentence would unfortunately not be accurate.
It's usually not the DNS server that is unreachable, but that some middlebox
has done something wrong, such as: not allow DANE queries or responses
through; not allow DNSSEC signatures through; not allow EDNS options
that enable DNSSEC through, or engage in other misbehavior.

> 2) IANA Considerations should probably be updated.

I guess you are suggesting that the last sentence is probably obsolete:

    "If the draft is adopted by the WG, the authors expect to make an
     early allocation request as specified in [RFC7120]."

Agreed. It's a little late for that! :-)

We will remove it.

Shumon Huque

---

From: Willem Toorop <[email-masked]>
Date: Thu, 8 Feb 2018 10:51:27 +0100

Op 08-02-18 om 03:27 schreef Shumon Huque:
> On Wed, Feb 7, 2018 at 8:21 AM, Mirja Kühlewind <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

I wouldn't call it a relatively small fraction :)  DNSSEC is severely
hampered for end-entities by broken infrastructure in many different
ways.  Sometimes an upstream resolver can be used for positive DNSSEC
answers (i.e. existing records), but not for non-existent or wildcard
answers, because it simply doesn't forward the NSEC(3) proof for it.

The last measurements we at NLnet Labs did was in July 2015:

	Gorjón, Xavier Torrent, and Willem Toorop.
	"Discovery method for a DNSSEC validating stub resolver."
	(2015)

	https://nlnetlabs.nl/pub/os3-2015-rp2-xavier-torrent-gorjon.pdf

Measurements were done with RIPE Atlas, with at the time +-8200 probes.
At the time only 56% of probes received enough DNSSEC data from their
upstreams to be able to perform DNSSEC validation for both positive and
non-existent answers (required for DANE).

There is a RFC that outlines detection and mitigation techniques on how
to deal with this from DNSSEC validation stub resolvers:

	RFC8027  -  DNSSEC Roadblock Avoidance

Ultimately such a stub resolver has to be able to fallback to full
recursive resolving (i.e. iterating from the root).  Although even that
might fail...

Furthermore, hampered DNS (but not specifically DNSSEC), is the primary
motivation for the new DNS over HTTPS draft (and workgroup):

https://tools.ietf.org/html/draft-ietf-doh-dns-over-https

(DoH might be the ultimate final fallback in DNSSEC Roadblock Avoidance)

---

From: Shumon Huque <[email-masked]>
Date: Thu, 8 Feb 2018 09:32:55 -0500

> non-existent answers (required for DANE).

Ah, thanks. I'd forgotten that it was so high!

I think my "relatively small" comment was recalling an earlier study (I
think by
Google) that saw a breakage of around ~ 5%, but I think that was just
measuring
the ability to lookup and obtain less common RR types and did not measure
ability
to perform full DNSSEC validation.

Shumon.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 13 Feb 2018 12:07:14 -0500

> to perform full DNSSEC validation.

What's the behavior when the middlebox is a proxy, let's say existing
a managed network?  I presume from from section 3.1 that this
negotiation doesn't work in that instance unless sites configured for
this are not subject to the proxy as is often done for financial site
access from corporate networks.  It would be good to know if it does
work and that is addressed with the text Mirja calls out for her #1
question.  Having this clarified could be helpful.

Thanks.

-- 

Best regards,
Kathleen

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Feb 2018 09:50:07 +1100

> question.  Having this clarified could be helpful.

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.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 21 Feb 2018 11:00:25 -0500

> That's pretty well understood.  I don't see why that requires special

Yeah, I agree Martin .. this is the same as with any other extension.

Shumon.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 21 Feb 2018 11:04:55 -0500

> Yeah, I agree Martin .. this is the same as with any other extension.

OK, I think it is clear in the discussion with 1.2, but wasn't sure if
it was clear enough elsewhere and figured it was best to ask.

-- 

Best regards,
Kathleen

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 21 Feb 2018 13:49:49 -0500

> On Feb 21, 2018, at 11:00 AM, Shumon Huque <[email-masked]> wrote:
> 
> On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson <[email-masked]> wrote:

Actually, I don't think it is quite the same.  This extension may
be naïvely expected to provide a different peer authentication
mechanism than the traditional WebPKI.  Users who might expect this
extension to protect them from WebPKI compromise via DANE TLSA
records, need to understand that such protection only exists when
DANE is enforced (mandatory) by the client.

The absence of DANE TLSA records, which is downgrade-resistant
when the client has access to DNSSEC authenticated denial of
existence (makes its own DNSSEC lookups) is no longer downgrade-
resistant when delivered via this extension if the client
is willing to accept just WebPKI in the (apparent) absence of DANE
TLSA records.

-- 
	Viktor.

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 22 Feb 2018 10:59:56 -0500

On Wed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni <[email-masked]>
wrote:

> 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?

>   This extension may

Some of this is already discussed or at least implicit in the draft.
If you want to propose specific text to add or modify, please do so ..

Shumon.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 22 Feb 2018 11:08:13 -0500

> Have other TLS extension specs gone into the details of middlebox

This one is a little different though as end users are expecting e2e
without interference with this extension.  Understanding the behavior
is important for administrators and users as Viktor stated.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Shumon Huque <[email-masked]>
Date: Thu, 22 Feb 2018 11:17:58 -0500

> is important for administrators and users as Viktor stated.

Okay Kathleen.

We'll add some discussion on this. Viktor - I assume you'll help with text.

Shumon.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 22 Feb 2018 12:06:54 -0500

On Thu, Feb 22, 2018 at 11:17 AM, Shumon Huque <[email-masked]> wrote:
> On Thu, Feb 22, 2018 at 11:08 AM, Kathleen Moriarty

Thank you!

-- 

Best regards,
Kathleen

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 22 Feb 2018 12:21:13 -0500

> On Feb 22, 2018, at 10:59 AM, Shumon Huque <[email-masked]> 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).

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.

---

From: Shumon Huque <[email-masked]>
Date: Fri, 23 Feb 2018 14:20:12 -0500

> 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