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 details.
> 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).
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
