On Tue, Jul 04, 2017 at 11:33:45AM -0400, Shumon Huque wrote:
> 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:
>
> 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.
I think either this should be strengthened or taken out entierely.
Right now it is "the worst of both worlds".
> (Perhaps RFC 5155 should also be mentioned now that this spec accommodates
> 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!
> > 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).
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).
> 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.
Yes, QUIC runs over UDP. However, IETF-QUIC will be TLS 1.3, not DTLS.
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
