Subject: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 4 Jun 2018 15:39:47 -0500

Hi folks,

I've taken a stab at putting together some security considerations text for
draft-ietf-tls-dnssec-chain-extension that reflects my understanding of the
current state of affairs.  It's in a pull request at
https://github.com/tlswg/dnssec-chain-extension/pull/19 , along with Viktor's
commit to update the text about the actual DNS records involved (which as
far as I can tell seems to improve the technical accuracy of the text), and
also inserting a variable-length array that's reserved for future attempts
to mitigate the (now-)documented security considerations.

I'd be interested to hear what aspects people agree with and disagree with,
whether on- or off-list.

Thanks,

Ben (with no hats)

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 5 Jun 2018 00:26:24 -0400

> On Jun 4, 2018, at 4:39 PM, Benjamin Kaduk <bkaduk=[email-masked]> wrote:
> 

Looks like a solid proposal to me, especially the updated security considerations.
Thanks!  I added two very minor comments on the PR, one correcting a typo, the other
slightly more technical correcting an erroneous NSEC record in the NSEC denial
of existence example.  Thanks again...

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 5 Jun 2018 09:51:03 -0400 (EDT)

On Mon, 4 Jun 2018, Benjamin Kaduk wrote:

Hi Ben,

> to mitigate the (now-)documented security considerations.

Thanks for writing the proposed text. The new opaque Reserved field
along with the denial of existence changes you propose addresses all
my concerns.

One corner case that might be worth mentioning with the proposed DoE text
is the odd corner case of hitting a server with a Host header for which
it is not configured. You will hit the "default vhost" but you have no
appropriate extension data to populate for that hostname. So either the
server will return the (cached) TLSA/DoA data of the 'wrong' hostname,
or it could just omit the extension. I'd mostly like to say something to
prevent an implementation of forgetting this corner case and causing
some vulnerability in their code later on by pointing to bogus memory or
crashing on dereferencing a NULL.

Some nits:

 	If the server supports this extension it performs the appropriate DNS queries,

In my PR I had changed this into "obtains the appropriate DNS RRsets",
because I envision that TLS servers might not do DNS lookups themselves,
but just read this via a file or other method. Eg a cron job that
regenerates these hourly for all the hosted domains. It also reduces
some fear that all TLS servers suddenly could need to link against
a DNSSEC library. They don't if they can just reload a blob from disk
regularly to serve up.

Similarly:

 	it will need to rebuild

is better written as "it will need rebuilt data"

 	"authenticates the chain"

That should probably be "validate the chain", but the document has more
mixups of validate vs authenticate. In my PR request I had not corrected
them in an effort to keep the diff as small as possible.

I had modified the examples slightly, so the NSEC example would show a
simpler NSEC chain (from www to zzz) instead of the one wrapping around
from www to the zone apex. The example quoted is the wrong NSEC record
(the one from apex to www.example.com does not show that the
_443._tcp.www.example.com does not exist, you need the one from
www.example.com to the apex at the end of the zone)

I'm not sure what you mean with:

 	validated negative TTL

I guess you mean to say the shortest TTL of any data in the chain? But
sometimes the negative cache time is larger then the TTL (eg if TTL = 0)
Since this is just generic DNS handling, I would probably just write
something like "up to the appropriate lifetime" and leave it out of
this document.

 	denial of existence RRset

Technically that should be "RRsets" since you usually will need more then
one RRset to prove this (to disprove existence of the wildcard record)

 	-      DNSSEC authentication chain extension from a server, SHOULD use this
 	+      DNSSEC authentication chain extension from a server, uses this

I'm not sure why the SHOULD was removed here? Since it is describing TLS
client behaviour the "uses this" confuses me as I dont know if that
means MAY, SHOULD or MUST.

 	+ Specifically, the relevant DANE records are included
 	+ in the TLS handshake transcript hash, so both sides
 	+ possess identical records;

I'm not sure why you suggest to add this text. A TLS client might still
have cached a valid TLSA records from a previous connection 1 second
ago and might decide to not use this information at all. Also, it seems
to suggest that the transscript hash protects this data, but it is
"protection" using the webpki or proof of lack of MITM, but the data
does not need this protecting as it is protected by DNSSEC signatures.

 	+ the client remains responsible
 	+ for actually performing the domain name validation of
 	+ the DANE records.

Well, if it just fired up a previous TLS connection, perhaps it will be
content with the same pubkey used and skip re-validating this data? I
guess we sort of say the same thing due to the lack of a MUST ?

 	+ The Reserved field is reserved for future updates to this
 	+ document; in particular it is hoped that the issues discussed
 	+ in <xref target="increasing-trust" /> can be addressed.
 	+ Implementations of this specification MUST send a zero-length vector

Perhaps that last line can be clarified a bit:

 	Implementation not implementing any updates to this document
 	MUST send a zero-length vector

This sentence does not parse:

 	"whether or not to the exclusion"

This text is a little confusing to me:

 	+ certified by the DNS key hierarchy, that the
 	+ server does not support DANE authentication

The TLS server itself might support "DANE authentication", but there is
simply no data.  Perhaps say that the server's configured hostname does
not support DANE authentication?

Thanks again for the write up!

Paul

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 25 Jun 2018 21:20:16 -0700

Hi Folks,

There has been some discussion with a small group of folks on github -
https://github.com/tlswg/dnssec-chain-extension/pull/19.   I want to make
sure there is consensus in the working group to take on the pinning work
and see if there is consensus for modifications in the revision.  Please
respond to the following questions on the list by July 10, 2018.

1.  Do you support the working group taking on future work on a pinning
mechanism (based on the modifications or another approach)?

2.  Do you support the reserved bytes in the revision for a future pinning
mechanism?

3.  Do you support the proof of denial of existence text in the revision?

4.  Do you support the new and improved security considerations?

Thanks,

Joe

On Tue, Jun 5, 2018 at 6:51 AM, Paul Wouters <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nico Williams <[email-masked]>
Date: Tue, 26 Jun 2018 11:18:49 -0500

> mechanism (based on the modifications or another approach)?

Yes with a caveat: I don't much care whether pinning work gets done as
an individual submission, as a TLS WG work item, or some other WG's work
item.

> 2.  Do you support the reserved bytes in the revision for a future pinning

Yes.  I prefer just the two bytes we asked for, but I'm also happy with
the optional up-to-255-byte hole.  I'm not at all interested in more
complex holes.

> 3.  Do you support the proof of denial of existence text in the revision?

Yes.

> 4.  Do you support the new and improved security considerations?

Yes.

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Wed, 27 Jun 2018 12:27:03 -0400 (EDT)

On Mon, 25 Jun 2018, Joseph Salowey wrote:

> There has been some discussion with a small group of folks on github - https://github.com/tlswg/dnssec-chain-extension/pull/19. 
>  I want to make sure there is consensus in the working group to take on the pinning work and see if there is consensus for
> modifications in the revision.  Please respond to the following questions on the list by July 10, 2018. 
> 
> 1.  Do you support the working group taking on future work on a pinning mechanism (based on the modifications or another
> approach)?

Yes I support taking on the work to do the extension pinning. Just to
ensure people are not confused, this is not about pinning of TLS(A) data.

> 2.  Do you support the reserved bytes in the revision for a future pinning mechanism?

Yes I support both this proposal of reserved bytes or the previous the two
byte reservation. I have no strong preference.

I do not support using a second TLS extension to pin the first, or the
use of a TLS Extensions block, which is also basically two extensions
interacting with each other.

> 3.  Do you support the proof of denial of existence text in the revision?

Yes I support this text, provided the error in the example.com example is
fixed (it is using the wrong NSEC record, see Viktor's or my PR for the
fix)

> 4.  Do you support the new and improved security considerations? 

Yes I support the changes.

Do note that this part confuses me a little bit:

 	but under the assumptions of this specification, there may not be a
 	reliable way to obtain such DNS records.

where "such" refers to Denial of Existence records. Since your change
also has:

+        Following the TLSA or denial of existence RRset,
+        the subsequent RRsets MUST contain the full set of DNS records
          needed to authenticate the TLSA record set or denial of existence
          response via the server's trust anchor.

I think the "there may not be a reliable way to obtain such DNS records."
can be removed?

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 27 Jun 2018 12:56:12 -0400

> On Jun 26, 2018, at 12:20 AM, Joseph Salowey <[email-masked]> wrote:
> 
> Hi Folks,
> 
> There has been some discussion with a small group of folks on github - https://github.com/tlswg/dnssec-chain-extension/pull/19.   I want to make sure there is consensus in the working group to take on the pinning work and see if there is consensus for modifications in the revision.  Please respond to the following questions on the list by July 10, 2018. 
> 
> 1.  Do you support the working group taking on future work on a pinning mechanism (based on the modifications or another approach)?

Yes.

> 2.  Do you support the reserved bytes in the revision for a future pinning mechanism?

Yes, no strong feelings whether it is exactly 2 bytes or an opaque<0..255>
to be defined as part of 1.  With either exactly 2 bytes, or an empty opaque,
the server signals that its operator does not (yet?) support unilateral
client-side pinning.  No to turning this into an extension block.

> 3.  Do you support the proof of denial of existence text in the revision?

Yes, with minor error corrections, where appropriate (perhaps
after the next I-D revision, easier perhaps to read a complete
snapshot than a pull request, and tools.ietf.org can also show
diffs).

> 4.  Do you support the new and improved security considerations?

Yes.  We can word-smith any minor blemishes when the next I-D
version comes out.

-- 
	Viktor.