Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

From: Shumon Huque <[email-masked]>
Date: Thu, 1 Mar 2018 14:13:39 -0500

On Wed, Feb 28, 2018 at 3:07 PM, Nico Williams <[email-masked]>
wrote:

> IF there's an objection to modifying the extension in order to add a
> pin-to-DANE TTL field, I would propose the following instead:
>
>     Make the pin-to-DANE be "forever" but make it so it can easily be
>     cleared if DANE is undeployed for the service.
>

This option is already covered in the draft. It doesn't use the term
pinning,
but does mention caching the existence of DANE on first contact and
requiring it subsequently (if clients want to do so).

I do not know if the draft authors and/or WG have an appetite to do the
much
more major change suggested by Viktor (i.e in-protocol pinning TTL
commitment
and requiring subsequent denial of existence proof if DANE is removed).

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 1 Mar 2018 14:16:13 -0500

On Tue, Feb 27, 2018 at 6:36 PM, Nico Williams <[email-masked]>
wrote:

> On Tue, Feb 27, 2018 at 11:24:31AM -0500, Shumon Huque wrote:
> > On Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque <[email-masked]> wrote:
> > > 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.
> >
> > Following up to my own message, sorry ..
> >
> > It occurred to me that perhaps a good way to mitigate this risk is
> > a combo of mechanisms like CAA and Certificate Transparency logs.
>
> NO.  That's insanely complicated.

Is it really?

We're talking about a scenario of incremental deployment of DANE in an
existing PKIX ecosystem. In such an environment, I would expect that
many servers will likely support both PKIX-only and DANE, at least
initially. So presumably they will already be paying attention to CT logs
to
detect mis-issuance. And even if they support only DANE, they might be
concerned about an attacker impersonating their service to DANE
unaware clients.

Shumon.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 1 Mar 2018 16:51:03 -0500

> On Mar 1, 2018, at 2:13 PM, Shumon Huque <[email-masked]> wrote:
> 
>> On Wed, Feb 28, 2018 at 3:07 PM, Nico Williams <[email-masked]> wrote:
> This option is already covered in the draft. It doesn't use the term pinning,
> I do not know if the draft authors and/or WG have an appetite to do the much 
> more major change suggested by Viktor (i.e in-protocol pinning TTL commitment

Avoiding an explicit TTL, and clients unilaterally assuming the DANE extension
will always be available is not IMHO a good idea.

Websites that initially implement the extension should be able to eventually
stop using it, if for some reason they decide that they no longer want to do
so.  While the server can clear the caches of clients that see a denial of
existence of the TLSA records, or proof an unsigned delegation from a parent
domain, without a max TTL there are always clients that have not yet connected
since the policy change, and will be broken indefinitely if the extension is no
longer delivered.

Therefore, any long-term caching of a destination's support for the extension
should require server opt-in, and must have a maximum duration.

-- 
	Viktor.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 3 Mar 2018 22:09:34 -0500 (EST)

> and requiring subsequent denial of existence proof if DANE is removed).

I think it is worth discussing in London and/or some people meeting up
to talk about this and bring something to the list/WG.

The original idea of this extension I believe (and one of my reasons
behind writing RFC 7901) was to provide an alternative path for DNS
that couldn't be blocked or broken and that provides DNS answers without
additional latency. To me, that always included proof of non-existence,
as it would come in as the answer to a DNS chain-query via TLS headers
as the transport.

I don't know why this got turned into something that is almost like DNS
but not quite DNS. I think that is a mistake.

The TLS extension should be nothing more (and nothing less) than
stappled DNS suitable for a DNS routines.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 Mar 2018 19:21:52 -0800

Hi folks,

This is way outside the range of my DISCUSS, so maybe we should change the
thread title.

Paul, can you walk me through the security value of a proof of nonexistence
here? Perhaps describe an attack that it stops.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 3 Mar 2018 22:44:16 -0500

[ Not replying for Paul, I'm sure he he'll post views separately ]

> On Mar 3, 2018, at 10:21 PM, Eric Rescorla <[email-masked]> wrote:
> 

My take is:

Non-existence proofs can clear a pinned DANE policy, where a client would
other require ongoing delivery TLSA records (after initially seeing them
from the server).  The data would not be pinned, that's what the DNSSEC
signed TLSA records are for.

The attack in question is downgrade to just PKIX (with fraudulently
obtained certificates).  Such a downgrade makes PKIX-TA(0) and PKIX-EE(1)
ineffective, and downgrades DANE TlSA to DV certs which are strictly weaker.

Therefore, if the extension were to include an extended pin-TTL, then
denial of existence becomes useful, and indeed the pinning is primarily
a means to make it downgrade-resistant.

-- 
	Viktor.

---

From: Willem Toorop <[email-masked]>
Date: Mon, 5 Mar 2018 10:32:25 +0100

Op 01-03-18 om 22:50 schreef Viktor Dukhovni:
> will always be available is not IMHO a good idea.>

How do you (all) feel about using the expiry date on the RRSIG for the
TLSA to be used for this purpose?

---

From: Willem Toorop <[email-masked]>
Date: Mon, 5 Mar 2018 11:08:50 +0100

Op 26-02-18 om 15:26 schreef Paul Wouters:
> On Thu, 22 Feb 2018, Shumon Huque wrote:
> 
>> On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters <[email-masked]> wrote:
>>       On Wed, 21 Feb 2018, Shumon Huque wrote:
>>
>>             Okay, got it. For people that have already implemented
>> this, I think
>>             there has been an implicit understanding that the format
>> of the chain
>>             data is a sequence of concatenated wire format RRs exactly
>> as they appear
>>             in a DNS message section
>>
>>
>>       Note, I would not call it "sequence of concatenated wire format
>> RRs", as
>>       it is simply the wireformat of a DNS message.
>>
>>       The fact that some parts
>>       are concatenated RR's is just part of the wireformat of the DNS
>> reply
>>       message. That is, this isn't introducing some new form of
>> concatenated
>>       content - it is _just_ a regular DNS wire format message, and the
>>       document should not go deeper into its explanation.
>>
>>
>> It would _not_ be correct to say that this is a "DNS wire format
>> message" - that 
>> would mean there is a DNS header section with flags and response codes, 
>> and other sections. The chain data structure as currently specified
>> really is 
>> concatenated wire-format RRs (as they appear _within_ a DNS message 
>> _section_). Let me know if that is unclear in the draft (or my
>> proposed edits).
> 
> 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?

No Paul, the division in sections is irrelevant for a verifier.  The
only bit of information in a DNS message that is used by a verifier is
the question.  From the question, validation starts and the relevant
records are followed and verified.  But the question section is also not
needed as the question can be derived from the name and port of the
service, i.e. <port>._tcp.<name>. TLSA

The order described in the draft is both an optimization to reduce the
number of times a verifier has to go over the RRs, and it makes the
content easier to read (and understand) for humans too.

Also, for non existence answers, DNSSEC validators (and thus also a
verifier for the chain extension) simply ignore the DNS message header.
Proof of non-existence can and must be derived from the set of RRs in
the message body/sections too.

The extension already supports Denial of Existence proof b.t.w., because
it is also needed for wildcard expansions (which are supported).

Personally, I do not have very strong feelings whether or not the
extension content is a DNS message or not, but a verifier would ignore
the header and the question anyway, so why bother with that overhead?
Also, you *can* use the content of the RFC7901 chain query.  You just
have to skip the header and question section, and then include the rest.

> 
> 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.
> 
>> I recall at one point way back there was a discussion about whether
>> the chain
>> data should just be a fully formed DNS message, but I don't believe
>> that idea
>> had much support in the working group (personally I would have been
>> fine with 
>> that choice too, if it did have support).
> 
> Do you remember why not? I'll see about checking the archives, but to me
> the hint that you are losing information and require some kind of
> ordering seems to suggest there is a need for using the full DNS message
> reply format
> 
>> There is some residual wording in the draft about ordering of CNAMEs
>> etc in
>> the answer records part. Assuming the WG agrees, I am fine with relaxing
>> that requirement - that ended up in there because although there is no
>> defined
>> ordering of RRs within a DNS message section, as a practical matter
>> CNAMEs
>> are almost always ordered since there are some DNS queriers that get
>> confused 
>> otherwise. This is a new protocol though, so we can be more faithful
>> to the DNS 
>> spec.
> 
> I would prefer the residual wording to go away. Any hints at order being
> important should be squashed.
> 
>>       I don't think getting unrelated DNSSEC records would be an
>> issue. TLS
>>       has its maximum sizes for the handshake. In fact, it could allow
>> the
>>       extension to have some useful data in the case of MX or SRV. 
>> (and could
>>       be a feature to build a nice resolver over TLS using 1 tor
>> circuit).
>>
>> The draft currently doesn't address the MX or SRV use case. I suggest
>> that we tackle that in a future version.
> 
> Jus make sure the document doesn't forbid any such data, and allow the
> client to ignore these or put them in the cache as it sees fit.
> 
>>       I'm also not sure about the talking of unsigned CNAME records from
>>       DNAME. The above pseudo code (extended with special cases)
>> should be
>>       in some DNS library, and that library will know what records to
>> expect
>>       unsigned which are proven by the DNAME (or wildcard) synthesis
>> and knows
>>       when/if to add it to the validated cache. I don't think that
>> should be
>>       explained in this RFC at all. The DNS implementation does not need
>>       to be specified in this document and it should just focus on saying
>>       that "the DNS message response is validated and upon validation the
>>       content can be considered DANE validated".
>>
>>
>> Where we ended up, is that WG participants asked for some level of DNSSEC
>> detail to be included in this doc.
> 
> Again, that will only lead to bad implementations. There should be no
> need to update this document once something like ANAME, ALIAS or ZNAME
> is introduced to the DNS. So you should not talk about these things at
> all. TLS client should use a dns library that knows these things, or if
> they want to write one from scratch, these implementors should look at
> the DNS RFCs and not this RFC for guidance on how the DNS protocol
> works.
> 
> Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 5 Mar 2018 09:00:15 -0500

> On Mar 5, 2018, at 4:32 AM, Willem Toorop <[email-masked]> wrote:
> 

I don't think the expiry date is adequate for this purpose.  To reduce
the scope for replay attacks, my domain has 14 day RRSIG lifetimes, and
automated re-signing happens as records age, so they are often as close
as ~4 days away from expiration when re-signed.  And yet, if were to
deploy a web server that implements this extension, I'd want to commit
to DANE for a considerably longer time.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 5 Mar 2018 11:02:48 -0500 (EST)

> to DANE for a considerably longer time.

There is also the reverse problem of pinning something you don't have
anymore. With TTL, you can tune your commitment and risk.

Also in general, DNS data should not be used beyond its TTL unless the
data itself has some kind of TTL on it (eg a full cert payload or
openpgp key with expiry)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 12 Mar 2018 14:29:55 -0400 (EDT)

> the message body/sections too.

Willem (and Shumon and Viktor) have convinced me the DNS Header and
Sections are not needed.

> it is also needed for wildcard expansions (which are supported).

The issue here is the requirement of the TLS server to send these
records in the absence of any TLS record. This allows the clients to
detect a rogue webserver cert that is valid in webPKI but not valid
based on DANE. Without this commitment, the TLS extension does not
really work, as it can be omitted by an attacker.

Paul

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 12 Mar 2018 15:22:45 -0400

Hello,

Can you please provide updated text that addresses EKR's discuss while
this additional discussion continues?  I'd like to see if it's
possible to get this wrapped up before the plenary in London.
Eliminating discuss points and resolving this additional issue are
required for that.  If this does not get wrapped up before then, it is
likely the draft will have to go on another IESG telechat with Ben as
AD, which is fine if that's needed, but better to avoid.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 12 Mar 2018 22:01:03 +0200

> really work, as it can be omitted by an attacker.

One idea for adding pinning:

- Add pinned flag to the client request structure. This is set if
  the client has the server pinned, otherwise clear.
- Add max_age field to the server response structure.
- If max_age=0, the payload can either be authenticated TLSA RRset or
  proof no such thing exists. Any sent RRset applies to current
  connection. In either case, the pin breaks immediately.
- If max_age>0, the payload must be TLSA RRset. The TLSA RRset
  appiles to this connection. Pin the name as requiring this extension
  for next max_age seconds.
- Add security consideration that sending TLSA RRsets with max_age=0
  is vulernable to downgrade attacks.

The reason for the flag in client request is to tell the server if
it should bother sending ADoE back or not.

Also, could cached_info extension be extended to cover data for this
extension? It would save some bandwidth...

-Ilari

---

From: Shumon Huque <[email-masked]>
Date: Sun, 18 Mar 2018 10:11:17 +0000

Hi Kathleen,

Sorry for the delay. We'll have an updated draft addressing the IESG
discuss/comments shortly after the I-D submission window opens early
this week.

The one other sticking point is the issue that Viktor has raised about
extending
the protocol to provide pinning to prevent downgrade to PKIX. That has not
been resolved on list yet, so I assume will be discussed at Wednesday's TLS
session.

Shumon.