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 protected]]
> Sent: Sunday, March 22, 2015 10:31 PM
> To: Orit Levin (LCA); Ralph Holz
> Cc: [email protected]
> Subject: Re: [Uta] Comments [was: RE: Splitting the draft? [was RE:
> draft-ietf-
> uta-email-deep-00 comments]]
>
> 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
