Subject: [Uta] Adam Roach's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Mon, 23 Oct 2017 20:45:05 -0700

Adam Roach has entered the following ballot position for
draft-ietf-uta-email-deep-09: Yes

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-email-deep/

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

Balloting "Yes" because I think this is a very welcome and important update to
its antecedent documents -- but I think there are a few simple changes needed
before it's ready to go.

Most importantly; section 3.2 contains the following text:

   Clients MUST
   implement the certificate validation mechanism described in [RFC3501]
   and SHOULD implement the certificate validation mechanism described
   in [RFC7817].

I'm not sure this is kosher. The relevant portion of RFC3501 has been removed
by RFC7817 and replaced by the procedures from RFC7817. My understanding is
saying that you MUST implement RFC3501 for validation implies that you MUST
implement RFC7817 for validation, since RFC3501 has been formally updated.
Putting them at different normative levels in this document doesn't make sense.

____

Section 4.3 says what the "value included in this additional clause SHOULD be"
but doesn't indicate that the clause itself SHOULD be included. I assume this
is an oversight?

Sections 4.5 and 4.5.1 use the word "recommended" in a non-normative fashion
(correctly, I believe). For avoidance of doubt, I recommend replacing the
RFC2119 boilerplate with the newer RFC8174 boilerplate.

Section 4.5.3 normatively specifies the use of DNSSEC, which makes some or all
of RFCs 4033-4035 normative references, I believe.

Section 4.5.4 normatively specifies the use of TLSA, which makes RFC6698 a
normative reference, I believe.

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Oct 2017 00:13:11 -0400

I think Chris wrote this text, so perhaps he will comment.  I'm guessing 
that 7817 was new enough at the time the text was written that making it 
a MUST requirement seemed a bit much to ask.  "MUST 7817" is probably 
more reasonable by now.

> RFC2119 boilerplate with the newer RFC8174 boilerplate.
agree, this will be fixed in -10
> of RFCs 4033-4035 normative references, I believe.
I already added a reference to 4033 in -10 and will consider adding the 
others.
> normative reference, I believe.
good catch; thanks.

Keith

---

From: "Chris Newman" <[email-masked]>
Date: Tue, 24 Oct 2017 10:38:11 -0700

On 23 Oct 2017, at 21:13, Keith Moore wrote:

> I think Chris wrote this text, so perhaps he will comment.  I'm 
> guessing that 7817 was new enough at the time the text was written 
> that making it a MUST requirement seemed a bit much to ask.  "MUST 
> 7817" is probably more reasonable by now.

That was written when the document was an Internet draft. I'm fine with 
MUST 7817 now.

		- Chris

> I already added a reference to 4033 in -10 and will consider adding 
> the others.