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 protected]>
wrote:
> 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 protected]]
> Sent: Monday, March 02, 2015 4:36 PM
> To: Orit Levin (LCA)
> Cc: [email protected]
> 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 protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/uta
>
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
