Subject: [Uta] Comments [was: RE: Splitting the draft? [was RE: draft-ietf-uta-email-deep-00 comments]]

From: "Orit Levin (LCA)" <[email-masked]>
Date: Mon, 16 Mar 2015 22:41:58 +0000

Ralph,
Sorry for the delay in reply.
Your comments are very insightful and made me think along the following lines:

First, the topic of “OS for TLS”, is open for discussion in UTA. Interested writer(s)  and  presenter(s) are welcome to the Dallas meeting.

That being said, using TLS with email protocols is in the scope of UTA from the start. (BTW To describe such a document, UTA’s charter uses “bcp” instead of BCP because it’s not about the type of the document, but about its scope and intent.)

Right now, DEEP draft is not a bcp document for using TLS with e-mail protocols. As you pointed out, currently email protocols use TLS opportunistically, at best.

Perhaps because of that, the authors start the document by introducing a new comprehensive DEEP approach to elevate the current “more or less” opportunistic mode of operation to the “assured” one. To do so, a range of existing current practices is included in the document at different places “as needed” and described with various level of details. Some are included as the building blocks for DEEP (e.g., Implicit TLS), others – to acknowledge other less secure practices (e.g., certificate pinning in 3.2 and the OS-like mode in 3.3).

My point is that splitting (or, alternatively, renaming & rearranging) the draft into <Part 1: bcp> and <Part 2: new: DEEP> would be a better fit for UTA and more beneficial to UTA’s audience with little or no overhead. It seems  that UTA does need to document best **existing** email practices (built on various OS approaches) with their technical details. That is in order to improve interoperability and coexist with the emerging new solution(s) … until those are universally deployed.

Also, as mentioned in the Open Issues in the draft, DEEP represents one possible direction for improving e-mail security; using DANE for MUAs would be an orthogonal approach to include and potentially explore.

Hope this makes sense,

Orit.

From: Ralph Holz [mailto:[email-masked]]
Sent: Monday, March 02, 2015 4:36 PM
To: Orit Levin (LCA)
Cc: [email-masked]
Subject: Re: [Uta] Splitting the draft? [was RE: draft-ietf-uta-email-deep-00 comments]

Hi Orin,

How does this relate to the new drafts for Opportunistic Security? It seems to me that at least the TLS level should be synchronised. So maybe it makes sense to split this up, go ahead with opportunistic security profiles for certain applications (= OS + DEEP, part 1), enhanced with further privacy measures for email (= DEEP, part 2)?

Ralph

On 3 March 2015 at 10:45, Orit Levin (LCA) <[email-masked]<mailto:[email-masked]>> wrote:
During the last meeting, I expressed my opinion (as an individual, not as a chair) that it would be reasonable to split the draft into two:
1.      A "best current practices for e-mail" document expanding the tls-bcp document and based on existing protocols and mechanisms.
2.      A separate "proposed standard" document defining new mechanisms in order to improve email security, etc. These correspond to definitions in sections 5, 6, 7, the related procedures throughout the document, and the IANA Considerations.

There was no time for this discussion at the meeting, so we agreed to move it to the list. I would like to know what people think about this direction.
Thanks,
Orit.

_______________________________________________
Uta mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/uta

---

From: Chris Newman <[email-masked]>
Date: Mon, 23 Mar 2015 00:30:59 -0500

I'm not clear on what is "new" vs. what is "bcp" from your perspective. I can't
find a clear division. I am open to re-organizing the document to improve
clarity if there are specific suggestions to do so.

Although DEEP is about the single subject of improving confidentiality for MUA
to server connections, I can break down what the document does to achieve that
into roughly 7 sub-tasks:

1. introduce model for client confidentiality assurance similar to the model
that has deployed in web browsers but adapted for the "email account" model
common in email clients. 

2. Standardize non-standard confidentiality approaches for MUA protocols that
have the largest deployment, plus client certificate stuff so they can
interoperate.

3. Begin to deprecate alternative approaches that have not deployed as well.

4. Improve confidentiality provided by account setup phase.

5. introduce model for automated security upgrades similar to HSTS model, but
adapted for email protocols and generalized a bit

6. improve ability to audit/log confidentiality assurance and usage

7. advice for authors/deployment/providers

I'm a firm believer that security is systemic. Each of these tasks is part of
the overall goal to improve confidentiality. There are also some dependencies
between tasks; the current organization tries to avoid forward references as
much as possible.

So as for the distinction of "new" vs. "bcp". From a "what's already
standardized?"  viewpoint, it's all new except section 3. From a "what's
deployed?" viewpoint, section 2 and 3 cover what's deployed (maybe parts of
section 4 are deployed) while the rest is new. From a "has something like this
been standardized by the IETF before?" viewpoint, nothing in DEEP is new. From
a "what could go in an IETF BCP document?", we have section 1 (which is a model
rather than protocol) and parts of section 7 that don't depend on new protocol
in other sections. While section 3 is a BCP-like action it can't be done
without standardizing the protocol in section 2. Anyway, could you be more
specific about how you'd like the document organized?

		Thanks,
		- Chris

--On March 16, 2015 22:41:58 +0000 "Orit Levin (LCA)" <[email-masked]>
wrote:

> First, the topic of “OS for TLS”, is open for discussion in UTA.
> Interested writer(s)  and  presenter(s) are welcome to the Dallas meeting.
> 
> That being said, using TLS with email protocols is in the scope of UTA from
> the start. (BTW To describe such a document, UTA’s charter uses “bcp”
> instead of BCP because it’s not about the type of the document, but about
> its scope and intent.)
> 
> Right now, DEEP draft is not a bcp document for using TLS with e-mail
> protocols. As you pointed out, currently email protocols use TLS
> opportunistically, at best.
> 
> Perhaps because of that, the authors start the document by introducing a new
> comprehensive DEEP approach to elevate the current “more or less”
> opportunistic mode of operation to the “assured” one. To do so, a range
> of existing current practices is included in the document at different places
> “as needed” and described with various level of details. Some are
> included as the building blocks for DEEP (e.g., Implicit TLS), others – to
> acknowledge other less secure practices (e.g., certificate pinning in 3.2 and
> the OS-like mode in 3.3).
> 
> My point is that splitting (or, alternatively, renaming & rearranging) the
> draft into <Part 1: bcp> and <Part 2: new: DEEP> would be a better fit for
> UTA and more beneficial to UTA’s audience with little or no overhead. It
> seems  that UTA does need to document best **existing** email practices
> (built on various OS approaches) with their technical details. That is in
> order to improve interoperability and coexist with the emerging new
> solution(s) … until those are universally deployed.
> 
> Also, as mentioned in the Open Issues in the draft, DEEP represents one
> possible direction for improving e-mail security; using DANE for MUAs would
> be an orthogonal approach to include and potentially explore.
> 
> 
> Hope this makes sense,
> 
> Orit.
> 
> 
> How does this relate to the new drafts for Opportunistic Security? It seems
> to me that at least the TLS level should be synchronised. So maybe it makes
> sense to split this up, go ahead with opportunistic security profiles for
> certain applications (= OS + DEEP, part 1), enhanced with further privacy
> measures for email (= DEEP, part 2)?
> 
> Ralph
> 
> On 3 March 2015 at 10:45, Orit Levin (LCA)
> <[email-masked]<mailto:[email-masked]>> wrote: During the last
> meeting, I expressed my opinion (as an individual, not as a chair) that it
> would be reasonable to split the draft into two: 1.      A "best current
> practices for e-mail" document expanding the tls-bcp document and based on
> existing protocols and mechanisms. 2.      A separate "proposed standard"
> document defining new mechanisms in order to improve email security, etc.
> These correspond to definitions in sections 5, 6, 7, the related procedures
> throughout the document, and the IANA Considerations.
> 
> There was no time for this discussion at the meeting, so we agreed to move it
> to the list. I would like to know what people think about this direction.
> Thanks,
> Orit.
>

---

From: Leif Johansson <[email-masked]>
Date: Mon, 23 Mar 2015 13:51:16 +0100

> into roughly 7 sub-tasks:

The goals you outline are really important and the keyword above is
"improving"!

However, a BCP is mainly about describing what is done today.

Combining that perspective with pushing the envelope is difficult to
achieve in a single draft imho.

I think we should have both. I don't necessarily think DEEP and a BCP
for email hop-to-hop can or should be combined.

	Cheers Leif

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Mon, 23 Mar 2015 15:11:50 +0000

Chris,
Thanks a lot for taking this step and breaking DEEP into its sub-tasks.
This kind of "nomenclature"  ("what") at the opening of the document with a very short description of "how" for each (and the references to "where" in the draft) would improve the document a lot.

This would also help a lot to see how/whether the draft rearrangement or split is needed.
Would it be possible to have this discussion with the slides for the UTA session today?

Regardless the potential split/rearrangement, much of the "existing" practices are briefly documented under the "client confidentiality assurance" section. They probably deserve a separate section at the start of the document.

Looking forward to the slides and the discussion in the room!
Cheers,
Orit.  

> -----Original Message-----
> From: Chris Newman [mailto:[email-masked]]
> Sent: Sunday, March 22, 2015 10:31 PM
> To: Orit Levin (LCA); Ralph Holz
> Cc: [email-masked]
> Subject: Re: [Uta] Comments [was: RE: Splitting the draft? [was RE: draft-ietf-
> uta-email-deep-00 comments]]
>

---

From: Chris Newman <[email-masked]>
Date: Mon, 23 Mar 2015 10:22:39 -0500

--On March 23, 2015 13:51:16 +0100 Leif Johansson <[email-masked]> wrote:
>> I'm not clear on what is "new" vs. what is "bcp" from your perspective. I
>> can't find a clear division. I am open to re-organizing the document to
>> improve clarity if there are specific suggestions to do so.
>> 
>> Although DEEP is about the single subject of improving confidentiality for
>> MUA to server connections, I can break down what the document does to
>> achieve that into roughly 7 sub-tasks:
> 

That's incorrect. A BCP describes what is done today based on currently
published standards track technology. When what's deployed is not standards
track, as is the case with the MUA to server hop that DEEP covers, I see no way
to write a useful BCP on the topic.

> achieve in a single draft imho.

I disagree. I view security as systemic (covering protocol, implementations,
deployment models, management models, auditing, etc). Because of this, I
believe limiting security-related documents on the basis of "what fits in a
BCP" is a bad idea when focusing on a protocol. It is simply over-constraining
an engineering problem.

> for email hop-to-hop can or should be combined.

DEEP is covering the MUA to server single hop (which includes SMTP Submission,
RFC 6409), it does not cover the MTA relay hop-to-hop problem (SMTP relay RFC
5321). I prefer that these be kept as largely separate documents because the
security threats and models are very different.

Can we please discuss either technical details of DEEP or how to improve
readability of the DEEP document? I'm happy to have such discussions. I find
discussions involving the term "BCP" to be highly unproductive and not useful.

		- Chris

---

From: Leif Johansson <[email-masked]>
Date: Mon, 23 Mar 2015 16:35:17 +0100

> to write a useful BCP on the topic.

I'm not sure splitting hairs on the meaning of "BCP" is useful or
interesting.

What I was trying to say is that I think it would be useful and
interesting to document existing deployment practices of hop-by-hop tls
for email.

My understanding is that that is not what you and Keith are trying
to achieve with DEEP (and I agree that the WG should be talking about
the content of DEEP rather than the classification of the document)-

	Cheers Leif