Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols
RFC 7817

Note: This ballot was opened for revision 07 and is now closed.

(Ben Campbell) Yes

Comment (2015-12-16 for -07)
No email
send info
- section 3, first paragraph:
MiTM prevention is just one of many reasons to match the reference identifier, right?

-5.1:
It might be worth mentioning that the methods in this draft require the provider to manage private keys for the tenant domains. 

- Informative References:
Please consider whether 2595, 5234, and 6066 should be normative references.

Editorial and Nits:
-2, Reference Identifier:
I agree with Barry's comments. Additionally, do you need the 2119 MUST in the definition? It seems like that belongs in the related requirements/procedures section.

-4.1: This section needs more proofreading\. Here's some things I found, but I may have missed stuff.
-- "manual confirm exception" -> "manually confirm exceptions"
-- "because TLS server certificate verification" - Missing "the" before TLS
-- "failure to match TLS server certificate against the expected domains" - missing "the" before TLS. Should "domains" be singular?
-- "for example.org domain" - missing "the" before "example.org"
-- "this solution depends reliance of DNSSEC " - I don't understand the phrase
-- "The ability of issuing certificates that contain SRV-ID implies..." - I don't understand the phrase.

- 5: Lots of sentence fragments in the numbered list items. That's not necessarily wrong, but mixing them up like this makes it harder to read. (At least for me.)

(Stephen Farrell) Yes

(Barry Leiba) (was Discuss) Yes

Comment (2015-12-15 for -07)
No email
send info
In the Introduction, you say that ths document replaces Section 2.4 of RFC 2595.  It appears that it's specifically Section 3 that replaces that section.  Maybe it's best to say that?

-- Section 2 --

   reference identifier:  (as defined in [RFC6125]) One of the domain
      names associated by the email (i.e., an SMTP, IMAP, POP3 or
      ManageSieve) client with the target email server and optionally an
      application service type for performing name checks on the server
      certificate.

1. You refer to the definition in 6125 as though you're repeating it here, but you're not: you're giving a different definition.  Maybe if you said "formally defined in RFC 6125" instead, it'd be clearer that this explanation is applying that formal definition to this specific situation (email).

2. It's usually bad to put a parenthesized explanation in the middle of a unit, and "email client" is a unit here.  (And, as almost always, I think "i.e." is unnecessary and further distracting.)

3. The sentence is long and awkward, saying "associated by... with... and optionally...," and it's easy to get lost.

Here's a suggestion:
NEW
   reference identifier:  (formally defined in [RFC6125]) One of the
      domain names that the email client (SMTP, IMAP, POP3 or ManageSieve)
      associates with the target email server.  The identifier can also
      include an application service type for performing name checks on
      the server certificate.
END

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Deborah Brungard) No Objection

(Benoît Claise) No Objection

Comment (2015-12-16 for -07)
No email
send info
Bert Wijnen's OPS DIR review, on which Alexey promised to act:
> Hi I did the OPS-Directorate review fordraft-ietf-uta-email-tls-certs-07
>
> In general, I think this document is more or less ready to be published.
>
> I do believe that section 5 does touch on a number of operational
> aspects (and specifically about scaling). The title of that section
> however is:
>     Compliance Checklist for Mail Service Providers and Certificate
>     Signing Request generation tools
> So it may not immediately attract attention from operators so that
> they can see operational aspects. Maybe that could be pointed out
> somewhere in the document.
>
> Section 5 also states that this document and its predecessors
> "don't address scaling issues caused by use of TLS in multi-tenanted
> environments." And it states that further work is needed in that space.
> That is another operational aspect that may need to be pointed out
> specifically to operators.
>
> So maybe these 2 points can be highlighted in a saparate small sectoin
> titled "Operational Considerations".
> Just thinking aloud here. The point s have been made, but such a small
> section qould quickly point operators to the proper places for info.

Sounds like a good idea, I will add.

(Alissa Cooper) No Objection

(Spencer Dawkins) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Comment (2015-12-15 for -07)
No email
send info
Bert Wijnen performed the opsdir review.

(Terry Manderson) No Objection

Alvaro Retana No Objection

Comment (2015-12-17 for -08)
No email
send info
Maybe it's just me..

This document starts very specifically saying what it's updating/replacing, but then I didn't find references in the text that said things like "this section replaces..." -- this made it hard to clearly figure out the changes.

(Martin Stiemerling) No Objection