Subject: [Uta] Benjamin Kaduk's No Objection on draft-ietf-uta-smtp-require-tls-09: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Fri, 02 Aug 2019 15:06:48 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-uta-smtp-require-tls-09: No Objection

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-uta-smtp-require-tls/

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

Thank you for resolving my Discuss points!

I do think the added text in Section 4.2.1 about DNS-ID/CN-ID should
probably be clarified that it only applies to the RFC 6125 procedures and
not the RFC 7672 ones.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 2 Aug 2019 15:18:39 -0700

Thanks for your review.

Since RFC 7672 (section 1.1, definition of "Reference identifier") calls
out the use of use of CN-ID if no DNS-ID (subjectAltName of type
dNSName) is present, I don't really see a conflict between the wording
in the draft and 7672. Or is the concern that we shouldn't be allowing
the use of CN-ID if DNS-ID is present?

I have always thought that the "alternative" nature of subjectAltName
means that those names are allowed to be used in addition to commonName,
but I guess that isn't really the way things work.

-Jim

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 2 Aug 2019 17:30:47 -0500

> the use of CN-ID if DNS-ID is present?

I could be mistaken, but my understanding was that for DANE, the "reference
identifier" (compared against the DNS-ID/CN-ID) was not necessarily going
to be the result of an MX lookup (or A record fallback).  So I wasn't
concerned about the DNS-ID/CN-ID part per se, but the other part of the
added text -- that was just a convenient way to refer to the chunk that
changed.

> but I guess that isn't really the way things work.

It's a natural assumption!  I guess that the commonName was defined without
the benefit of many years of deployment experience (and without knowledge
of the craziness that the modern Internet has become!), so it's just not
well suited for (many of) the situations we work in anymore.  The
subjectAltName is more flexible and has survived the disruption better.
(Not that I was around for the start of it, of course...)

-Ben