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

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

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

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:38:51 UTC