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

Olle,

The way in which a SIP request can utilize TLS for subsequent proxy hops
even though the user has not requested it (e.g. using a secure SIP or sips
URI) seems within the spirit of Paul's definition.  A more complete
approach could choose TLS for the first hop as well.

I'm less certain if the presence of a "transport=tls" parameter in the SIP
message violates Paul's rule about not indicating that TLS has been used.
 I'd need more explanation to understand this rule anyway, along with the
rule that no user configuration be allowed. It is not clear to me how
either of these does the harm that is described in the Security
Considerations section.

For VoIP and video calling in general, there is also the issue of
encryption of the media - to use SRTP or use unencrypted RTP. For ZRTP, we
developed an approach that could be considered opportunistic in this
definition, although we described it "best effort encryption" (RFC 6189).
 But that is a discussion for another thread!

- Alan -

On Mon, Feb 3, 2014 at 2:49 AM, Olle E. Johansson <oej@edvina.net> wrote:

> 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
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>