Subject: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

From: Alexey Melnikov <[email-masked]>
Date: Wed, 07 Feb 2018 10:22:44 -0800

Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-dnssec-chain-extension-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/

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

   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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The first mention of NSEC3 need a normative reference.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 7 Feb 2018 21:05:14 -0500

> draft-ietf-tls-dnssec-chain-extension-06: Discuss

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.

> 2) TLS 1.3 needs to be a normative reference, but it is not even listed in

Ok, we will add it.

Yup, will do [RFC 5155]

Shumon Huque

---

From: Shumon Huque <[email-masked]>
Date: Wed, 21 Feb 2018 11:06:49 -0500

On Wed, Feb 7, 2018 at 9:05 PM, Shumon Huque <[email-masked]> wrote:

> then the client will have to ignore them (they aren't signed and thus
> can't be

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.