Re: Mandatory encryption *is* theater

I too, hope we only use secure transports for HTTP/2.


On Tue, Aug 27, 2013 at 2:20 AM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> I guess my point is that you've repeatedly made criticisms based on the
> authentication requirement (for example, your criticisms based on
> certificate configuration). I agree authentication would be nice to have,
> but I think it's unfair to criticize mandatory to offer *encryption*
> because of authentication. This is why I complain about it being a straw
> man argument.
>
> To be clear, I'm still personally leaning towards only supporting HTTP/2
> over a secure transport in chromium (and if we can get that for http://URIs too, great!). I just don't want to see mnot's proposal get unfairly
> treated. I'd like to see where the discussion leads us. If it gains any
> traction, then I need to check back with some more chromium networking
> folks (like rch/akalin who may be lurking on this thread) to see how much
> interest we have in unauthenticated, but encrypted HTTP/2. I myself hope we
> only use secure transports.
>
> On Aug 27, 2013 2:14 PM, "Eliot Lear" <lear@cisco.com> wrote:
> >
> > Hi Will,
> >
> > On 8/26/13 4:33 PM, William Chan (陈智昌) wrote:
> >
> > > Great, I think we've made progress here on narrowing in on the meat of
> > > the discussion. I've got nothing new here other than what others have
> > > already said, but I'll re-emphasize a particularly point. We're
> > > primarily talking about http:// URIs here. Given that constraint, it's
> > > unclear if we want to require server authentication. I think most
> > > people are starting with just encryption. So while the authentication
> > > discussion is interesting, I'd ignore authentication for now.
> >
> > I know I'm not winning an congeniality awards here for disagreeing so
> > much, but I wouldn't entirely ignore authentication.  As you browser
> > folk know, you may have retained a lot of information about the server.
> > Some of that information might involve the identity of the server, which
> > is really what is at issue here.  Making use of that would be good, but
> > I don't know if it can be done properly on port 80 in a standard, unless
> > of course you happen to have a published DNS record with capabilities.
> > It opens up a whole can of worms about whether example.com:80 and
> > example.com:someotherportrunningSSL are equivalent.
> >
> > It's also not the most elegant idea I've ever had, I must say.
> >
> > Eliot
> >
> >
>