Re: Rough minutes

I'm stumped about #3 myself.

The literal interpretation is that you follow (or type in) an http:// link, get a response, and in the response learn that this is also available with SSL. So the client attempts to upgrade to SSL, and receives a valid certificate. So, yay!

But in that case, why is the http:// link out there at all, and if anybody types it in, why not immediately redirect to https:// as pretty much all sites using SSL do?

Also, I don't like the implication:  No valid certificate --> No encryption --> No HTTP/2. That's a far higher bar than the goal that's set in the charter.  We could at least give you ADH ciphersuites with no certificates.


On Nov 9, 2013, at 11:04 PM, Peter Lepeska <<>> wrote:

I never did understand option #3. What is opportunistic encryption with authentication? I thought opportunistic encryption is TLS-relaxed, which is encryption without server authentication.

Also, I think  the choices are different for HTTP 1 and 2 b/c HTTP/2.x doesn't involve a performance trade-off.

For HTTP 1.x, the only realistic choice (assuming do nothing is off the table) in my opinion is:
1) Add support for TLS-relaxed in HTTP/1.x web servers and browsers but make it OFF by default. Performance impact is too great for HTTP 1.x so many deployments will not want this.

For HTTP 2.x, I believe the choices are:
1) Add support for TLS-relaxed in HTTP/2.x web servers and browsers but make it ON by default.
2) Require Full TLS in HTTP 2.x.


On Tue, Nov 5, 2013 at 9:17 PM, Yoav Nir <<>> wrote:
And #2 was only slightly stronger.

On Nov 5, 2013, at 6:08 PM, Tim Bray <<>>

I would have said the weakness of the #3 and #4 hums was very, very close.

On Tue, Nov 5, 2013 at 4:41 PM, Mark Nottingham <<>> wrote:
 are up at:


Mark Nottingham

Email secured by Check Point

Received on Sunday, 10 November 2013 04:12:00 UTC