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
>>>  -----------------------------------------------------------------
>>>  -----
>>>  -----------------------------------------------------------------
>>>  -----
>>>  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,
TLS mailing list

Reply via email to