Re: [Uta] [saag] UTA WG report

[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:
>
> Keith,
>
> Great intro to gathering the very much needed feedback.
>
> Adding UTA so we can continue the discussion there.
>
> Thanks,
>
> Orit.
>
>  
>
> *From:*saag [mailto:saag-bounces@ietf.org] *On Behalf Of *Keith Moore
> *Sent:* Thursday, March 30, 2017 12:42 PM
> *To:* saag@ietf.org
> *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:
>
>     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.
>
>      
>
>
>
>
>     _______________________________________________
>
>     saag mailing list
>
>     saag@ietf.org <mailto:saag@ietf.org>
>
>     https://www.ietf.org/mailman/listinfo/saag
>
>  
>
>
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta