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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
