Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
Hi, On Wed, Feb 21, 2018, at 4:06 PM, Shumon Huque wrote: > On Wed, Feb 7, 2018 at 9:05 PM, Shumon Huque wrote:>> On > Wed, Feb 7, 2018 at 1:22 PM, Alexey Melnikov >> 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
Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
On Wed, Feb 7, 2018 at 9:05 PM, Shumon Huque wrote: > On Wed, Feb 7, 2018 at 1:22 PM, Alexey Melnikov > 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
Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
On Wed, Feb 7, 2018 at 1:22 PM, Alexey Melnikov 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. >unsigned CNAME records that may have been synthesized in the response >from a DNS resolver. > > 2) TLS 1.3 needs to be a normative reference, but it is not even listed in > References. > Ok, we will add it. > -- > COMMENT: > -- > > The first mention of NSEC3 need a normative reference. > Yup, will do [RFC 5155] Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
