Re: [Uta] Proposed definition of opportunistic encryption using TLS: draft-hoffman-uta-opportunistic-tls-00.txt

Paul,
First - thank you for writing this. I had only a vague understanding of the term "oppurtunistic encryption" before reading this as it has been used in many contexts. I would like to add a bit more complex scenario than HTTP client/server.

In the SIP protocol, a manager of a service can define by using NAPTR DNS records that all connections to my service has to use TLS to connect to the service. It's not really oppurtunistic since there is a requirement, but not from the user. It's surely authenticated. Your document only talks about user requirments, but here is a case of a server/service requirement that controls behaviour.

Now if w have a signalling path with multiple proxys between a user and an endpoint any of these servers could use oppurtunistic encryption for the next hop. In SIP we add a "TLS" transport marker to a via header - much like a received header in mail - when we use TLS. This to me marks an authenticated TLS connection. I wonder if there is any reason to separate this from the case where a middleman finds a TLS naptr or SRV records and sets up TLS just because it is possible, a matter of preference in the server, a proxy-controlled oppurtunistic encryption path. With TLS we have special requirements for the return path that may not apply to oppurtunistic TLS. We propably want to mark those connections as TCP and add some extra info that TLS was actually used. At this point I don't think we need an "OTLS" marker to suggest TLS if possible. That could be wrong. :-)

On a side note SIP has no error codes for telling a client that a remote connection (beyond the first proxy)  failed because of bad certificates or something else TLS-related, just "Connection failed, sorry" (like Javascript). I don't think that's because of any security concern, just a poor specification.

/O

On 03 Feb 2014, at 06:03, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> Greetings again. One of the deliverables in our charter is:
> 
>   - Consider, and possibly define, a standard way for an application
>     client and server to use unauthenticated encryption through TLS
>     when server and/or client authentication cannot be achieved.
> 
> I think that wording was sloppy, and would like the WG to come up with a clear definition of what it is we want application protocols to possibly support in order to thwart pervasive monitoring. I put together my ideas in a very short draft.
> 
> If folks like the idea of this definition, I think it would be appropriate for a WG document.
> 
> --Paul Hoffman
> 
> 
> Begin forwarded message:
> 
>> From: internet-drafts@ietf.org
>> Subject: I-D Action: draft-hoffman-uta-opportunistic-tls-00.txt
>> Date: February 2, 2014 at 8:59:10 PM PST
>> To: i-d-announce@ietf.org
>> Reply-To: internet-drafts@ietf.org
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> 
>> 
>>       Title           : Opportunistic Encryption Using TLS
>>       Author          : Paul Hoffman
>> 	Filename        : draft-hoffman-uta-opportunistic-tls-00.txt
>> 	Pages           : 5
>> 	Date            : 2014-02-02
>> 
>> Abstract:
>>  This document defines the term "opportunistic encryption using TLS"
>>  as it applies to application protocols that use TLS.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-hoffman-uta-opportunistic-tls/
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-hoffman-uta-opportunistic-tls-00
> 
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta