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

[Ballot comment]
(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.

[Ballot comment]
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 :-)  )

[Ballot 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.

[Ballot comment]
Balloting "Yes" because I think this is a very welcome 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.

[Ballot comment]
Balloting "Yes" because I think this is a very welcome update to its antecedent documents -- but I think there are a few minor tweaks 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.

[Ballot comment]
Balloting "Yes" because I think this is a very welcome update to its antecedent documents -- but I think there are a few 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.

[Ballot comment]
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?

[Ballot 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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-uta-email-deep-09. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the Service Name and Transport Protocol Port Number Registry located at

https://www.iana.org/assignments/service-names-port-numbers/

the registration of the TCP well-known port 995 will be amended using the following template based on [ RFC 6335 ]:

Service Name: pop3s
Transport Protocol: TCP
Assignee: IETF
Contact: IESG
Description: POP3 over TLS protocol
Reference: [ RFC-to-be ]
Port Number: 995

Second, also in the Service Name and Transport Protocol Port Number Registry located at

https://www.iana.org/assignments/service-names-port-numbers/

the registration of the TCP well-known port 993 will be amended using the following template based on [ RFC 6335 ]:

Service Name: imaps
Transport Protocol: TCP
Assignee: IETF
Contact: IESG
Description: IMAP over TLS protocol
Reference: [ RFC-to-be ]
Port Number: 993

IANA QUESTION: Should there be any changes to the UDP port for 995 and 993? Should the contact changes apply to those as well?

Third, also in the Service Name and Transport Protocol Port Number Registry located at

https://www.iana.org/assignments/service-names-port-numbers/

the registration of the TCP well-known port 465 will be amended to have an alternate usage using the following template based on [ RFC 6335 ]:

Service Name: submissions
Transport Protocol: TCP
Assignee: IETF
Contact: IESG
Description: Message Submission over TLS protocol
Reference: RFC XXXX (this document once published)
Port Number: 465

The IANA Services Operator understands that these three actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-10-13):

From: The IESG
To: IETF-Announce
CC: uta@ietf.org, alexey.melnikov@isode.com, uta-chairs@ietf.org, leifj@sunet.se, draft-ietf-uta-email-deep@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Cleartext Considered Obsolete: Use of TLS for Email Submission and Access) to Proposed Standard


The IESG has received a request from the Using TLS in Applications WG (uta)
to consider the following document: - 'Cleartext Considered Obsolete: Use of
TLS for Email Submission and
  Access'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-10-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This specification outlines current recommendations for use of
  Transport Layer Security (TLS) to provide confidentiality of email
  traffic between a mail user agent (MUA) and a mail submission or mail
  access server.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-uta-email-deep/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-uta-email-deep/ballot/


No IPR declarations have been submitted directly on this I-D.