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

On 2014-02-03 18:13, Alan Johnston wrote:
> Paul,
>
> Thanks for your reply - see a comment below.
>
> - Alan -
>
>
> On Mon, Feb 3, 2014 at 10:30 AM, Paul Hoffman <paul.hoffman@vpnc.org
> <mailto:paul.hoffman@vpnc.org>> wrote:
>
>     On Feb 3, 2014, at 7:28 AM, Alan Johnston
>     <alan.b.johnston@gmail.com <mailto:alan.b.johnston@gmail.com>> 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?

Thats different though - in that case you have a "valid" TLS server
cert, you just didn't know to ask for it.

The OE case is (imo) when the all the server has is a (possibly)
un-authenticated key. Displaying the padlock in that case is ...
questionable.
>  
>
>
>     > 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
>
>
>
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta