On Wed, Feb 7, 2018 at 9:05 PM, Shumon Huque <shu...@gmail.com> wrote:
> On Wed, Feb 7, 2018 at 1:22 PM, Alexey Melnikov <aamelni...@fastmail.fm> > wrote: > >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-tls-dnssec-chain-extension-06: Discuss >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I think this is a useful document and I will ballot Yes once my small >> issues are resolved: >> >> 1) In 3.4: >> >> 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. DNAME chains should omit >> >> SHOULD? What are the implications if this is not followed? >> > > Ok. I guess we need the upper case word here, yes. > > Implication: If the synthesized CNAME records are included in the chain > then the client will have to ignore them (they aren't signed and thus > can't be > validated) - the signed DNAME record is sufficient for the client to > securely > validate the mapping and continue processing. > > It might make things simpler to just make this a MUST. I would guess this > would not raise any objections from the working group. > A quick follow-up on this. I think we just keep this as a SHOULD. I looked at what an existing DNS library implementation does, and it includes the synthesized CNAME. It's easy enough for the client to just ignore it when validating the chain. Shumon.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
