Subject: [Uta] Last Call: <draft-ietf-uta-email-deep-09.txt> (Cleartext Considered Obsolete: Use of TLS for Email Submission and Access) to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 29 Sep 2017 08:54:04 -0700

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'
  <draft-ietf-uta-email-deep-09.txt> 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
[email-masked] mailing lists by 2017-10-13. Exceptionally, comments may be
sent to [email-masked] 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.

---

From: Stephan Bosch <[email-masked]>
Date: Fri, 29 Sep 2017 20:34:37 +0200

Hi,

>    traffic between a mail user agent (MUA) and a mail submission or mail

I haven't followed the discussions and I hadn't seen this document until
I saw this last call. But after reading it, I have one question: what
about ManageSieve (RFC5804)? Arguably, it is not a mail submission nor a
mail access protocol, but it would be a service (often) operated along
with those functions. Most notably, ManageSieve currently only supports
STARTTLS and not the implicit TLS prescribed in this document; no
well-known port is assigned for that purpose. Therefore, systems
supporting ManageSieve along with the protocols mentioned would have a
weakness (which could perhaps be used to access the other services as
well). It is unlikely that a ManageSieve client would support implicit
TLS without some IETF specification.

Is that going to be addressed in a separate document?

Regards,

Stephan.

---

From: "Chris Newman" <[email-masked]>
Date: Fri, 29 Sep 2017 12:55:15 -0700

> Is that going to be addressed in a separate document?

We choose not to specifically mention less widely used protocols in this 
space such as manage sieve (RFC 5804) and MTQP (RFC 3887) to keep the 
document concise. But section 4 & 5 have catch-all language which covers 
these protocols.

		- Chris

>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Duta-2Demail-2Ddeep_&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=QBZgPENFbjFadxqU4HJ3ZDpRz3X1JlDY-keqMt52FFo&m=tLH8lmlu0cQavkNgSBfaMxleT-TVp1GxhPyb2Mtq7wc&s=jHtWApWkrUxoPy6YHnpRCEhQgbAd-QHULEzPCRuzMTo&e=
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Duta-2Demail-2Ddeep_ballot_&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=QBZgPENFbjFadxqU4HJ3ZDpRz3X1JlDY-keqMt52FFo&m=tLH8lmlu0cQavkNgSBfaMxleT-TVp1GxhPyb2Mtq7wc&s=1d8Y1OB22fSwqQcTpVPBXgRJojnPNhR-CxF6HFNHsZQ&e=
>>
>>