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

On Thu, Dec 12, 2013 at 12:38 PM, Adrien de Croy <adrien@qbik.com> wrote:
>
>
> ------ Original Message ------
> From: "William Chan (陈智昌)" <willchan@chromium.org>
> To: "Adrien de Croy" <adrien@qbik.com>
> Cc: "Patrick McManus" <mcmanus@ducksong.com>; "Martin Thomson"
> <martin.thomson@gmail.com>; "Mark Nottingham" <mnot@mnot.net>; "HTTP Working
> Group" <ietf-http-wg@w3.org>
> Sent: 13/12/2013 09:28:06
> Subject: 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.
>
>
> Actually no I don't, STLS/STARTTLS work great in POP3/IMAP/SMTP.
>
> People get to retain choice whether it is used and/or offered.

Ah, OK. I misunderstood your position. Sorry for that.

>
>
>>
>>>
>>>  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.
>
> ok, I thought you were proposing that opportunistic encryption was something
> Chromium wouldn't get, because you didn't want to offer any alternative path
> to full authenticated TLS.

Oh, I misunderstood you and perhaps miscommunicated. Indeed, the
Chromium project currently has no plans to respect a server
advertisement that we could do unauthenticated TLS for http:// URIs. I
believe the draft does not require a client to respect any such server
advertisement, but merely proposes a mechanism for such a server
advertisement. The site author has the choice to advertise
unauthenticated TLS for http:// URIs, and the client has a choice of
whether or not to respect it, and intermediaries have the choice of
stripping out such advertisements if they so choose. I'm stating the
current Chromium project stance is that we do not believe such a
mechanism should even be standardized, and were it to be standardized,
we would not respect the server advertisement in our browser.

And for clarity, we do have a similar mechanism today in
Alternate-Protocol. That is intended to allow site authors to
advertise support for SPDY (or QUIC) for deployment of protocols with
better networking performance, *not* for security or privacy. There is
a fine line there, and it's definitely debatable whether or not we
should even support Alternate-Protocol given possible confusion here.
It's something we have in the back of our minds, but we have not felt
a need to revisit it at this time. But we may need to do so.

I hope this clarifies matters. Let me know if there is any confusion
here. I understand that we seem to disagree both on:
* Whether or not increased HTTPS adoption is a good thing
* Whether or not opportunistic encryption should even be offered (by
any party, be it server/intermediary, or client).

>
> Adrien
>
>
>>
>>>
>>>  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:55:40 UTC