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. > 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
