Re: Fwd: New Version Notification for draft-nottingham-http2-encryption-02.txt

On Thu, Dec 12, 2013 at 12:21 PM, Adrien de Croy <adrien@qbik.com> wrote:
> Maybe the problem is us.
>
> e.g. that we think the level of https adoption is a problem to be solved.
>
> personally I do not.

I understand and disagree with your position on HTTPS adoption. I
mostly brought it up in comparison to opportunistic encryption. IIUC,
you also disagree with opportunistic encryption as well.

>
> What if it simply reflects the desires of the people who own and run the
> sites. Exercising their choice.
>
> We are proposing (yet again) taking that choice away which I have a major
> problem with.  It's a philosophical problem, I don't believe any of us have
> the right to make those choices for everyone else, especially considering
> (which few seem to be) the ENORMOUS cost.

I believe you are incorrect in your understanding of the proposal.
This particular draft proposal is about offering a mechanism for
opportunistic encryption. It's a mechanism, and once again up to the
site author's choice. Let me know if I misunderstood you.

>
> Adrien
>
>
> ------ Original Message ------
> From: "William Chan (陈智昌)" <willchan@chromium.org>
> To: "Patrick McManus" <mcmanus@ducksong.com>
> Cc: "Martin Thomson" <martin.thomson@gmail.com>; "Mark Nottingham"
> <mnot@mnot.net>; "HTTP Working Group" <ietf-http-wg@w3.org>
> Sent: 13/12/2013 09:05:07
> Subject: Re: Fwd: New Version Notification for
> draft-nottingham-http2-encryption-02.txt
>>
>> Me speaking as a Chromium project representative here:
>> We talked about this internally amongst Chromium project members, and
>> the *current consensus* opinion is that Chromium does not support
>> opportunistic encryption, nor would we implement it were such a
>> mechanism standardized (I'm assuming no one's proposing mandatory to
>> implement...the draft does not appear to do so). We want to push
>> people toward adopting HTTPS, not the middle ground of opportunistic
>> encryption. You can see some opinions from other project members
>> (https://twitter.com/sleevi_/status/410092604613611520,
>> https://twitter.com/justinschuh/status/410104482622472192,
>> https://twitter.com/sleevi_/status/410093372116709376).
>>
>> OK, back to me talking as me, just another IETF individual:
>> I respect the goals behind opportunistic encryption, but it is
>> *unclear* to me if it is actually a net positive. There are definitely
>> a lot of things to like about it which I think have already been
>> covered. But I'm concerned that the risk of hurting HTTPS adoption is
>> real and significant. I don't have hard data to back this up. But even
>> looking at the numerous complaints about browser warnings for
>> self-signed certs
>> (http://robert.accettura.com/blog/2008/07/19/unobstructed-https/,
>>
>> http://it.slashdot.org/story/08/06/24/2345223/when-is-a-self-signed-ssl-certificate-acceptable,
>> etc) is indicative that site developers perceive a lot of benefit from
>> encryption without authentication. I am not convinced site developers
>> sufficiently understand the importance of authentication, and I worry
>> that offering a middle ground of unauthenticated encryption will give
>> them an out to not go full HTTPS.
>>
>> I think that the main problem we'd like to address is that HTTPS
>> adoption sucks. I join others in saying we should focus our energies
>> on solving that problem
>> (https://twitter.com/BRIAN_____/status/410181992085336064), rather
>> than working on proposals where the net result is unclear to be
>> beneficial or detrimental.
>>
>> Cheers.
>>
>> On Thu, Dec 12, 2013 at 10:03 AM, Patrick McManus <mcmanus@ducksong.com>
>> wrote:
>>>
>>>  I am slowing coming to a similar position on http2-encryption that
>>> Martin
>>>  expresses in the quote trail.
>>>
>>>  Doing the relaxed semantic is imo probably a net-positive. I'm not
>>> entirely
>>>  convinced but I'm not sure anything other than time and operational
>>>  experience could make it more clear. (anyone interested in a poc please
>>> let
>>>  me know.)
>>>
>>>  I also don't see a need to use a different *PN token for it than you
>>> would
>>>  for normal https. Any advertisement for relaxed (e.g. via alt-svc) is
>>> scoped
>>>  to the origin (and therefore scheme) and http/2 itself carries a scheme
>>> on
>>>  every transaction so the server isn't gaining any new information by
>>> putting
>>>  a relaxed token in the handshake. Brian, over in TLS WG, and Martin have
>>>  made different arguments why using 2 identifiers could be a net loss to
>>>  security and I don't see anyone arguing its necessity.
>>>
>>>
>>>  On Thu, Dec 12, 2013 at 12:31 AM, Martin Thomson
>>> <martin.thomson@gmail.com>
>>>  wrote:
>>>>
>>>>
>>>>  Overall, I think that the relaxed semantic proposed here is a pragmatic
>>>>  approach to getting more goodness into our protocol. Goodness being, in
>>>> this
>>>>  instance, better resilience against passive attacks, as well as opening
>>>>  avenues to some forms of active attack mitigation.
>>>>
>>>>  Re C.4:
>>>>
>>>>  I haven't seen strong justification for the "h2r" identifier. On the
>>>>  contrary, I see potential for harm in it. I'm worried that this will
>>>> create
>>>>  more confusion about the security properties of the protocol.
>>>>
>>>>  The idea that "h2r" might be used as some form of signal is basically
>>>>  devoid of value unless you believe that http: URIs will somehow need to
>>>> be
>>>>  retrieved with the same level of confidentiality and authentication as
>>>>  https: ones. I just don't see a server that cares about this leaving
>>>> the "s"
>>>>  off.
>>>>
>>>>  I believe it to be sufficient for the client to just use TLS. Any
>>>>  decisions about authentication are largely up to the client. The server
>>>>  would have to assume that http: URIs aren't going through rigorous
>>>> checks,
>>>>  though that doesn't mean that checking is completely precluded. I can
>>>>  imagine not checking in the classic CA chaining sense, but maybe
>>>> CT-like
>>>>  mechanisms could be useful in reducing the incidences of some types of
>>>>  active attacks. Especially if we are able to provide sufficient
>>>> incentive
>>>>  for proxies to come out from cover of darkness (actually, that may be a
>>>>  necessary precondition for some really strong improvements).
>>>>
>>>>  Creating disincentives around the use of "better" modes is - aside from
>>>>  just being perverse - ultimately going to be self-defeating. As long as
>>>> the
>>>>  downgrade path includes HTTP/1.1 in the clear, an active attack is
>>>> going to
>>>>  be trivial to mount without some other facilities in place.
>>>>
>>>>  I think that a "relaxed" mode is a good incremental improvement. Maybe
>>>> it
>>>>  will be a leg up on those facilities.
>>>>
>>>>  On Dec 10, 2013 8:21 PM, "Mark Nottingham" <mnot@mnot.net> wrote:
>>>>>
>>>>>
>>>>>  FYI.
>>>>>
>>>>>
>>>>>  Begin forwarded message:
>>>>>
>>>>>  > From: internet-drafts@ietf.org
>>>>>  > Subject: New Version Notification for
>>>>>  > draft-nottingham-http2-encryption-02.txt
>>>>>  > Date: 11 December 2013 3:18:55 pm AEDT
>>>>>  > To: Mark Nottingham <mnot@mnot.net>
>>>>>  >
>>>>>  >
>>>>>  > A new version of I-D, draft-nottingham-http2-encryption-02.txt
>>>>>  > has been successfully submitted by Mark Nottingham and posted to the
>>>>>  > IETF repository.
>>>>>  >
>>>>>  > Filename: draft-nottingham-http2-encryption
>>>>>  > Revision: 02
>>>>>  > Title: Opportunistic Encryption for HTTP URIs
>>>>>  > Creation date: 2013-12-11
>>>>>  > Group: Individual Submission
>>>>>  > Number of pages: 10
>>>>>  > URL:
>>>>>  >
>>>>> http://www.ietf.org/internet-drafts/draft-nottingham-http2-encryption-02.txt
>>>>>  > Status:
>>>>>  > http://datatracker.ietf.org/doc/draft-nottingham-http2-encryption
>>>>>  > Htmlized:
>>>>>  > http://tools.ietf.org/html/draft-nottingham-http2-encryption-02
>>>>>  > Diff:
>>>>>  >
>>>>> http://www.ietf.org/rfcdiff?url2=draft-nottingham-http2-encryption-02
>>>>>  >
>>>>>  > Abstract:
>>>>>  > This document proposes two changes to HTTP/2.0; first, it suggests
>>>>>  > using ALPN Protocol Identifies to identify the specific stack of
>>>>>  > protocols in use, including TLS, and second, it proposes a way to
>>>>>  > opportunistically encrypt HTTP/2.0 using TLS for HTTP URIs.
>>>>>  >
>>>>>  >
>>>>>  >
>>>>>  >
>>>>>  > Please note that it may take a couple of minutes from the time of
>>>>>  > submission
>>>>>  > until the htmlized version and diff are available at tools.ietf.org.
>>>>>  >
>>>>>  > The IETF Secretariat
>>>>>  >
>>>>>
>>>>>  --
>>>>>  Mark Nottingham http://www.mnot.net/
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>
>

Received on Thursday, 12 December 2013 20:28:35 UTC