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

[Ilari Liusvaara <[e-mail]>]

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