Re: [Uta] Proposed list of deliverables

Thanks, Paul!
See inline. \Orit.

> -----Original Message-----
> From: Uta [mailto:uta-bounces@ietf.org] On Behalf Of Paul Hoffman
> Sent: Monday, January 20, 2014 4:58 AM
> To: uta@ietf.org
> Subject: Re: [Uta] Proposed list of deliverables
> 
> On Jan 18, 2014, at 1:24 AM, Orit Levin (LCA) <oritl@microsoft.com> wrote:
> 
> > Below is the list of deliverables for your consideration:
> >
> > 1. A threat analysis document containing a collection of known security
> breaches to application protocols due to poor use of TLS (Likely an
> Informational RFC)
> 
> Is this meant to also cover application protocols with *no* use of TLS? That is, is
> the threat analysis supposed to cover "why you should encrypt", or just "why
> you should encrypt well when you encrypt"?
> 

I envision this document to be as specific to TLS usage as possible (or the lack of it when TLS should have been a natural choice).

I could imagine the document to be organization by specific and/or publicly documented security breaches, each followed by a "threat analysis" targeted to application protocol designers and application users, who are not necessarily crypto professionals or security experts. The analysis should point to more "deep dive" security and other UTA documents when appropriate. Of course, at this stage this is a suggestion for feedback.

> > 2. Applications' independent document recommending best existing and future
> practices for using TLS (Likely a BCP or a Proposed Standard RFC)
> 
> Good.
> 
> > 3. A set of documents, each describing best existing and future practices for
> using TLS with a specific application protocol, i.e., SMTP, POP, IMAP, XMPP,
> HTTP 1.1, etc. (Case-by-case likely a BCP or a Proposed Standard RFC)
> 
> This needs to be defined more. The phase "using TLS" can mean one or more of:
> - TLS with server authentication, with encryption
> - TLS with server authentication, without encryption
> - TLS without server authentication, with encryption
> - TLS with server authentication, with client authentication, with encryption
> - TLS with server authentication, with client authentication, without encryption
> - TLS without server authentication, with client authentication, with encryption
> Different short names are applied different scenarios, making it all the more
> confusing. If we don't get this one right, we can easily delay useful results from
> the WG by two years.

If this organization proves useful, it probably belongs to #2 Applications' independent document. For the application-specific documents, similar discussion could be helpful for focusing on use cases (topologies) relevant to this application with its application clients, servers, proxies, etc. (each implementing a TLS client or a TLS server).

> 
> > 4. A document discussing (and potentially defining) how to apply the
> opportunistic encryption approach (preliminary outlined in draft-farrelll-mpls-
> opportunistic-encrypt-00.txt) to TLS. (Category TBD)
> 
> The preliminary outline in that document is transitory, and in some ways not
> easily applicable to TLS.

Sections 2.1 - 2.3 in this draft are generic and can be applicable to an arbitrary protocol. As it was pointed out in Vancouver and on the perpass list earlier, other definitions/interpretations of opportunistic encryption (OE) exist in RFCs and peoples' minds. I believe that IETF needs to agree on a conceptual meaning of OE or whatever alternative name(s) are chosen for different things. 

>Why are we not making our own definition so that we
> can apply it to TLS precisely?
> 

That is exactly what this deliverables is for; that is regardless whether we call it OE or not :-). Still, the terminology needs to be understood and consistent across the industry (at the very least, across all IETF).

> --Paul Hoffman
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta