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

[Alan Johnston <[e-mail]>]

Paul,

Thanks for your reply - see a comment below.

- Alan -


On Mon, Feb 3, 2014 at 10:30 AM, Paul Hoffman <[e-mail]> wrote:

> On Feb 3, 2014, at 7:28 AM, Alan Johnston <[e-mail]>
> wrote:
>
> > 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.
>
> It does not violate the rule unless it is something that the user
> configures. If it is something set by the application developer (in this
> case, to follow the requirements of the protocol), but is not
> user-configurable, it's fine.
>
> >  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.
>
> Consider the HTTP / browser case. You have set up a TLS-accessible web
> site because security is good for the Internet, but you hate paying for and
> configuring a certificate for obvious reasons. If all common browsers let
> user say "always do TLS even for http: URLs, and ignore any server
> failure", you would configure your web server to do TLS with no certificate
> because that's good enough. That's a security reduction for the Internet.
>

But it's the "ignore any server failure" part that is the security
reduction, and that is not OE by your definition but "unathenticated TLS"
that you describe in the Appendix, right?

Here's a real example:  The EFF's HTTP Everywhere browser extension (
https://www.eff.org/https-everywhere).  It finds HTTPS connections even
when I just try to visit the HTTP site.  Does the browser displaying the
padlock hurt anything?  How does this reduce security for the Internet?


>
> > 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!
>
> Please, please note: "this definition" is only about TLS. I even called
> that out in the draft.
>
> --Paul Hoffman