Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 2 Jul 2017 17:03:08 +0300

On Wed, Jun 28, 2017 at 02:15:45PM -0700, Joseph Salowey wrote:
> This is the working group last call for
> draft-ietf-tls-dnssec-chain-extension-04.
> Please send you comments to the list by July 12, 2017.

Some comments:

1) Section 3.2.  Protocol, TLS 1.3:

> The authentication chain will be an extension to the certificate_list
> to which the certificate being authenticated  belongs.

Extension blocks are per-certificate. I presume the extension goes to
the extension block of EE certificate?

2) Section 3.2.  Protocol, TLS 1.3:

I think if one refers to TLS 1.2 section, one should just call out the
differences (i.e., where the server extension goes), and not duplicate
parts of TLS 1.2 processing.

Right now, the text can be fairly easily be misread (e.g., that the
restriction on not constructing arbtirary records does not apply).

3) Section 3.4.  DNSSEC Authentication Chain Data:

> The resource records SHOULD be presented in the canonical form and
> ordering as described in RFC 4034 [RFC4034].

What is the expected _receiver_ (i.e., client) behavior? Is the client
supposed to run a canonicalization and sorting pass on the records?

If the client does not do this, and the server sends noncanonical or
unsorted RRset, the validation is going to fail.

4) Section 3.4.  DNSSEC Authentication Chain Data:

> Each RRset in the sequence is followed by its associated RRsig
> record.  The RRsig record is in DNS wire format as described in RFC
> 4034 [RFC4034], Section 3.1.  The signature portion of the RDATA, as
> described in the same section, is the following:

This seems to imply that all RRs that make RRSet need to be adjacent in
the serialization. However, I don't see this explicitly stated
anywhere.

Also, 'RRsig record' or 'RRsig records'? IIRC, if ZSK is being rolled
(and for DNSKEY, if KSK is being rolled), there will be two RRsig
records for one RRtype.

5) Section 3.4.  DNSSEC Authentication Chain Data:

> The first RRset in the chain MUST contain the TLSA record set being
> presented.  However, if the owner name of the TLSA record set is an
> alias (CNAME or DNAME), then it MUST be preceded by the chain of
> alias records needed to resolve it.

Is there a requirement to order the aliases in order those aliases are
followed?

6) Section 3.4.  DNSSEC Authentication Chain Data:

> The final DNSKEY RRset in the authentication chain corresponds to the
> trust anchor (typically the DNS root).  This trust anchor is also
> preconfigured in the TLS client, but including it in the response
> from the server permits TLS clients to use the automated trust anchor
> rollover mechanism defined in RFC 5011 [RFC5011] to update their
> configured trust anchor.

I think this is wrong. The final DNSKEY RRSet does contain the the
preconfigured root key. However, it also contains other keys that
are used to sign the DS records.

The client needs those keys in order to validate the chain, and those
keys are rotated every few months for root, instead of every N years.

Furthermore, frequently the trust anchor is provisioned as a fake DS
record for the root. Validating with such anchor requires sending the
root DNSKEY.

Real-world zone data (omitted the cryptographic line noise, and added
some hilights):

$ dig +dnssec -t DNSKEY .

; <<>> DiG 9.10.3-P4-Debian <<>> +dnssec -t DNSKEY .
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3623
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;.                              IN      DNSKEY

;; ANSWER SECTION:
.                       154841  IN      DNSKEY  256 3 8 <...>
.                       154841  IN      DNSKEY  257 3 8 <...>
.                       154841  IN      DNSKEY  256 3 8 <...>
.                       154841  IN      RRSIG   DNSKEY 8 0 172800 20170711000000 20170620000000 19036 . <...>
;; --------------------------------------------------------------------
;; Note the "19036" near end of previous line. That field contains the
;; key checksum of the key making the signature. 19036 is the checksum
;; of the well-known IANA root key.
;; --------------------------------------------------------------------

;; Query time: 0 msec
;; SERVER: ::1#53(::1)

$ dig +dnssec -t DS fi.

; <<>> DiG 9.10.3-P4-Debian <<>> +dnssec -t DS fi.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16923
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;fi.                            IN      DS

;; ANSWER SECTION:
fi.                     66181   IN      DS      48592 8 2 <...>
fi.                     66181   IN      RRSIG   DS 8 1 86400 20170711050000 20170628040000 14796 . <...>
;; --------------------------------------------------------------------
;; Note here the key checksum is not "19036", but "14796".  The key
;; used is found from the . IN DNSKEY records, and rotated every few
;; months.
;;
;; Also note: DS records are special, and reside on parent side of
;; zone cut, not on child side (another special type is NS, which
;; exists on both sides of the zone cut; all other data RRtypes exist
;; on the child side).
;; --------------------------------------------------------------------

;; Query time: 0 msec
;; SERVER: ::1#53(::1)

7) Section 4.  Construction of Serialized Authentication Chains

> The transport is "tcp" for TLS servers, and "udp" for DTLS servers.
> The port number label is the left-most label, followed by the
> transport, followed by the base domain name.

So if this would be used with IETF-QUIC, the labels would be
_443._tcp, which is the same as one used by HTTPS, right?

-Ilari

---

From: Melinda Shore <[email-masked]>
Date: Sun, 2 Jul 2017 21:04:13 -0800

Thanks for the careful review, Ilari.  It's a long weekend in the US
but we'll get some proposed text out mid-to-late this week.

Melinda

---

From: Shumon Huque <[email-masked]>
Date: Tue, 4 Jul 2017 11:33:45 -0400

> the extension block of EE certificate?

Yes, in fact the previous sentence to the one you quoted did say this more
or less: " ... return a serialized authentication chain in the Certificate
message associated with the end entity certificate being validated ". I
would propose rewording that a bit and removing the last quoted sentence
entirely:

   Servers receiving a "dnssec_chain" extension in the ClientHello, and
   which are capable of being authenticated via DANE, SHOULD return a
   serialized authentication chain in the extension block of the
Certificate
   message containing the end entity certificate being validated, using the
   format described below.

> parts of TLS 1.2 processing.

I agree.

> unsorted RRset, the validation is going to fail.

Since the ordering is a SHOULD on the server side, the client has to check
and perform canonical re-ordering if necessary anyway, before computing and
validating the signature. If this were a MUST, a stronger case could be
made that this recommendation saves the client some work.

Personally, I would be fine with taking out the recommendation for the
server to canonically order the records. DNSSEC validators (the client end)
are required to reconstruct the canonical form and ordering of the RRset
(see RFC 4035, Section 5.3) before validation, so unless there is a
compelling rationale for deviating from this, we shouldn't.

Section 6 ("Verification") essentially says to do validation according to
RFC 4035, which covers all of this, and we were planning on leaving it at
that -- rather than replicating text that just restates DNSSEC validation
logic that is normatively defined elsewhere.

(Perhaps RFC 5155 should also be mentioned now that this spec accommodates
negative proofs associated with wildcards and thus has to deal with NSEC3).

> the serialization. However, I don't see this explicitly stated

Yes, we can state that more explicitly.

> (and for DNSKEY, if KSK is being rolled), there will be two RRsig

Good catch. RRsig records (or maybe RRsig RRset).

I think we say "DNSKEY RRsets" throughout, so that covers additional
keys/rollovers etc.

> Is there a requirement to order the aliases in order those aliases are

Strictly speaking, DNS protocol specs don't require it. In practice, some
DNS clients balk or fail if they are presented aliases out of order. So
almost all DNS responders order aliases. This is a green field application
though, so we don't need to impose such a requirement, but I'm also okay
with stating that the aliases are ordered.

> are used to sign the DS records.

Ok, yes, the rationale provided for including the trust anchor DNSKEY RRset
is incomplete. As you say, it is also needed to authenticate the ZSKs which
sign delegations. We'll update this text.

> keys are rotated every few months for root, instead of every N years.

Correct, and that's why the entire DNSKEY RRset is always delivered.

> record for the root. Validating with such anchor requires sending the

Also true, and hence the entire DNSKEY RRset is always delivered.

> $ dig +dnssec -t DNSKEY .

[ stuff omitted ]

> _443._tcp, which is the same as one used by HTTPS, right?

I hadn't yet thought of this use case, but wouldn't it be _443._udp since
QUIC runs over UDP? Perhaps a server operator that supports both TLS and
QUIC, wants to have separate server credentials for each. And if not, they
could alias one of the TLSA records to the other.

-- 
Shumon Huque

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 4 Jul 2017 12:14:42 -0400

> On Jul 4, 2017, at 11:33 AM, Shumon Huque <[email-masked]> wrote:
> 
> Yes, in fact the previous sentence to the one you quoted did say this more or less: " ... return a serialized authentication chain in the Certificate message associated with the end entity certificate being validated ". I would propose rewording that a bit and removing the last quoted sentence entirely:
> 
>    serialized authentication chain in the extension block of the Certificate 

Why the end-entity certificate, and not the final certificate
sent by the server?  With anything but DANE-EE(3) the TLSA
records can't be processed against the server's certificate
message until *all* the server certificates have been received.

So instead of squirreling away the DNS data while waiting for
all the server certificates to arrive, it may make more sense
to receive the TLSA records (and associated signatures, CNAMEs,
DNAMEs, ...) once all the server certificates have been received.

Of course either way one still buffers all the server certificates,
so buffering the TLSA records is not a major issue.  It's just that
I don't see a compelling argument for sending the TLSA records with
the EE certificate.  Perhaps send them with any of the server
certificates, it probably makes no difference which...

-- 
	Viktor.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 4 Jul 2017 19:19:18 +0300

> logic that is normatively defined elsewhere.

I think either this should be strengthened or taken out entierely.
Right now it is "the worst of both worlds".
 
> negative proofs associated with wildcards and thus has to deal with NSEC3).

Oh yes. AFAICT (since there is always data):

- If the record is not a wildcard, then no NSEC nor NSEC3 records are
  needed.
- If the record is a wildcard, then one NSEC or NSEC3 record that
  denies the sibling of source that is the ancestor of the QNAME.

But this might very well be wrong!

> Good catch. RRsig records (or maybe RRsig RRset).

Maybe I'm just unfamilier with DNS, but I think RRsig RRset might be
interpretted as set of RRsig records in some name (which is very much
wrong interpretation here). 

> could alias one of the TLSA records to the other.

Yes, QUIC runs over UDP. However, IETF-QUIC will be TLS 1.3, not DTLS.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 4 Jul 2017 19:27:17 +0300

> message until *all* the server certificates have been received.

Well, the optimal would be the certficiate record pertrains to.
However, since RRsets are atomic, this is not possible.
 
> certificates, it probably makes no difference which...

The entiere Certificate message should be loaded into memory anyway.
And one definitely does not want to merge records.

-Ilari

---

From: Shumon Huque <[email-masked]>
Date: Tue, 4 Jul 2017 12:35:54 -0400

On Tue, Jul 4, 2017 at 12:14 PM, Viktor Dukhovni <[email-masked]>
wrote:

> > Yes, in fact the previous sentence to the one you quoted did say this
> more or less: " ... return a serialized authentication chain in the
> Certificate message associated with the end entity certificate being
> validated ". I would propose rewording that a bit and removing the last
> quoted sentence entirely:
> >

I'm not in principle opposed, but intuitively it makes most sense to
associate the DNSSEC chain with the certificate being validated.

The other logical place this might have been placed is  Encrypted
Extensions. But that again precedes the Certificate message, so doesn't
address your buffering up concern.

Also if DANE-EE turned out to be the common use case, it helps right? Cause
the validator doesn't care about the rest of the certificate chain, and can
authenticate the EE cert right away.

> certificates, it probably makes no difference which...

Ok. Let's see if anyone else chimes in with opinions on this ..

-- 
Shumon Huque

---

From: Shumon Huque <[email-masked]>
Date: Tue, 4 Jul 2017 13:18:05 -0400

> Right now it is "the worst of both worlds".

My proposal is to remove the recommendation that the server SHOULD order
records in an RRset. And refer to the normative DNSSEC validation algorithm
for the client. That should take care of this.

> - If the record is not a wildcard, then no NSEC nor NSEC3 records are

Correct.

>   denies the sibling of source that is the ancestor of the QNAME.

The client first needs to determine that a wildcard DNS record was matched
- this can be deduced from the the label count field in the RRSIG record
being less than the label count in the QNAME. It then needs to authenticate
NSEC/NSEC3 records that prove the following facts:  (1) that there is no
exact match of the QNAME and (2) that no closer wildcard could have
matched. Often the same NSEC/NSEC3 record can prove both facts.

> wrong interpretation here).

An RRset is defined as the set of records that share the same name, type,
and class. So an RRsig RRset should cover signatures produced by different
keys for the same RRset. But if this sounds confusing, I'm okay with "RRsig
records".

> Yes, QUIC runs over UDP. However, IETF-QUIC will be TLS 1.3, not DTLS.

You mean IETF QUIC will reuse the TLS 1.3 handshake mechanism right? But
it's still a distinct transport from TLS 1.3 I assume. (I'm a QUIC newbie -
feel free to correct me).

The statement in the draft that the "_udp" label is for DTLS servers might
be too restrictive, and perhaps it should be expanded to include other
secure transports that run over UDP. The TLSA spec (RFC 6698) today only
defines 3 transport labels _tcp, _udp, and _sctp. I'm wondering whether
that needs to be expanded to include things like tls/dtls/quic, and whether
it needs an IANA maintained registry for extensibility.

-- 
Shumon Huque

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 4 Jul 2017 23:50:32 +0300

> matched. Often the same NSEC/NSEC3 record can prove both facts.

When is one NSEC/NSEC3 record (covering the sibling of source that is
the parent) together with the wildcard RRsig records not enough to
prove correctness of wildcard expansion?

(I know it takes 3 NSEC3 records to prove that something does not
exist, but here only cases where something exists are interesting).
 
> keys for the same RRset. But if this sounds confusing, I'm okay with "RRsig

RRsig is special in that it is subtyped in RRdata. I don't know if 
concept of "RRset" is redefined for RRsig to take that into account.

I.e., does RRsig RRset include RRsig's for any possible A records (which
are very much not interesting here)?
 
> feel free to correct me).

Pretty much.

-Ilari

---

From: Shumon Huque <[email-masked]>
Date: Tue, 4 Jul 2017 17:13:38 -0400

> are very much not interesting here)?

I think we need to say the set of RRsig records that "cover" the type in
question."

Shumon.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 7 Jul 2017 10:59:25 -0500

On 06/28/2017 04:15 PM, Joseph Salowey wrote:
> This is the working group last call
> for draft-ietf-tls-dnssec-chain-extension-04.  Please send you
> comments to the list by July 12, 2017.  

Just a couple minor things I don't remember being mentioned already that
I noticed in a quick read:

When section 3.4 mentions that "this document describes the data
structure in sufficient detail that implementors if they desire can
write their own code to do this", it seems that this really on makes
sense when the "this" is for the encoding side, not the decoding side. 
That is, in that we expect future DNS clients to continue to process
responses in the current format, but future DNS servers might generate
responses that cannot be properly decoded just following this document. 
(E.g., what would happen if NSEC5 became popular?)

In section 8:

   Mandating this extension for Raw Public Key
   authentication (where there are no X.509 certificates) could employ
   configuration mechanisms external to the TLS protocol

this sentence structure is a little confusing; it might be better to say something like "If needed, configuration mechanism external to the TLS protocol could be used to mandate the use of this extension for Raw Public Key authentication".

-Ben

---

From: Shumon Huque <[email-masked]>
Date: Fri, 7 Jul 2017 14:31:09 -0400

On Fri, Jul 7, 2017 at 11:59 AM, Benjamin Kaduk <[email-masked]> wrote:

> This is the working group last call for draft-ietf-tls-dnssec-chain-extension-04.
> Just a couple minor things I don't remember being mentioned already that I
> noticed in a quick read:
>
> When section 3.4 mentions that "this document describes the data structure
> in sufficient detail that implementors if they desire can write their own
> code to do this", it seems that this really on makes sense when the "this"
> is for the encoding side, not the decoding side.  That is, in that we
> expect future DNS clients to continue to process responses in the current
> format, but future DNS servers might generate responses that cannot be
> properly decoded just following this document.  (E.g., what would happen if
> NSEC5 became popular?)
>

I think it's best to take that sentence out. It's a remnant of much earlier
versions of the draft where we did describe the decoding (and validation)
side in more detail, whereas now a lot of the client side processing is
being referred to DNSSEC specs.

Regarding future DNSSEC protocol enhancements that may necessitate format
and protocol processing changes, maybe it's best to defer those to future
revisions of the spec. But feel free to propose any specific wording on
this topic for inclusion.

(NSEC5 adoption in DNSOP is still very much an open question. The other
possible enhancement that might need to be considered in the future is
records related to key transparency - "CT for DNSSEC", which could happen
someday.)

> this sentence structure is a little confusing; it might be better to say something like "If needed, configuration mechanism external to the TLS protocol could be used to mandate the use of this ext…
Yes, your suggested text sounds much better. We can incorporate that.

However, there is larger concern that I have with section 8 that probably
deserves working group discussion. This section might imply that there is a
(protocol resident) way to mandate the use of this extension, but I don't
think there is an easy way. Even in the case of X.509 certificates, the TLS
feature extension can only dictate the delivery of this extension when the
client has connected to the right server presenting that certificate.

A TLS client misdirected to a rogue TLS server (e.g. via DNS spoofing, a
routing attack, or other means) that has fraudulently acquired a public CA
issued certificate for the legitimate server name, could be induced to
establish a (PKIX) verified connection to that rogue server that precludes
DANE authentication, when in fact it was available.

Some TLS applications may desire to mandate DANE authentication where
available, and protect themselves against malicious or tricked CAs. What is
the best way to accommodate them? TLS clients could keep a whitelist of
DANE servers, which doesn't scale very far; they could use TOFU/HPKP like
methods: add DANE supporting sites to a whitelist dynamically as they are
seen, etc.

Some other applications use the presence of an authenticated TLSA record to
enforce DANE authentication (RFC 7672 for SMTP STARTTLS). The last time
this was discussed in the context of tls-dnssec-chain, it was argued that
this "mandatory use" was not a semantic that the generic TLSA record
provides, so only specific applications should specify that behavior. But
if a specific TLS application using this extension did want to specify this
behavior, how could it happen?

In a hypothetical world where all TLS clients & servers understood this
extension, we could have required the TLS server to either (1) present the
dnssec_chain for their TLSA record, or (2) present a dnssec_chain that
demonstrates that there is no secure TLSA record, or that there is no
secure delegation to the zone. I think this would solve the problem, but
this isn't practical any time soon (or perhaps ever).

I'm not suggesting that we need to come up with a solution for this, but I
believe the issue probably needs some sort of mention somewhere (in
Security Considerations?).

-- 
Shumon Huque

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 7 Jul 2017 13:51:03 -0500

On 07/07/2017 01:31 PM, Shumon Huque wrote:
> I'm not suggesting that we need to come up with a solution for this,
> but I believe the issue probably needs some sort of mention somewhere
> (in Security Considerations?).

Sounds good to me.

-Ben

---

From: Tom Ritter <[email-masked]>
Date: Fri, 7 Jul 2017 14:13:28 -0500

As a note, I didn't see anything in this draft (from a quick read)
that precludes any of DANE's Certificate Usage, Selector, or Matching
Type fields. If that's not the case, perhaps someone can correct me.

   A client must not be able to force a server to perform lookups on
   arbitrary domain names using this mechanism.  Therefore, a server
   MUST NOT construct chains for domain names other than its own.

What about the reverse? Do we care about a server tricking a client
into priming its DNS cache?

-tom

On 28 June 2017 at 16:15, Joseph Salowey <[email-masked]> wrote:
> draft-ietf-tls-dnssec-chain-extension-04.  Please send you comments to the
> list by July 12, 2017.
>
> Thanks,
>
> J&S
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Shumon Huque <[email-masked]>
Date: Fri, 7 Jul 2017 16:01:52 -0400

> Type fields. If that's not the case, perhaps someone can correct me.

Yes, that's correct. Is there any reason it should?

TLS applications are free to preclude the use of DANE parameters, but a
more general purpose protocol I feel probably should not. The draft does
refer several times to RFC 7671 (DANE updates and operational guidelines),
which has some recommendations which ought to be followed.

> -tom

Yes, we want to avoid that, but I would expect that any sane client
implementation, as a basic precaution, would only accept a DNSSEC chain
corresponding to the TLSA name that it expected to see. If the server
presented anything else, it would not be considered invalid. Similarly, if
the chain included embedded unexpected extraneous records, I would expect
the client implementation to ignore those (or even invalidate the whole
chain if it wanted to be more draconian). If necessary, we could have
explicit text about this.

-- 
Shumon Huque