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

From: Mark Nottingham <[email-masked]>
Date: Wed, 11 Dec 2013 15:19:11 +1100

FYI.

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-nottingham-http2-encryption-02.txt
> Date: 11 December 2013 3:18:55 pm AEDT
> To: Mark Nottingham <[email-masked]>
> 
> 
> 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/

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Dec 2013 19:04:23 -0800

I'm still confused about "h2r". Why is the server offering this as
something different than "h2t"? That is, if it is the client's choice
whether or not to authenticate the server, why do you have this as
something the server is offering?

--Paul Hoffman

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 Dec 2013 15:52:22 +1100

Yep, that's been discussed a few times, it's an open question.

One possible use is that the server may want/need to know whether or not the client is validating the cert; e.g., a bank.

Cheers,

On 12 Dec 2013, at 2:04 pm, Paul Hoffman <[email-masked]> wrote:

> I'm still confused about "h2r". Why is the server offering this as something different than "h2t"? That is, if it is the client's choice whether or not to authenticate the server, why do you have this as something the server is offering?
> 
> --Paul Hoffman

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Dec 2013 21:31:58 -0800

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" <[email-masked]> wrote:

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 12 Dec 2013 09:53:26 +0200

On Thu, Dec 12, 2013 at 03:52:22PM +1100, Mark Nottingham wrote:

(The difference between h2t and h2r)

> One possible use is that the server may want/need to know whether or
> not the client is validating the cert; e.g., a bank.

Or client knowing if server supports HTTP-over-HTTPS (sending HTTP
requests over HTTP/TLS)? Or does h2t or HTTP/2.0 already imply it?
I have seen at least one HTTP/1.1 server that fails in dangerous
way[1] (and knowing it is apache probably means there are a lot
more of those) if one tries using HTTP-over-HTTPS.

Also, internally using HTTPS on HTTPS could cause some (bady
written) things to fail as client and server could then disagree
about the protocol.

[1] Essentially, returning wrong data without error.

-Ilari

---

From: Patrick McManus <[email-masked]>
Date: Thu, 12 Dec 2013 13:03:30 -0500

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
<[email-masked]>wrote:

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Dec 2013 11:14:52 -0800

On Wed, Dec 11, 2013 at 8:52 PM, Mark Nottingham <[email-masked]> wrote:

>
> One possible use is that the server may want/need to know whether or not
> the client is validating the cert; e.g., a bank.
>
>
1) In what scenarios that are similar to what we have today does a server
want/need to know that the client validated the cert? In your "a bank"
example, assume that the user removed the WhizzyCA root from the browser's
pile, the bank chains up to WhizzyCA, and the user clicked through the "do
you really want to do this" warning from his browser. How does that server
know that?

2) Are there other possible uses?

--Paul Hoffman

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 12 Dec 2013 12:05:07 -0800

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 <[email-masked]> wrote:
> 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 <[email-masked]>
> wrote:
>>
>> 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:
>>
>> https: ones. I just don't see a server that cares about this leaving the "s"
>> off.
>>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 12 Dec 2013 20:09:06 +0000

>real and significant.

When you say "HTTPS adoption" do you mean HTTPS as we know it, with
trojaned CA's or do you mean some future variant where the authentication
is actually worth something when it comes to trust ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 12 Dec 2013 12:18:00 -0800

> is actually worth something when it comes to trust ?

I mean HTTPS as we know it and believe we should work on fixing
existing PKI issues. I am a fan of work like public key pinning
(https://www.imperialviolet.org/2011/05/04/pinning.html).

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 12 Dec 2013 20:21:36 +0000

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.

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.

Adrien

------ Original Message ------
From: "William Chan (陈智昌)" <[email-masked]>
To: "Patrick McManus" <[email-masked]>
Cc: "Martin Thomson" <[email-masked]>; "Mark Nottingham" 
<[email-masked]>; "HTTP Working Group" <[email-masked]>
Sent: 13/12/2013 09:05:07
Subject: Re: Fwd: New Version Notification for 
draft-nottingham-http2-encryption-02.txt
>>scoped

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 12 Dec 2013 12:28:06 -0800

On Thu, Dec 12, 2013 at 12:21 PM, Adrien de Croy <[email-masked]> 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.

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

>>>> this

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 12 Dec 2013 20:38:45 +0000

------ Original Message ------
From: "William Chan (陈智昌)" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Patrick McManus" <[email-masked]>; "Martin Thomson" 
<[email-masked]>; "Mark Nottingham" <[email-masked]>; "HTTP 
Working Group" <[email-masked]>
Sent: 13/12/2013 09:28:06
Subject: Re: Fwd: New Version Notification for 
draft-nottingham-http2-encryption-02.txt
>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.

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

>>>  On Thu, Dec 12, 2013 at 10:03 AM, Patrick McManus 
>>><[email-masked]>
>>>  wrote:
>>>>
>>>>   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
>>>>   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
>>>>>   contrary, I see potential for harm in it. I'm worried that this 
>>>>>will
>>>>>  create
>>>>>   devoid of value unless you believe that http: URIs will somehow 
>>>>>need to
>>>>>  be
>>>>>   https: ones. I just don't see a server that cares about this 
>>>>>leaving
>>>>>  the "s"
>>>>>   off.
>>>>>
>>>>>   would have to assume that http: URIs aren't going through 
>>>>>rigorous
>>>>>  checks,
>>>>>   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
>>>>>   I think that a "relaxed" mode is a good incremental improvement. 
>>>>>Maybe
>>>>>  it
>>>>>>   > Please note that it may take a couple of minutes from the time 
>>>>>>of
>>>>>>   > submission

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 12 Dec 2013 20:39:08 +0000

In message <emac540e4f-ad51-4150-8748-5daacd186421@bodybag>, "Adrien de Croy" w

>e.g. that we think the level of https adoption is a problem to be solved.

Me neither:  We should deliver tools, not policies.

In particular, I think it is utterly hypocritical to attempt to
mandate HTTPS adoption as long as the authentication framework is
known to be comprehensively trojaned.

I'm also not too warm on the opportunistic encryption idea:

On the plus side:  It frustrates the casual tcpdump() abuse and
defeats high performance pritive keyword based filtering.

On the minus side:  It is just bit-scrambling and it doesn't take
that much to defeat it.

There is no doubt that deploying a good opportunistic scrambling, lets
call it that, since that's all it is, will make people in NSA and GCHQ
curse us.

If that's the goal, we should design the scrambling to be maximally
resource hungry, in order to defeat 10GE snooping cards with limited
RAM resources.

But for that to work, deployment must be swift and comprehensive
(ie: HTTP/1 not /2) and it will only buy the world a minimum of
privacy for some months.

If we think we can engage the political process during such a pause
and put the brakes on the Global War On Privacy, then it may be
well worth it.

But as long as people think more crypto is a sufficient answer,
they are merely deluding themselves, and we should not crap up
the protocol standards with futile attempts.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Dec 2013 21:44:47 +0100

Will, Adrien,

> site author's choice. Let me know if I misunderstood you.

Well.

It seems to all a matter of who gets choice.  Is it the site author?  Is
it the browser?  Is it the site administrator?  This conversation needs
to tie back to how proxies would engage in all of this in a way in which
they are 1st class objects and those lovely use cases like Eliot's
Island. (Thanks for that one, Mark.  I just want to run down a beach
yelling "Skipper!!!")  And then we need to see what is desired versus
what is possible, either with mostly existing code or with new code.

You stated it well earlier that you guys have a current position and not
a final position.  A lot of us would fit that bill, although our
positions may differ - for the moment.  That's the great thing about
driving toward consensus.
Also, some experimenting will help us find that consensus.  I'd love to
see a full diagnostic with swimming pool lane diagrammed out of who
speaks what when with intermediaries in the picture.

Eliot

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 12 Dec 2013 12:55:12 -0800

On Thu, Dec 12, 2013 at 12:38 PM, Adrien de Croy <[email-masked]> wrote:
> <[email-masked]>; "Mark Nottingham" <[email-masked]>; "HTTP Working
> Group" <[email-masked]>

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

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

>>>>>>   devoid of value unless you believe that http: URIs will somehow need
>>>>>> to
>>>>>>  be
>>>>>>   just being perverse - ultimately going to be self-defeating. As long
>>>>>> as
>>>>>>  the

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 12 Dec 2013 23:25:06 +0000

------ Original Message ------
>* Whether or not increased HTTPS adoption is a good thing
I prefer to take 1 step back from there.

Whether or not we should be trying to make a judgement call on whether 
increased (or existing) level of HTTPS adoption is a good thing or not.

I would propose we should not even be trying to rule on this point.

>any party, be it server/intermediary, or client).
I may be misunderstanding what is proposed.

in mail, opportunistic encryption closest corollary is STARTTLS.  In 
this case, it's not unauthenticated.  Also, the protocol isn't first 
layered over TLS.  the TLS is decided on later in the protocol, and if 
chosen, it is added under the application layer over the transport 
layer.

Is the current proposal that http2 always be over TLS but that there be 
an optional opt-out for crypto? Or opt-out of the authentication part of 
the crypto?

This leaves the TLS framing (and the problematic handshake) in each 
connection, which I have a problem with purely from a performance POV.

I'm in New Zealand so maybe I'm more sensitive to latency.  It's at 
least 200ms RT to the US from here.

Regards

Adrien

>>>>>>    I am slowing coming to a similar position on http2-encryption 
>>>>>>that
>>>>>>   Martin
>>>>>>    Doing the relaxed semantic is imo probably a net-positive. I'm 
>>>>>>not
>>>>>>   entirely
>>>>>>    I also don't see a need to use a different *PN token for it 
>>>>>>than you
>>>>>>   would
>>>>>>    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
>>>>>>>    approach to getting more goodness into our protocol. Goodness 
>>>>>>>being,
>>>>>>>  in
>>>>>>>   this
>>>>>>>    instance, better resilience against passive attacks, as well 
>>>>>>>as
>>>>>>>  opening
>>>>>>>    contrary, I see potential for harm in it. I'm worried that 
>>>>>>>this will
>>>>>>>   create
>>>>>>>    retrieved with the same level of confidentiality and 
>>>>>>>authentication
>>>>>>>  as
>>>>>>>    decisions about authentication are largely up to the client. 
>>>>>>>The
>>>>>>>  server
>>>>>>>    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
>>>>>>>    Creating disincentives around the use of "better" modes is - 
>>>>>>>aside
>>>>>>>  from
>>>>>>>    downgrade path includes HTTP/1.1 in the clear, an active 
>>>>>>>attack is
>>>>>>>   going to
>>>>>>>>    > has been successfully submitted by Mark Nottingham and 
>>>>>>>>posted to
>>>>>>>>  the
>>>>>>>>    > IETF repository.
>>>>>>>>    >
>>>>>>>>    > Please note that it may take a couple of minutes from the 
>>>>>>>>time of
>>>>>>>>    > submission

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 12 Dec 2013 15:45:46 -0800

On Thu, Dec 12, 2013 at 3:25 PM, Adrien de Croy <[email-masked]> wrote:
> in mail, opportunistic encryption closest corollary is STARTTLS.  In this
> case, it's not unauthenticated.  Also, the protocol isn't first layered over
> TLS.  the TLS is decided on later in the protocol, and if chosen, it is
> added under the application layer over the transport layer.
>
> Is the current proposal that http2 always be over TLS but that there be an
> optional opt-out for crypto? Or opt-out of the authentication part of the
> crypto?

I think you should read the draft, and in particular,
http://tools.ietf.org/html/draft-nottingham-http2-encryption-02#section-2.1.
It provides for a "h2r" (HTTP/2 relaxed) that does opportunistic
unauthenticated encryption:
"""
   When connecting to an "h2r" service, the algorithm for authenticating
   the server described in [RFC2818] Section 3.1 changes; the client
   does not necessarily validate its certificate for expiry, hostname
   match or relationship to a known certificate authority (as it would
   with "normal" HTTPS).
"""

So, it lets servers advertise support for serving http:// URIs over
TLS, but without server authentication. The reason for doing so is to
lower the barrier to using encryption, by not requiring server
authentication, without having to switch URIs from http:// to
https://.

There is nothing in the proposal that requires that HTTP/2 always be
over TLS. This is covered in the appendix
(http://tools.ietf.org/html/draft-nottingham-http2-encryption-02#appendix-C.1):
"""
C.1.  Will this make encryption mandatory in HTTP/2.0?

   Not in the sense that this proposal would have it required (with a
   MUST) in the specification.

   What might happen, however, is that some browser implementers will
   take the flexibility that this approach grants and decide to not
   negotiate for HTTP/2.0 without one of the encryption profiles.  That
   means that servers would need to implement one of the encryption-
   enabling profiles to interoperate using HTTP/2.0 for HTTP URIs.
   Not in the sense that this proposal would have it required (with a
   MUST) in the specification.
"""

> I'm in New Zealand so maybe I'm more sensitive to latency.  It's at least
> 200ms RT to the US from here.
>
> Regards
>
> Adrien
>
>
>>
>>>
>>>  Adrien
>>>
>>>
>>>>
>>>>>
>>>>>   Adrien
>>>>>
>>>>>
>>>>>>>> need
>>>>>>>> long
>>>>>>>>>    > has been successfully submitted by Mark Nottingham and posted
>>>>>>>>> to
>>>>>>>>>  the
>>>>>>>>>    > IETF repository.
>>>>>>>>>    >

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 13 Dec 2013 10:56:40 +1100

Martin said:

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

That's true, *if* clients implement the http2-tls protocol identifier semantics uniformly; otherwise, they won't know whether they need to offer a valid certificate to upgrade to that protocol. 

When I wrote this draft, there was still active debate; some people thought opp encryption without authentication could be useful, whereas others are firm that this is not a good direction, and opp encryption should only happen when coupled with strong server auth.

If we overload the semantics of http2-tls (ignoring the exact syntax of the identifier) to mean "opportunistic encryption without authentication", but some browsers require authentication, we have an interop problem, and opp encryption without authentication is effectively impossible to use. 

Now, if no one is interested in using TLS with authentication for http:// URIs, this problem (probably) goes away. The one thing that worries me a tiny bit is that a browser's position about what an acceptable mix of security characteristics might change over time, and if it does, we may need this distinction again. However, since we're using draft identifiers, it's not a huge risk.

Based on this discussion, it sounds like I can go ahead and remove h2r and refine the semantics of h2t to include the HTTP URI use case (i.e., no auth if on the same host, strong auth if on a different host). 

Make sense?

Cheers,

On 13 Dec 2013, at 5:03 am, Patrick McManus <[email-masked]> 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 <[email-masked]> 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.
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Dec 2013 18:46:27 -0800

> That's true, *if* clients implement the http2-tls protocol identifier semantics uniformly; otherwise, they won't know whether they need to offer a valid certificate to upgrade to that protocol.

Right, I guess that I had assumed that you hadn't made that leap yet.
As in, clients would not be able to expect a good certificate if they
had followed their noses to the other end of an http: URI.  That was
kinda the point of the rest of my mail: there is no point in raising
the bar that high because all that does is chase people back to 1.1.

> Now, if no one is interested in using TLS with authentication for http:// URIs, this problem (probably) goes away. The one thing that worries me a tiny bit is that a browser's position about what a…

I think that there will be a continuing evolution of what the security
properties of each of the schemes is.  But I hope that this isn't
going to lead to states of disconnect where each end has very
different expectations.

Maybe we can eliminate the differences; I remain a little skeptical
about that though.

> Based on this discussion, it sounds like I can go ahead and remove h2r and refine the semantics of h2t to include the HTTP URI use case (i.e., no auth if on the same host, strong auth if on a diffe…

Noting that the distinguishing mark here is the 's', sure.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Dec 2013 20:45:40 -0800

On Thu, Dec 12, 2013 at 12:05 PM, William Chan (陈智昌)
<[email-masked]>wrote:

> implement...the draft does not appear to do so).

Just to try again to get clarity: do you not support any type of
opportunistic encryption, or just the type given in this draft? Others have
proposed other methods, such as my "do it in HTTP/2 itself". I can
interpret your message both ways.

--Paul Hoffman

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 13 Dec 2013 21:20:32 -0800

I don't know what the "do it in HTTP/2 itself" proposal is. I thought
your proposal was advertising opportunistic encryption in DNS. Anyhow,
we don't support any type of opportunistic encryption, especially
unauthenticated. We want people to use https://, therefore we more or
less only plan to support HTTP/2 for https:// URIs. Let me know if
this still leaves anything unclear.

On Fri, Dec 13, 2013 at 8:45 PM, Paul Hoffman <[email-masked]> wrote:
> On Thu, Dec 12, 2013 at 12:05 PM, William Chan (陈智昌) <[email-masked]>
> wrote:
>>
> proposed other methods, such as my "do it in HTTP/2 itself". I can interpret
> your message both ways.
>
> --Paul Hoffman

---

From: Roberto Peon <[email-masked]>
Date: Sat, 14 Dec 2013 10:23:39 -0800

Yup.
-=R
On Dec 12, 2013 3:58 PM, "Mark Nottingham" <[email-masked]> wrote:

> That's true, *if* clients implement the http2-tls protocol identifier
> semantics uniformly; otherwise, they won't know whether they need to offer
> a valid certificate to upgrade to that protocol.
>
> When I wrote this draft, there was still active debate; some people
> thought opp encryption without authentication could be useful, whereas
> others are firm that this is not a good direction, and opp encryption
> should only happen when coupled with strong server auth.
>
> If we overload the semantics of http2-tls (ignoring the exact syntax of
> the identifier) to mean "opportunistic encryption without authentication",
> but some browsers require authentication, we have an interop problem, and
> opp encryption without authentication is effectively impossible to use.
>
> Now, if no one is interested in using TLS with authentication for http://URIs, this problem (probably) goes away. The one thing that worries me a
> tiny bit is that a browser's position about what an acceptable mix of
> security characteristics might change over time, and if it does, we may
> need this distinction again. However, since we're using draft identifiers,
> it's not a huge risk.
>
> Based on this discussion, it sounds like I can go ahead and remove h2r and
> refine the semantics of h2t to include the HTTP URI use case (i.e., no auth
> if on the same host, strong auth if on a different host).
>
> Make sense?
>
> Cheers,
>
>
>
> > 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

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 14 Dec 2013 11:14:33 -0800

On Fri, Dec 13, 2013 at 9:20 PM, William Chan (陈智昌)
<[email-masked]>wrote:

> I don't know what the "do it in HTTP/2 itself" proposal is.

http://tools.ietf.org/html/draft-hoffman-httpbis-minimal-unauth-enc-01

> I thought
> your proposal was advertising opportunistic encryption in DNS.

That is orthogonal, and is *not* opportunistic encryption: it allows a
browser to change the URI scheme from "http:" to "https:".

> Anyhow,

That's completely clear.

I disagree with your conclusion, and still want HTTP/2 to enable
opportunistic encryption in a way that browsers and servers will deploy,
but I'm not a browser vendor.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 14 Dec 2013 19:20:40 +0000

Possibly a different thread really but...

> this still leaves anything unclear.

What that leaves unclear for me is how the current 30-40% of web
sites that are setup for some form of TLS will suddenly become
99%. Without some other action on helping sites get certs, it
just won't happen would be my prediction.

I think its all the more puzzling when contrasted with other cases
where people claim that we can't do X because that'd cause a problem
for 1% of the web, but yet here you seem to be saying its ok to
do this when it'd cause a problem for 60-70% of the web. (I don't
recall whether or not you've made such claim William.)

Even if only as a backup in case that 30-40% -> 99% transition
fails, I'd hope folks do continue working on ways to provide
opportunistic encryption for HTTP/2.0.

On the current draft - its seems quite odd to ignore the existing
anon-DH ciphersuites when trying to do opportunistic encryption.

S.

---

From: Tim Bray <[email-masked]>
Date: Sat, 14 Dec 2013 11:41:00 -0800

On Sat, Dec 14, 2013 at 11:20 AM, Stephen Farrell <[email-masked]

> just won't happen would be my prediction.

The ones who can’t/won’t deploy TLS stay with HTTP/1.1, that’s all.  Or am
I missing something?

---

From: Brian Smith <[email-masked]>
Date: Sat, 14 Dec 2013 12:40:58 -0800

> just won't happen would be my prediction.

We need to focus our effort on that problem.

There are already at least three commercial CAs, that browsers trust, that
give away free certificates: StartCom (restricted to non-business use),
GlobalSign (restricted to open source projects), and GoDaddy (restricted to
open source projects). These CAs give away an inferior good (presumably) in
the hopes of you eventually upgrading to their non-free goods. The main
problem with these CAs' freemium models is that their decision process for
whether you qualify for the free product isn't (and cannot be) automated.
However, I believe there is an opportunity for us (browser makers in
particular, and the IETF community in general) to create a new kind of
inferior good in the certificate space that CAs (possibly other than the
ones I mentioned) may be willing to give away for free in a way that allows
CAs to be comfortable with, without jeopardizing their businesses. Note:
when I say "inferior good," I use "inferior" in the economic sense only; I
think we'd insist that such certificates have security properties at least
as good as what we already accept as the minimum in browsers today.

Even if such efforts were to fail, we still wouldn't be at the point where
completely unauthenticated encryption is the only option left. There are
other ways of authenticating servers than punting to a commercial CA. We
should make sure we have thoroughly exhausted these alternatives before
giving up.

> recall whether or not you've made such claim William.)

When it comes to breaking interoperability or regressing performance, small
percentages like 1% matter. The fact that most connections web browsers
make are not encrypted+authenticated is a huge problem that needs to be
addressed with strong action, but it isn't acute in the way that a
compatibility or performance regression is.

Difficulty with certificates doesn't explain why bing.com, reddit.com,
tumblr.com, baidu.com, wikipedia.com, and other top sites aren't
HTTPS-only. Social issues (wikipedia has been very open about how politics
affects their HTTPS deployment) and performance issues are much more
serious issues, and those issues won't be properly addressed by adding
opportunistic encryption to HTTP/2.

Do third-party advertising sites (the kind whose cookies are being used to
de-anonymize users) use HTTP instead of HTTPS because they can't afford
certificates? No. Performance, scalability, the pain or migrating websites
from http:// to https:// URLs, and lack of motivation seem to be the
problems. Web browsers can encourage them to move to HTTPS by getting them
on our HSTS preload lists (so the browser "fixes" those http:// links to
https:// links automatically) and by doing other things. For example, at
Mozilla we've long had a desire to strip cookies from third-party requests
that aren't HTTPS. It seems like now is the time to figure out how to make
that work. We've already seen big advertisers make changes like this to
accomodate our recent mixed-content blocking changes. I'm confident that
such advertisers would be willing to accomodate further changes, if nudged
a little bit.

> opportunistic encryption for HTTP/2.0.

I agree that it is reasonable to continue to explore unauthenticated
encryption options. However, I encourage people to support the efforts to
go further--to try to hit a home run instead of trying to bunt.

> anon-DH ciphersuites when trying to do opportunistic encryption.

The way cipher suites are currently negotiated in TLS, with the client
saying which cipher suites it supports and the server choosing one, suffers
from the same problem that ALPN causes for http2-tls-relaxed: the client is
telling potential MitMs whether or not they will get caught. I appreciate,
and agree with, the fundemental aims of the perpass effort. However, I
think way too much emphasis is being put on the "passive" part. We need to
remember that perfect is the enemy of the good, but at the same time it
would be unfortunate to spend a huge amount of effort trying to prevent
passive attacks while making active attacks easier to carry out.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 14 Dec 2013 20:55:17 +0000

In message <CAFewVt6j0yaRboARj=[email-masked]>
, Brian Smith writes:

>give away free certificates: [...]

That's not really the key problem.

The key problem is that there are too many CAs which have been
willing or coerced to hand over bits, which allowed certain people
to lie about who they were.

Forcing or coercing people to use a known broken solution, which only
pretends to offer security, is at best deceptive and certainly
worse than letting people knowingly use plaintext.

Until you can offer a secure alternative, trying to force people
to use snake-oil security is just wrong.

---

From: Brian Smith <[email-masked]>
Date: Sat, 14 Dec 2013 12:57:13 -0800

> Make sense?

I am not sure it makes sense, but also I am not sure I understand the
proposal. It seems like you are proposing to move the defense against MitM
from TLS to the HTTP layer, where the HTTP layer will try to prevent MitM
by checking the scheme on each individual request. However, in HTTP/2,
isn't it the case that there are other types of things that get sent and
received on the connection besides requests and responses? Option
negotiation and whatnot? How would the server know that *those* things,
which don't have URIs associated with them, are authenticated or not?

Again, I think I might be misunderstanding the proposal, and more clarity
would be helpful.

Cheers,
Brian

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 14 Dec 2013 23:16:55 -0800

> just won't happen would be my prediction.

Either helping sites get certs, or adding support for self-signed certs. Maybe combine self-signed certs and pinning. Maybe use a naming convention, something like "www-selfsigned.example.com." Or maybe www-07FDAE37.example.com, where 07FDAE37 is some identifier of the self-signed cert. If the browsers knew to expect a self-signed cert, they would not have to put up the scary UI when they find one...

-- Christian Huitema

---

From: Yoav Nir <[email-masked]>
Date: Sun, 15 Dec 2013 13:53:22 +0200

> Either helping sites get certs, or adding support for self-signed certs. Maybe combine self-signed certs and pinning. Maybe use a naming convention, something like "www-selfsigned.example.com." Or…
No scary UI means that a MitM or someone who has compromised the DNS can 
hijack your connection, show a self-signed cert, and get no indication 
to the user that something is wrong.  So (let's use hotmail, because not 
all examples have to be gmail):

http://hotmail.com  redirects to https://selfsigned.live.com  which has 
a self-signed certificate, and everything looks fine.  Except it's an 
attacker.

They can mitigate this by adding HSTS, or better yet, HPKP. But that is 
forcing the website to do work just to regain the scary UI.

Making pinning a requirement for using self-signed certificates seems 
backwards, as pinning is dangerous stuff (see all the warnings in the 
draft) that can easily brick your website. I don't think it's suitable 
for the 60-70% who can't or won't get a proper certificate. If you can't 
afford a $10 DV certificate, you can't afford the IT staff to do HPKP 
safely.

Yoav

---

From: "Adrien de Croy" <[email-masked]>
Date: Sun, 15 Dec 2013 22:09:30 +0000

------ Original Message ------
From: "Tim Bray" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: "William Chan (陈智昌)" <[email-masked]>; "Paul Hoffman" 
<[email-masked]>; "HTTP Working Group" <[email-masked]>
Sent: 15/12/2013 08:41:00
Subject: Re: Fwd: New Version Notification for 
draft-nottingham-http2-encryption-02.txt
>On Sat, Dec 14, 2013 at 11:20 AM, Stephen Farrell 
><[email-masked]> wrote:
>>
>The ones who can’t/won’t deploy TLS stay with HTTP/1.1, that’s all.  Or 
>am I missing something?

Maybe you're missing the discussion we had about the 
futility/unacceptability of the "they can just use HTTP/1.1" argument.

---

From: "Adrien de Croy" <[email-masked]>
Date: Sun, 15 Dec 2013 22:14:23 +0000

I'm pretty sure this argument (there are free certs so we should all use 
them for everything) has been floated and sunk about 3 times on this 
list.

Maybe we need some place where we can collect these arguments and the 
results of them so we can post referrals to that place instead of doing 
that work over and over?

Adrien

------ Original Message ------
From: "Brian Smith" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: "William Chan (陈智昌)" <[email-masked]>; "Paul Hoffman" 
<[email-masked]>; "HTTP Working Group" <[email-masked]>
Sent: 15/12/2013 09:40:58
Subject: Re: Fwd: New Version Notification for 
draft-nottingham-http2-encryption-02.txt
>There are already at least three commercial CAs, that browsers trust, 
>that give away free certificates: StartCom (restricted to non-business 
>use), GlobalSign (restricted to open source projects), and GoDaddy 
>(restricted to open source projects). These CAs give away an inferior 
>good (presumably) in the hopes of you eventually upgrading to their 
>non-free goods. The main problem with these CAs' freemium models is 
>that their decision process for whether you qualify for the free 
>product isn't (and cannot be) automated. However, I believe there is an 
>opportunity for us (browser makers in particular, and the IETF 
>community in general) to create a new kind of inferior good in the 
>certificate space that CAs (possibly other than the ones I mentioned) 
>may be willing to give away for free in a way that allows CAs to be 
>comfortable with, without jeopardizing their businesses. Note: when I 
>say "inferior good," I use "inferior" in the economic sense only; I 
>think we'd insist that such certificates have security properties at 
>least as good as what we already accept as the minimum in browsers 
>today.
>
>Even if such efforts were to fail, we still wouldn't be at the point 
>where completely unauthenticated encryption is the only option left. 
>There are other ways of authenticating servers than punting to a 
>commercial CA. We should make sure we have thoroughly exhausted these 
>alternatives before giving up.
>
>When it comes to breaking interoperability or regressing performance, 
>small percentages like 1% matter. The fact that most connections web 
>browsers make are not encrypted+authenticated is a huge problem that 
>needs to be addressed with strong action, but it isn't acute in the way 
>that a compatibility or performance regression is.
>
>HTTPS-only. Social issues (wikipedia has been very open about how 
>politics affects their HTTPS deployment) and performance issues are 
>much more serious issues, and those issues won't be properly addressed 
>by adding opportunistic encryption to HTTP/2.
>
>Do third-party advertising sites (the kind whose cookies are being used 
>to de-anonymize users) use HTTP instead of HTTPS because they can't 
>afford certificates? No. Performance, scalability, the pain or 
>migrating websites from http:// to https:// URLs, and lack of 
>motivation seem to be the problems. Web browsers can encourage them to 
>move to HTTPS by getting them on our HSTS preload lists (so the browser 
>"fixes" those http:// links to https:// links automatically) and by 
>doing other things. For example, at Mozilla we've long had a desire to 
>strip cookies from third-party requests that aren't HTTPS. It seems 
>like now is the time to figure out how to make that work. We've already 
>seen big advertisers make changes like this to accomodate our recent 
>mixed-content blocking changes. I'm confident that such advertisers 
>would be willing to accomodate further changes, if nudged a little bit.
>
>encryption options. However, I encourage people to support the efforts 
>to go further--to try to hit a home run instead of trying to bunt.
>
>saying which cipher suites it supports and the server choosing one, 
>suffers from the same problem that ALPN causes for http2-tls-relaxed: 
>the client is telling potential MitMs whether or not they will get 
>caught. I appreciate, and agree with, the fundemental aims of the 
>perpass effort. However, I think way too much emphasis is being put on 
>the "passive" part. We need to remember that perfect is the enemy of 
>the good, but at the same time it would be unfortunate to spend a huge 
>amount of effort trying to prevent passive attacks while making active 
>attacks easier to carry out.
>
>Cheers,
>Brian
>--

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sun, 15 Dec 2013 15:03:28 -0800

I don't recall this argument being sunk. Can you provide a reference
or explain why?

On Sun, Dec 15, 2013 at 2:14 PM, Adrien de Croy <[email-masked]> wrote:
> them for everything) has been floated and sunk about 3 times on this list.
>
> results of them so we can post referrals to that place instead of doing that
> work over and over?
>
> Adrien
>
>
> percentages like 1% matter. The fact that most connections web browsers make
> are not encrypted+authenticated is a huge problem that needs to be addressed
> with strong action, but it isn't acute in the way that a compatibility or
> performance regression is.
>
> tumblr.com, baidu.com, wikipedia.com, and other top sites aren't HTTPS-only.
> Social issues (wikipedia has been very open about how politics affects their
> HTTPS deployment) and performance issues are much more serious issues, and
> those issues won't be properly addressed by adding opportunistic encryption
> to HTTP/2.
>
> such advertisers would be willing to accomodate further changes, if nudged a
> little bit.
>
>>
> encryption options. However, I encourage people to support the efforts to go
> further--to try to hit a home run instead of trying to bunt.
>
>>
> and agree with, the fundemental aims of the perpass effort. However, I think
> way too much emphasis is being put on the "passive" part. We need to

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 15 Dec 2013 23:24:10 +0000

On 12/14/2013 08:40 PM, Brian Smith wrote:
> open source projects).

One problem with that is that startcom is only free for 2nd level
domains (iirc). For those its great and I've used it and would
recommend it - once I had mail setup for the domain it only took
20 minutes to get all the cert stuff sorted. Having said that,
I've no idea how secure any of their stuff is, but for a case
where all I want is to get rid of the stupid cert warning dialog,
what they do is just fine.

But, AFAIK, there's nothing I can get for e.g. my server at
https://down.dsg.cs.tcd.ie/ Now in theory I could get something
done via tcd.ie but that's in fact not possible due to our fun
central university IT folks (same old story:-) and the way that
the cs n/w in college is autonomous from the rest of tcd.ie.

Now that's all very specific to my server, but I think its (only
2nd level domains) likely just one of the gaps between that 30-40%
and the 99% goal.

Separately, I'm not sure I buy the just-use-1.1 argument that Tim
made, there's no reason why this particular problem is different
in that respect. So I don't see why just-use-1.1 is a good answer
here unless its a good answer everywhere, which doesn't seem to
be the case.

But yes, work in this space would be great. Doesn't seem to
be happening yet though. So colour me skeptical for now at least.

S.

---

From: "Adrien de Croy" <[email-masked]>
Date: Sun, 15 Dec 2013 23:40:18 +0000

Hi

would need to trawl the last 4 months or so messages to pick all the 
bits out.

But I think the general issues are these.

nothing is truly free
you get what you pay for

There's more to PKI than just the issuing of certs.  How can we trust 
certs if no attempt has been made by the CA to properly validate 
identity of applicants?  How can a CA afford to run DoS-proof OCSP 
servers if you don't pay them?  How can they also afford to keep their 
private key secure against increased risk of attack (increased incentive 
/ reward for breaking) etc etc etc.

How can a CA currently offering free certs suddenly provide 1000 times 
(or more?) as many free certs and still have them be free?

I just don't think it stacks up for there still to be free certs that 
are worth anything once everyone has to have a cert, and the place that 
leaves us is worse than where we are now.  A proliferation of worthless 
(untrustable) certs on a vast scale.

I think this is why people have been proposing alternatives to CA-issued 
certs.

Adrien

------ Original Message ------
From: "William Chan (陈智昌)" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Brian Smith" <[email-masked]>; "Stephen Farrell" 
<[email-masked]>; "Paul Hoffman" <[email-masked]>; 
"HTTP Working Group" <[email-masked]>
Sent: 16/12/2013 12:03:28
Subject: Re: Fwd: New Version Notification for 
draft-nottingham-http2-encryption-02.txt
>>least
>>where
>>small
>>HTTPS-only.
>>suffers

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 15 Dec 2013 16:30:39 -0800

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Sunday, December 15, 2013 3:53 AM
To: [email-masked]
Subject: Re: Fwd: New Version Notification for draft-nottingham-http2-encryption-02.txt

Yoav

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 15 Dec 2013 16:37:16 -0800

From: Yoav Nir [mailto:[email-masked]], Sunday, December 15, 2013 3:53 AM

> a self-signed certificate, and everything looks fine.  Except it's an 

The problem is really the insecure redirect, not the use of a self-signed certificate. We could have: http://hotmail.com  redirects to https://recorder.dgse.fr  which has  a CA-signed certificate, and everything looks fine. The only protection against that one is to connect to "https://hotmail.com," and get an authentic redirect if needed. 

-- Christian Huitema

---

From: Yoav Nir <[email-masked]>
Date: Mon, 16 Dec 2013 14:02:20 +0200

> From: [email-masked]
> To: [email-masked]; [email-masked]
> Date: Sun, 15 Dec 2013 16:37:16 -0800
> Subject: RE: Fwd: New Version Notification for draft-nottingham-http2-encryption-02.txt
> 

But how can you get an authentic redirect, if hotmail.com does not have a CA-issued certificate? And if it does, why not use that rather than a self-signed certificate?

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Dec 2013 09:43:38 -0800

On 16 December 2013 04:02, Yoav Nir <[email-masked]> wrote:
> But how can you get an authentic redirect, if hotmail.com does not have a
> CA-issued certificate? And if it does, why not use that rather than a
> self-signed certificate?

That was somewhat the point of the comment I think.  If you are going
to avoid getting a good certificate, then you also avoid all the
advantages, like resilience against active attacks like that.

A self-signed certificate does allow for things that are TOFU-like,
but not perfectly.  Things like CT help too.  Obviously,
http://hotmail.com should have a certificate that is signed by a CA
and HSTS turned on.  (Sadly, in reality, it has the former; instead of
the latter, it provides a P3P header :( )  Those things cost.

As an aside, I really would like people to recognize the non-monetary
costs here, which are far more relevant.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Dec 2013 18:02:46 +0000

On 12/16/2013 05:43 PM, Martin Thomson wrote:
> but not perfectly.  Things like CT help too.  

But afaik CT doesn't help with self-signed or equivalent TOFU
things as it relies on the CAs to avoid the log being spammed.
If there were a way to let web sites use CT for self-signed
certs, that'd be interesting but I thought that the CT folks
didn't like that idea.

S.

> Obviously,

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Dec 2013 10:28:54 -0800

> certs, that'd be interesting but I thought that the CT folks

The idea does create an authority problem.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Dec 2013 10:59:49 +0100

> I don't recall this argument being sunk. Can you provide a reference
Or conversely, could you point to a list of freely available CAs that
Chrome or Chromium supports?  As someone who gets an annual bill, I'd
love to know.  Alternatively, I'd love to hear when you expect Chrome to
support DANE.  I'm licking my chops for that...

Eliot

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 17 Dec 2013 09:36:29 -0800

Did you mean CAs that offered free certs? Brian listed this earlier already.

And I know there are DANE fans here...I don't really want to talk
about it here since it'll distract from the conversation. Please ask
at https://code.google.com/p/chromium/issues/detail?id=50874. But in
short, I believe we have no plans to implement.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Dec 2013 20:22:06 +0100

Hi Will,

I'm a pretty simple guy and what will follow is simple logic.  But maybe
it's wrong (indicating I'm simpler still).  See below, please.

> Did you mean CAs that offered free certs? Brian listed this earlier already.

That list was problematic.  It does not provide for general availability
of certificates, but for open source projects, and other limited groups,
an "inferior product" as Brian called it.

> short, I believe we have no plans to implement.

Bringing this back around to draft-nottingham-http2-encryption, the
document poses a problematic issue around what is mandatory to
implement.  Some browser developers have made it clear that they're not
going to do unencrypted http2.  If reality is that HTTP2 will only be
implemented by browsers via TLS, then there are exactly to paths one can
follow:

1.  Everyone can and will use TLS in all circumstances; or
2.  Not everyone can and will use TLS in all circumstances, and hence
HTTP2 is not a replacement for HTTP.

Let us assume that (1) is the intended target.  In that case, we have
the following options:

 1. Demonstrate that free certificates are generally available,
 2. Use unauthenticated or opportunistic encryption,
 3. See that DANE is delivered, or
 4. develop another option.

Personally I don't believe (A) and you and I have thus far rejected
(B)[*].  That leaves (C), which I personally like and you have no plan
to implement, or (D).  If you would like to avoid the distraction,
kindly correct my understanding?  Maybe you don't grant assumption of
(1).  I don't think others do, but the charter sort of pushes that
point.  Anyway, this is the reason we keep circling back to DANE, as I
see it.

Eliot

[*] I might be convinced that some form of encryption is yet a good idea.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Dec 2013 14:36:21 -0800

On 17 December 2013 11:22, Eliot Lear <[email-masked]> wrote:
> Demonstrate that free certificates are generally available,

I'll make my point again.  Zero dollars (or your currency of choice)
is not the same as zero friction.  It's an important part, but as long
as it requires anything other than zero effort, free is still
insufficient to move the needle in any meaningful way.

As long as I can 'apt-get install httpd' and whatever else I need to
do to get unsecured HTTP going, the effort required to get a secured
certificate had best be as close to zero in addition to that as
possible.

Yes, there are other concerns, like performance, but I haven't found
arguments around those particularly compelling from an end-user
perspective.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Dec 2013 22:44:20 +0000

> certificate had best be as close to zero in addition to that as

/me sings a song about opportunistic encryption again:-)

S

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Dec 2013 15:47:23 -0700

On 12/17/13 3:44 PM, Stephen Farrell wrote:
>> As long as I can 'apt-get install httpd' and whatever else I need
>> to do to get unsecured HTTP going, the effort required to get a
>> secured certificate had best be as close to zero in addition to
>> that as possible.
> 

Opportunistic or unauthenticated?

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 18 Dec 2013 18:00:15 +1100

On 18 Dec 2013, at 6:22 am, Eliot Lear <[email-masked]> wrote:

> Bringing this back around to draft-nottingham-http2-encryption, the document poses a problematic issue around what is mandatory to implement.  Some browser developers have made it clear that they're not going to do unencrypted http2.  If reality is that HTTP2 will only be implemented by browsers via TLS, then there are exactly to paths one can follow:
> 
> 2.  Not everyone can and will use TLS in all circumstances, and hence HTTP2 is not a replacement for HTTP.
> 
> Let us assume that (1) is the intended target.  In that case, we have the following options:
> 	A. Demonstrate that free certificates are generally available,
> 	B. Use unauthenticated or opportunistic encryption,
> 	C. See that DANE is delivered, or
> 	D. develop another option.
> Personally I don't believe (A) and you and I have thus far rejected (B)[*].  That leaves (C), which I personally like and you have no plan to implement, or (D).  If you would like to avoid the distraction, kindly correct my understanding?  Maybe you don't grant assumption of (1).  I don't think others do, but the charter sort of pushes that point.  Anyway, this is the reason we keep circling back to DANE, as I see it.

You don't talk about (2). What is your position on that outcome?

Our charter says:

> The resulting specification(s) are expected to meet these goals for common
> existing deployments of HTTP; in particular, Web browsing (desktop and
> mobile), non-browsers ("HTTP APIs"), Web serving (at a variety of scales), and
> intermediation (by proxies, corporate firewalls, "reverse" proxies and Content
> Delivery Networks).

Note "specifications." I.e., we're not required to make HTTP/2 a replacement for HTTP/1 *in the market*, as such; only to make the specs suitable for it. Again, no one has proposed that the HTTP/2 spec say that it only works across TLS.

In fact, it goes on to explicitly place "Specifying how the HTTP protocol is to be used or presented in a specific use case (e.g., in Web browsers)" as out of scope, meaning that, technically, *all* of this discussion is off-topic, since we're not (as per our charter) going to specify what Web browsers do per se; we're just defining the protocol on the wire. Nothing in 2616 prevents a Web browser from deciding to only support https://, for example, and -- so far -- HTTP/2 is just as neutral as /1.

Now, I suspect that we may decide that we *want* to specify (or at least document) browser behaviour regarding HTTP/2 to improve interop in that use case; if so, we'll need to get the charter changed. However, I'm not at all inclined to use such a change to force browsers to behave against their will, or to use it as "leverage" against them, since they're heavily invested in this process already based upon the current charter. 

Needless to say, discussions in Zurich should be interesting.

Cheers,

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Dec 2013 09:00:33 +0100

Hi Mark,

On 12/18/13 8:00 AM, Mark Nottingham wrote:

> [...]

Since you asked...

> Note "specifications." 

Well, no: "specification(s)".  The WG should conscientiously decide this
at some point.  We have many examples going in either direction.  But it
seems premature to discuss the matter now.

> I.e., we're not required to make HTTP/2 a replacement for HTTP/1 *in the market*, as such; only to make the specs suitable for it. 

To answer your other question and the charter, since you went there, I
don't really see a net benefit for most non-browser uses.  We've limited
participation from non-browser people in this working group.  The
charter says a bunch of other things as well that will probably cause
problems down the line, if not addressed.  But sometimes that means the
community should change or ignore the charter and not the spec.  Quite
frankly we're not there yet and there's good work being done.  Let's not
lose that fact.

> Again, no one has proposed that the HTTP/2 spec say that it only works across TLS.

And now let us add up the previous email with my statement above.  A
lack of interest from non-browsers and a statement from most browser
people that they aren't going to implement HTTP/2 upgrade means that it
will only work over TLS.  Ok... so then let's come back to path (1) and
sort the issues associated with it.
> In fact, it goes on to explicitly place "Specifying how the HTTP protocol is to be used or presented in a specific use case (e.g., in Web browsers)" as out of scope, meaning that, technically, *all…

Keep in mind the Tao: rough consensus and running code.  Think about the
shepherd write-up that must be done.  Whatever the charter says, we're
discussing running code at this point.  It's the generality of the spec
that's in question, but see above.  That doesn't necessarily mean change
the spec.

> Now, I suspect that we may decide that we *want* to specify (or at least document) browser behaviour regarding HTTP/2 to improve interop in that use case; if so, we'll need to get the charter chang…

Since none of us are kings or deities nobody will be forcing anyone to
do anything.  The issue I was addressing was really that DANE is
something that can facilitate deployment of the specification, and that
it is directly relevant to the previous discussion.  Especially if you

> insufficient to move the needle in any meaningful way.

I couldn't agree more, and I've said as much.  One of the reasons DANE
is very attractive is that it addresses not only the cost of the certs
but also the friction you mention.  It's a whole lot easier for a
developer to consider a platform in which certificates are entirely
registered through the local DNS.

Eliot

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 18 Dec 2013 17:11:26 +0900

> the cs n/w in college is autonomous from the rest of tcd.ie.

Hello Stephen,

Thanks for the heads-up! I was occasionally day-dreaming about getting a 
free certificate for my site. But I'm in exactly the same situation as 
you (five levels deep, central university IT,...). On top of that, I 
have organized my stuff so that I use different domains for different 
services, which as I understand means I need multiple certs. But maybe 
some day I'll try with self-signed ones, especially for the 
student-oriented services, because I could tell my students how to check 
that they get the right cert.

Regards,   Martin.

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 18 Dec 2013 19:30:05 +1000

On 18 December 2013 18:00, Eliot Lear <[email-masked]> wrote:

> will only work over TLS.

"We are one browser vendor who is in support of HTTP 2.0 for HTTP:// URIs.
 The same is true for our web server."  --Rob Trace from Microsoft.
<http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0662.html>

They might be market losing share, but I think IE still counts.  I have
trouble reconciling the above statement with your assertion that browsers
won't implement upgrade, since I don't know how else IE could support
HTTP/2 for http:// URIs, unless some other magic pre-negotiation mechanism
is invented (or possibly a best-effort fallback behaviour: try /2 first, if
it fails try /1; but I digress).  As noble or whatever as the effort to
promote TLS-everywhere may be, I've seen enough points raised in this
discussion to argue the case against fully encrypted connections in some
contexts, and a case *for* HTTP2 (and its improvements) on connections in
an intersecting set of contexts.  Some of those even included browser-based
access (so I believe IE is doing the Right Thing™).

The condition "that HTTP2 will only be implemented by browsers via TLS" is
flawed, and therefore your first list (1-2) is moot.  Point (1) is already
off the table (or on the table, depending on your preferred idiomatic
phrase for "not up for discussion"), and point (2) is only true if you
change it to "... hence encrypted-only HTTP2 is not a replacement...",
which is a tautology.  The charter as it stands, designing a full
replacement for the HTTP/1 spec, is, I believe, correct.  Implementations
are free to cherry-pick the bits they support, as long as their failure
modes for all the other bits fit the spec.  WRT browsers, if they never
make a connection that *isn't* over TLS, then that's completely up to them.

This doesn't in any way diminish your further list (A-D) for options if and
when encryption/security is used, but it makes it less of (or completely
not) a priority for this WG; instead it's on whoever decides not to
implement unencrypted HTTP/2.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 18 Dec 2013 10:03:06 -0500

> Opportunistic or unauthenticated?

Serious question: are those different? Not sure if that has been
hashed out yet, but willing to read more if I've missed it. best, Joe

- -- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Michael Sweet <[email-masked]>
Date: Wed, 18 Dec 2013 10:32:10 -0500

Eliot,

On Dec 18, 2013, at 3:00 AM, Eliot Lear <[email-masked]> wrote:
> ...

From a resource perspective alone I think multiplexing requests over a single connection is a major win for any HTTP-based RPC protocol (IPP, SOAP, REST, etc.) where you expect to send or receive more than one message.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Roberto Peon <[email-masked]>
Date: Wed, 18 Dec 2013 09:58:50 -0800

Yes, they absolutely can be different.

In the 'opportunistic' world, you attempt to use TLS whether or not the
scheme is HTTP or HTTPS.
In the 'unauthenticated' world, you accept an unauthenticated endpoint when
the scheme is HTTP.

The latter depends on the former, but is otherwise completely separate.

-=R

On Wed, Dec 18, 2013 at 7:03 AM, Joseph Lorenzo Hall <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJSsbkqAAoJEF+GaYdAqahxLmUQAIEDuUyLvabSVKrU53f4ZOQD
> Xv5RHr66H7VCKHpSaepStGmavm3lzbNp6e2FeRftpn46ho99+vjmQLQUSA9U/G6j
> ohi2aFbcHYvjH7ca2q9y6M7Dl+elLHKHJxnn68gqDDq/yWTNeVgrq4It0Bh4xq2p
> qDYypQj8xyI6slw1VwJa7STHRhj7CwL4dlYE/BIyJQNCnJpqLj7bTF62GRFcQkKO
> 7p9/rvAbd2cYjNzodzb+JNzAKm1uSKRyj7ufUO61j2WKi7AO5uAWagMD+64trAhj
> hwGUqiDjuCpMoQlNC0MYR9ssL0QVI+/jmb6ps+ZcKzw1G1AxXX3eQd6CVTf2ez0s
> UzdxuRxxNviYkbiIqnraP4NxrA2oxH88h/fOG+BRJ0K64Wb3gCDpcD8wbb29CJpu
> zi3xnmZyGHWfV25rj5u3vlbLnbviZ4C8edSBeqwKBPs1LZ8ULhi+1acoZiBfvx/u
> 121NGKcC13dr09idTUk9d4JCvKbmCxsDtJ6TS/b6kL7DnkgX+ggq5KLcdowAFq8a
> P0Nkbh6C53C8t0X+jZRrqvGvPx7EvLvi0ocdhQTKUKqimVc44DhyVVs9NicNZdvZ
> +aIukLu+b55Gdo00WeqMh+LqZT5yBaDGmXQKAbKdWcKf6bHk+gfL+m+9xl6IXhZR
> ySbSvJzxdIfr93lztcJO
> =eApo
> -----END PGP SIGNATURE-----
>
>
>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 18 Dec 2013 10:16:40 -0800

In reference to Mark's document:

We want an identifier that describes what wire protocol is going to be
spoken. This is useful whether upgrading via UPGRADE, via alt-svc,
alt-protocol, etc.
It seems reasonable to indicate both http with tls on tcp or http without
tls on tcp. Thusfar those are the options we know are likely to happen.

I could do without h2r. The client will decide what to do w.r.t.
authentication anyway. If we decide we wish to have the server advertise
what it'd like to see happen, then we can add that in as h2r later, and
nothing old will break.

@Elliot
My understanding of what Jeff Pinner has been saying is that the stuff
we've been doing has been quite useful in practice (today) for Twitter.

-=R

On Wed, Dec 18, 2013 at 7:32 AM, Michael Sweet <[email-masked]> wrote:

> >> I.e., we're not required to make HTTP/2 a replacement for HTTP/1 *in
> the market*, as such; only to make the specs suitable for it.
> >
> From a resource perspective alone I think multiplexing requests over a
> single connection is a major win for any HTTP-based RPC protocol (IPP,
> SOAP, REST, etc.) where you expect to send or receive more than one message.
>

---

From: Jeff Pinner <[email-masked]>
Date: Fri, 20 Dec 2013 17:48:38 -0800

> we've been doing has been quite useful in practice (today) for Twitter.

Just to insert some data on the "usefulness" of HTTP/2 for the non-browsers
use-case, at Twitter we have deployed SPDY on our iOS client, and when
connecting to our API, we have observed as much as a 30% decrease in
latency over HTTP/1.1. (See
https://blog.twitter.com/2013/cocoaspdy-spdy-for-ios-os-x)