Subject: [Uta] 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: 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

On 03/30/2017 03:13 PM, Orit Levin wrote:

Orit.

_______________________________________________

saag mailing list

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

https://www.ietf.org/mailman/listinfo/saag

---

From: Jim Fenton <[email-masked]>
Date: Thu, 30 Mar 2017 14:26:41 -0700

[removing saag list because this is probably at a lower level of detail
than appropriate there. But feel free to add them if I'm wrong]

My sense that there is a "BCP part" to the draft is probably more
clearly stated that there are really two different things described in
the draft, as the draft itself says in section 5 paragraph 4:

"Note that security directives are a separate mechanism from minimum
confidentiality assurance levels."

It appears to me that it's possible independently to implement/deploy
confidentiality assurance levels and security directives. So I would
split them up into separate documents.

I still see confidentiality assurance levels as more of a BCP-ish
mechanism. It defines particular security requirements for MUA-MTA
connections to meet Confidentiality Assurance Level (CAL) 1, and
different ones for CAL 0. That seems like a best current practice to me.

I think we should tease these two things apart into separate
specifications so that it's clear you can have one or the other or both.
But the categorization of these two things doesn't really matter to me
(whether CAL is a standards-track protocol or a BCP, specifically).

-Jim

On 3/30/17 1:50 PM, Orit Levin wrote:
> *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
>
>  
>
>     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.
>
>      
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Mar 2017 17:47:20 -0400

On 03/30/2017 05:26 PM, Jim Fenton wrote:
> [removing saag list because this is probably at a lower level of 
> detail than appropriate there. But feel free to add them if I'm wrong]
>

Disagree.  Compliance with both the CAL and the security directives are 
a matter of protocol interaction between client and server. The only 
real difference is that in the CAL case, no new protocol features need 
to be defined (we're talking about new client interactions with existing 
server features); whereas for security directives there are changes to 
the protocols used by the servers. But in both cases these are protocol 
interactions.

A client's compliance with this protocol can be tested, and the protocol 
could reasonably advance to full standard (or not) based on such testing 
with multiple client implementations.   So I don't understand why BCP is 
more appropriate.

(But if that's what IESG wanted to do, I wouldn't fight it.   Let's just 
try to not let this question delay the document, ok?)

I also believe it would be more confusing to have two documents for 
confidentiality assurance level and security directives, because both of 
them require the client to disconnect if the requirements aren't met.    
But I'll think about that some more.   The current document is longer 
than I'd like, and there's a tendency for readers to get overwhelmed by 
long documents and miss things.   But when readers have to read multiple 
documents in order to implement changes, it usually makes the problem 
worse.

> specifications so that it's clear you can have one or the other or both.

The only benefit I can see to that is that server implementors and MSPs 
and server implementors wouldn't have to read the CAL document [*], 
since that's all done on the user end.   Offhand, I don't see why it's 
beneficial for an MUA to be able to implement either CAL or security 
directives or both.  The two features were designed to work together.

[*] except that MSPs would still need to know about CAL for customer 
support reasons

Keith