Hi, On Wed, Feb 21, 2018, at 4:06 PM, Shumon Huque wrote: > 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.
I think adding some text explaining this would be a good addition to the document. Best Regards, Alexey
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
