W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Rough minutes

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 12 Nov 2013 11:56:55 +0800
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Peter Lepeska <bizzbyster@gmail.com>, Tim Bray <tbray@textuality.com>
Message-Id: <AAE165D2-DF80-49A3-B121-1608C109F4A4@mnot.net>
To: Yoav Nir <ynir@checkpoint.com>

On 10 Nov 2013, at 12:11 pm, Yoav Nir <ynir@checkpoint.com> wrote:

> 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?

Yes, pretty much. Unfortunately, we didn’t have time to follow the discussion to this conclusion in the room, but many conversations I had afterwards reflected this.

> 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.

The charter itself doesn’t address this topic explicitly; the discussion leading up to it did, of course. What we’re doing now is effectively revisiting that discussion to see where we sit, based upon new information that’s become available.

Cheers,


> 
> Yoav
> 
> On Nov 9, 2013, at 11:04 PM, Peter Lepeska <bizzbyster@gmail.com> 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.
>> 
>> Peter
>> 
>> 
>> On Tue, Nov 5, 2013 at 9:17 PM, Yoav Nir <ynir@checkpoint.com> wrote:
>> And #2 was only slightly stronger.
>> 
>> On Nov 5, 2013, at 6:08 PM, Tim Bray <tbray@textuality.com>
>>  wrote:
>> 
>>> 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 <mnot@mnot.net> wrote:
>>> … are up at:
>>>   http://trac.tools.ietf.org/wg/httpbis/trac/browser/wg_materials/ietf88/minutes.txt
>>> 
>>> Cheers,
>>> 
>>> 
>>> --
>>> Mark Nottingham   http://www.mnot.net/
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Email secured by Check Point 
>>> 
>> 
>> 
> 

--
Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 12 November 2013 03:57:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC