Skip to main content

Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
draft-ietf-uta-email-deep-12

Yes

(Spencer Dawkins)

No Objection

Warren Kumari
(Alia Atlas)
(Suresh Krishnan)

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

Warren Kumari
No Objection
Adam Roach Former IESG member
Yes
Yes (2017-10-23 for -09) Unknown
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.
Alexey Melnikov Former IESG member
Yes
Yes (2017-10-26 for -09) Unknown
Also need to decide weather UDP ports 993 and 995 should be released for allocation by IANA.
Alissa Cooper Former IESG member
Yes
Yes (2017-10-24 for -09) Unknown
It looks like there are some Gen-ART comments that have yet to be incorporated into the document.
Ben Campbell Former IESG member
Yes
Yes (2017-10-24 for -09) Unknown
I am balloting YES because I believe it is important to publish this. But there are a few issues I think should be resolved first:

Substantive:

-2: There are several instances of lower case versions of 2119 keywords. If those are intentional, then please use the updated boilerplate from 8174.

-4.1, last paragraph: "It is RECOMMENDED that new users be required to use TLS version 1.1
   or greater from the start."
Is 1.1 correct? Why not start with 1.2?

-5, bullet starting with: MUAs SHOULD provide a prominent visual indication "
This section seems to merit a MUST NOT level requirement about displaying the visual indication without sufficient evidence of confidentiality.

-5.4: I'm confused at why certificate pinning is okay for explicitly invalid certificates, when click-through overrides were previously recommended against. It seems like the same level of abuse is likely. (It's one thing to allow a user to set policy for an invalid cert; it's another to prompt them to do so.)

-5.5: How would a client determine that a client cert could be safely used with a particular server? (What does "safely" mean in this context?)

Editorial:

- Abstract: Please mention the updated RFCs

-4: "The following practices are recommended "
There are some MUSTs in those practices. That makes them required, not merely recommended.

-4, first and third bullets: s/ which / that

-4.1, first paragraph: The two "MAYs" seem more like statements of fact.

-5, 3rd bullet: "MUAs MUST NOT consider "
s/consider/treat   (unless we are talking about humans are AIs :-)  )
Eric Rescorla Former IESG member
Yes
Yes (2017-10-20 for -09) Unknown
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.
Kathleen Moriarty Former IESG member
Yes
Yes (2017-10-23 for -09) Unknown
Thank you very much for your work on this document!!! 

I agree with EKR's suggested edits.
Mirja Kühlewind Former IESG member
Yes
Yes (2017-10-23 for -09) Unknown
The document reads like a BCP to me. Was it discussed in the group to go for BCP? If yes, why was it decided to go not for BCP? If no, I would strong recommend for BCP.

Nits:
1) sec 4.1: "The specific means employed for deprecation of cleartext Mail Access
   Services and Mail Submission Services MAY vary from one MSP to the
   next..."
I guess this should rather be lower case "may" but the RFC editor might have caught that as well. 

2) Also sec 4.1:
"It is RECOMMENDED that new users be required to use TLS version 1.1
   or greater from the start. "
Should this be TLS1.2 or maybe a MUST? Just double-checking.

3) This document should probably have a reference to DNSSEC, I guess that's rfc4033...

4) sec 5.2:
"The default minimum expected level of confidentiality for all new
   accounts SHOULD be at least use of TLS version 1.1 or greater, and
   successful validation of the server's certificate."
Given this sentence defines the default minimum, I would have expected a MUST here? Or should this maybe be "MUST use TLS1.1 or greater" and "SHOULD do certificate validation"? However, what's the case were you wouldn't do it as the default minimum?

5) s/were not met by the connecting/were not met by the connection/

6) In section 5.4, should there maybe be a recommendation that a MUA should also offer a way for a user to remove the pinning, e.g. if it was detected later on that a wrong cert had been pinned?

7) sec 6: is there a useful reference to the milter protocol that can be provided?
Spencer Dawkins Former IESG member
Yes
Yes (for -09) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2017-10-25 for -09) Unknown
(1) Why isn't this document a BCP?  The document talks in many places about recommendations that it makes (not behavior that it specifies) — and even the Shepherd’s write up says that it "closely matches much of current practice for how mail services are operated.” 

(2) In 4.1 the use of “MAY” seems out of place to me, not just because the text is not specifying anything, but because it is just stating the fact that things can be different:

   The specific means employed for deprecation of cleartext Mail Access
   Services and Mail Submission Services MAY vary from one MSP to the
   next in light of their user communities' needs and constraints.
Benoît Claise Former IESG member
No Objection
No Objection (2017-10-22 for -09) Unknown
There are still some points that need to be discussed part of Carlos' OPS DIR review.
Suresh Krishnan Former IESG member
No Objection
No Objection (for -09) Unknown