On Sun, Jul 2, 2017 at 10:03 AM, Ilari Liusvaara <ilariliusva...@welho.com>
wrote:
> 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?
>
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.
> 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.
>
I agree.
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.
>
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).
> 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.
>
Yes, we can state that more explicitly.
>
> 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.
>
Good catch. RRsig records (or maybe RRsig RRset).
I think we say "DNSKEY RRsets" throughout, so that covers additional
keys/rollovers etc.
> 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?
>
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.
> 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.
>
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.
> 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.
>
Correct, and that's why the entire DNSKEY RRset is always delivered.
> Furthermore, frequently the trust anchor is provisioned as a fake DS
> record for the root. Validating with such anchor requires sending the
> root DNSKEY.
>
Also true, and hence the entire DNSKEY RRset is always delivered.
> Real-world zone data (omitted the cryptographic line noise, and added
> some hilights):
>
> $ dig +dnssec -t DNSKEY .
>
[ stuff omitted ]
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?
>
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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
