[Uta] Eric Rescorla's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla 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:
----------------------------------------------------------------------

Line 15
   This specification outlines current recommendations for use of
   Transport Layer Security (TLS) to provide confidentiality of email
Nit: "the use"

Line 103
   not use it in a way that maximizes end-user confidentiality.  This
   specification describes current recommendations for use of TLS in
   interactions between Mail User Agents and Mail Access Services, and
Nit: "the use"

Line 186
   TLS, and to encourage a greater consistency for how TLS is used, this
   specification now recommends use of Implicit TLS for POP, IMAP, SMTP
   Submission, and all other protocols used between a Mail User Agent
Do you want to say RECOMMENDED?

Line 199
   greeting, the server and client MUST enter AUTHORIZATION state, even
   if client credentials were supplied during the TLS handshake.
You mean TLS client certificates here, right? Maybe say so

Line 214
   remainder of the TCP connection.  If client credentials were provided
   during the TLS handshake that the server finds acceptable, the server
   MAY issue a PREAUTH greeting in which case both the server and client
Same comment above about client credentials == certs.

Line 304
      preference to services supporting STARTTLS (if offered).  (See
      also Section 4.5.)
I note that 6186 is kind of unclear on what should go in SNI. It obviously
needs to be what you are checking against (which 6186 gets right) but maybe
it's worth clarifying in this document somewhere.

Line 328
      the TLS ciphersuite of the session in which the mail was received,
      in the Received field of the outgoing message.  (See Section 4.3.)
Do you want to also suggest that it include the name of the DH group, if any?

Line 363
   refuse a ClientHello message from any client sending a protocol
   version number corresponding to any version of SSL or TLS 1.0.
   Another way is for the server to accept ClientHello messages from
It's worth being very clear that you mean ClientHello.version, not the record
version, as this has created a lot of interop problems.

Line 405
   implementation does not know the name of the cipher suite (a
   situation that should be remedied promptly), a four-digit hexadecimal
   cipher suite identifier MAY be used.  The ABNF for the field follows:
Hard to see how you could realistically get into this state...

Line 518
      [RFC7525], TLS 1.1 (or earlier) SHOULD NOT be used unless no
      higher version is available during TLS protocol negotiation.
This text doesn't quite seem right, as the client has no idea what the server
supports, it just knows what it negotiated. Can you explain how this would be
implemented?

Line 594
   accounts SHOULD be at least use of TLS version 1.1 or greater, and
   successful validation of the server's certificate.  (Future revisions
   to this specification may raise these requirements or impose
This second requirement is more important.

Line 672
   the such confidentiality is provided.  Additional advice on
   certificate pinning is present in [RFC6125].
Wow, we have a terrible name clash here, because we also have HPKP which
everyone calls "pinning". I see 6125 calls it that, so maybe on first use (S
5.3) can you please differentiate from HPKP

Line 679
   TLS handshake unless the server requests one and the client has
   determined the certificate can be safely used with that specific
   server, OR the client has been explicitly configured by the user to
Can you note that this is just a restatement of the rules in TLS?

Line 681
   server, OR the client has been explicitly configured by the user to
   use that particular certificate with that server.  How to make this
   determination is presently implementation specific.
The structure of this text is confusing. The rule is:

if (server asked &&
    (client determined safe || certificate configured)) {
    can use
} else {
    can't use
}

Line 781
   or interception; this is not intended to mitigate active attackers
   who have compromised service provider systems.
IMPORTANT: Client auth with TLS 1.2 reveals the user's identity. This is a
privacy issue, and so we need to note it. The options here are not great with <
1.3 because renegotiation is also bad, so I'm not suggesting a normative
change, but I think the doc needs to be clear.

Line 959
   in RFC 6186 resolves that critique for email.  The second bullet is
   correct as well, but not very important because useful deployment of
   security layers other than TLS in email is small enough to be
The second bullet is less correct than it used to be because we no longer
support export suites. Ordinarily I wouldn't bother to make this point, but if
we're revisiting this point by point, I think we should note that.