On Tue, Jul 28, 2015 at 6:15 PM, Viktor Dukhovni <[email protected]>
wrote:
> On Tue, Jul 28, 2015 at 05:05:22PM -0500, Nico Williams wrote:
>
> > > All the CNAME records need to be validated, not just the final
> > > TLSA RRset.
> >
> > Sure. The CNAMEs should be in the answer section too, no?
>
> Yes, in the answer section. Otherwise it is difficult for the
> client to navigate the response from its reference identifier domain
> (signalled via a mandatory SNI extension) to the actual TLSA RRset
> in the server's answer (which may be two layers of CNAMEs away).
>
> server-name0. -> server-name1. -> ... -> server-name-N. ==
> tlsa-base-domain.
> _port._proto.tlsa-base-domain. -> ... ->
> _ultimate._tlsa.owner-name.
> _ultimate._tlsa.owner-name. IN TLSA 3 1 1 <blob>
>
> Both CNAME chains and the TLSA RRset go in the answer section, all
> supporting RRSIG/DNSKEY/DS records are additionals. There's a
> draft from Shore, Huque et. al., that is evolving, ideally to spell
> out all the detail.
>
In case others missed it, it's the following draft:
https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-01
Debate is going on about the precise format of the chain data. The draft
currently doesn't use DNS "messages", but rather wire format DNS RRs
wrapped in a bit of TLS presentation syntax, but we're discussing other
possibilities. If we were to use DNS messages, there is already a proposal
from Paul Wouters which we might also look into:
https://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-02
I've already stated my personal preference for a chain of wire format DNS
RRs that could be fed into existing DNS library functions, but I'd like to
come to a consensus that is acceptable to most of the likely implementers.
One concern we've heard is that some folks don't want to import a large DNS
library into their application that has a whole of bunch of unnecessary
code (e.g. all the DNS transport code).
> > be OK if they were in the additional section. The point is that all of
> > them have to be in there. An alternative would be to have multiple DNS
> > responses, one for each CNAME and one for the TLSA RRset. The latter
> > might be necessary if 64KB is not enough to store the entire stapling.
> > Thoughts?
>
> The data will need to (and I expect will) fit into 16K so, it can
> go into a TLS handshake message. To that end, and in any case,
> the extension should I think support DNS name "compression", and
> should be encouraged to do use it (the draft says otherwise at
> present).
>
>
Right, it says to uncompress the names right now. Name compression is
defined in terms of pointers to offsets from the beginning of the DNS
message. Since we don't currently use DNS messages, we'd have to redefine
name compression to be something else, like an offset from the beginning of
the chain data structure. That would probably be fine, but I wonder if it's
really worth it. The size of the chain is likely going to be dominated not
by domain names, but by all the DNSSEC signatures, which aren't very
compressible.
Another method of reducing the chain size we are considering is client side
caching of RR sets and server side omission of the same.
Shumon.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
