Subject: [saag] UTA WG report

From: Orit Levin <[email-masked]>
Date: Thu, 30 Mar 2017 19:13:05 +0000

UTA WG met on Tue. All agenda topics relate to using TLS with e-mail protocols.

MTA-MTA interface: The drafts are very close to WG LC. The only real open issue remains the choice between Jason and tag-value format. Implementers choice is split 50/50. Vast majority (if not all) are OK with implementing either. The AD (Alexei) will suggest specific syntax for tag-value format. All interested parties (i.e., potential implementers) are encouraged to chime in on UTA list because we will be resolving this last issue in the upcoming weeks and moving the draft to LC.

MUA-MTA interface: the draft has been further updated. The relevancy (and the complexity) of the proposed protocol has been questioned during the meeting. Even if the answer is "irrelevant", the BCP part of the draft is still very useful. The authors will investigate and proceed according to the results. (Potentially, the draft could be shorten or split and the status changed to BCP, Experimental, or both.)

REQUIRE-TLS draft: the draft has been discussed and found valuable for specific critical cases. It was suggested to continue working on the draft with an intent to be adopted by UTA or other (new) WG going forward.

Orit.

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Mar 2017 15:41:52 -0400

As co-author of this document, I frankly don't understand what the "BCP 
part" of draft-ietf-email-deep-06 is.   BCP is appropriate for process 
documents, or for specifications that don't lend themselves to 
interoperability testing and thus cannot progress to full standard.  
Neither of those is the case for deep.

The assertion was made by one of the meeting attendees that the goals of 
this specification can be met by mail service providers (MSPs) 
incrementally blocking access to customers whose mail user agents (MUAs) 
don't negotiate TLS.   While I acknowledge that one MSP has successfully 
employed this strategy, I personally wonder how well this works for very 
large MSPs.  To me it seems like the customer support burden would be 
substantial.   But I'm working on getting feedback on the draft - both 
from implementors of widely-used MUAs, and from other MSPs - to see what 
they say about the draft.

Regardless of whether this protocol gets support from implementors, I 
would not consider this work finished until we have consensus on how to 
upgrade all MUA-server traffic to use TLS 1.1 or better, and have 
confidence that this will enable us to deprecate cleartext and TLS <= 
1.0 access to these services within a year or two.

Of course, if there's general agreement among MSPs that they can do this 
without changes to MUAs and servers, so much the better.    But the work 
isn't done until we have consensus on a way forward (whether it happens 
in UTA or not).

Keith

On 03/30/2017 03:13 PM, Orit Levin wrote:
> MTA-MTA interface: The drafts are very close to WG LC. The only real 
> open issue remains the choice between Jason and tag-value format. 
> Implementers choice is split 50/50. Vast majority (if not all) are OK 
> with implementing either. The AD (Alexei) will suggest specific syntax 
> for tag-value format. All interested parties (i.e., potential 
> implementers) are encouraged to chime in on UTA list because we will 
> be resolving this last issue in the upcoming weeks and moving the 
> draft to LC.
>
> MUA-MTA interface: the draft has been further updated. The relevancy 
> (and the complexity) of the proposed protocol has been questioned 
> during the meeting. Even if the answer is “irrelevant”, the BCP part 
> of the draft is still very useful. The authors will investigate and 
> proceed according to the results. (Potentially, the draft could be 
> shorten or split and the status changed to BCP, Experimental, or both.)
>
> REQUIRE-TLS draft: the draft has been discussed and found valuable for 
> specific critical cases. It was suggested to continue working on the 
> draft with an intent to be adopted by UTA or other (new) WG going 
> forward.
>
> Orit.
>
>
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Orit Levin <[email-masked]>
Date: Thu, 30 Mar 2017 20:50:26 +0000

Keith,
Great intro to gathering the very much needed feedback.
Adding UTA so we can continue the discussion there.
Thanks,
Orit.

From: saag [mailto:[email-masked]] On Behalf Of Keith Moore
Sent: Thursday, March 30, 2017 12:42 PM
To: [email-masked]
Subject: Re: [saag] UTA WG report

As co-author of this document, I frankly don't understand what the "BCP part" of draft-ietf-email-deep-06 is.   BCP is appropriate for process documents, or for specifications that don't lend themselves to interoperability testing and thus cannot progress to full standard.  Neither of those is the case for deep.

The assertion was made by one of the meeting attendees that the goals of this specification can be met by mail service providers (MSPs) incrementally blocking access to customers whose mail user agents (MUAs) don't negotiate TLS.   While I acknowledge that one MSP has successfully employed this strategy, I personally wonder how well this works for very large MSPs.  To me it seems like the customer support burden would be substantial.   But I'm working on getting feedback on the draft - both from implementors of widely-used MUAs, and from other MSPs - to see what they say about the draft.

Regardless of whether this protocol gets support from implementors, I would not consider this work finished until we have consensus on how to upgrade all MUA-server traffic to use TLS 1.1 or better, and have confidence that this will enable us to deprecate cleartext and TLS <= 1.0 access to these services within a year or two.

Of course, if there's general agreement among MSPs that they can do this without changes to MUAs and servers, so much the better.    But the work isn't done until we have consensus on a way forward (whether it happens in UTA or not).

Keith

Orit.

saag mailing list

[email-masked]<mailto:[email-masked]>