Subject: Berlin Minutes

From: Mark Nottingham <[email-masked]>
Date: Fri, 23 Aug 2013 13:56:48 +1000

... are now up at:
  http://www.ietf.org/proceedings/87/minutes/minutes-87-httpbis

Corrections / updates to me.

Regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: Eliot Lear <[email-masked]>
Date: Sun, 25 Aug 2013 08:16:30 +0200

Mark,

Regarding the minutes of the group, the working group declined to
mandate encryption for a number of reasons, not just back end services. 
What I said the last time, was that we can damage overall Internet
security by inuring people to certificate warnings – or we will inhibit
adoption of HTTP2 – unless the mechanisms to manage certificates
improve.  In addition many thousands of small devices exist without a
simple means to enroll – and pay.  Even if they do enroll – and pay, the
current certificate mechanisms require that they re-enroll - and pay. 
And so they don't.  There simply is no magic bullet.  The economics are
clear.  The means to encrypt has existed nearly two decades.   Mandating
encryption from the IETF has been tried before – specifically with IPv6
and IPsec.  If anything, that mandate may have acted as an inhibitor to
IPv6 implementations and deployment and served as a point of ridicule.

And so, I do not agree with those who hummed in favor of mandatory
encryption.  HTTP2 is already very complex and is biting off enough. 
The more it bites off the less likelihood of broad adoption.  We've seen
this movie before.  What we will have instead of HTTP/2 will be an
optional alternative to HTTP/1.1 that is deployed by large scale high
performance services.  Maybe that was always the goal, but if so, let's
recognize that and relabel.  I was under a different impression.

If we wish to explore new means to authenticate endpoints, that would be
a better starting point.

Eliot

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sun, 25 Aug 2013 15:07:08 +0800

Just chiming in here since I'm concerned that a misinterpretation of the
minutes may have led to an accidental straw man argument.

Eliot, can you clarify what section of the minutes you're responding to? I
see only one hum for HTTP/2:
"""
Who believes that these issues are worthy of further discussion: Hum in
support:strong hum. Hum against: silence. Good, and we are now at the end of
the alloted time for this.
"""

I don't see anything on humming on mandatory encryption. I note that
there's a section of the minutes where Larry and Mark are clarifying the
topic, since Larry said the topic was introduced as mandatory to implement
security, whereas Mark clarified:
"""
Mark says â€œmandatory to offerâ€ is closer
to what he said.
"""

So, I don't believe "mandatory encryption" was even discussed at the last
IETF, merely mandatory to offer [i forget if it was security or encryption,
but I suspect encryption]. And let's be precise about the language, since
security != encryption. You mentioned encryption, and then talked about
certificate warnings. Let's remember you can try to encrypt without
authenticating the peer.

Now, we can have a debate about whether or not mandatory encryption is
security theater, but I think no one is beating that drum right now
(although I won't preclude the possibility of someone stepping up to do
so). So it's probably best to stick to the topic that we discussed at the
last IETF, namely mandatory to offer [encryption?], unless someone would
like to discuss mandatory encryption right now.

Cheers.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 25 Aug 2013 07:09:45 +0000

In message <[email-masked]>, Eliot Lear writes:

>encryption.

Agreed:  The present mess cannot be solved by more encryption, it
will take politics to fix it:
	http://queue.acm.org/detail.cfm?id=2508864

-- 
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: Salvatore Loreto <[email-masked]>
Date: Sun, 25 Aug 2013 09:10:16 +0200

I don't think we were questioning the possibility to speak between 
client and server
without any encryption if both parties agree to speak in clear (i.e. TLS 
is not mandatory to use)

The hum, at least how I understood it, was only in favor to investigate 
a way to provide
from one side equal power to the client:
i.e. to provide to the client the possibility to require/negotiate the 
use of encryption;
and from the other side provide to the client the possibility to 
discovery the interposition
and then eventually interact with that proxy in between.

Having said that I agree with Eliot that solving everything just saying 
lets use TLS
is a theater, instead we should work on a way to authenticate endpoints, 
proxies,
how to provide data integrity etc.

/Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Roberto Peon <[email-masked]>
Date: Sun, 25 Aug 2013 00:14:36 -0700

Salvatore, that is also my recollection: To enable to client to require
encryption of the server for HTTP when it so desires and so introduce
symmetry in the negotiation between client/server w.r.t. encryption, but
there was no mention of requiring it for everything.

On Sun, Aug 25, 2013 at 12:10 AM, Salvatore Loreto <
[email-masked]> wrote:

> I don't think we were questioning the possibility to speak between client
> and server
> The hum, at least how I understood it, was only in favor to investigate a
> way to provide
> i.e. to provide to the client the possibility to require/negotiate the use
> of encryption;
> and from the other side provide to the client the possibility to discovery
> the interposition

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 25 Aug 2013 09:25:50 +0200

> and then eventually interact with that proxy in between.

OK, basically a user-chosen STARTTLS that the server can refuse, then
the user decides what to do. It could make sense if everyone in the
chain implements support for at least the clear mode. At least that's
my understanding.

Willy

---

From: Yoav Nir <[email-masked]>
Date: Sun, 25 Aug 2013 07:33:19 +0000

Hi Eliot.

Your message implies that the choice is between cleartext HTTP and an annual fee to a certificate vendor.

IETF standards provide at least two other options:

DANE allows you to use a self-issued certificate and register the key in the DNS. This is not implemented in the many thousands of small devices that you mention, or in any browser, but then neither is HTTP/2. There is a deployment issue in that publishing a random RR is a non-trivial process. For example, [1] makes no mention of how to generate TLSA records, and GoDaddy (largest registrar in the world) has nothing about it in their support. But all that could change.

TLS as anonymous ciphersuites that do not require a certificate at all. True, these ciphersuites do not protect against on-path attacks, but they do stop passive listeners, and there is some value in that. Not enough to call it "HTTPS", but it is better than nothing. And the application can still use some channel binding to discover the MitM, such as Trevor's Smart Cookie proposal where the cookie (which is a secret shared by client and server) is bound to the current master secret ([3]). Even without this, defeating passive listeners is a worthy goal.

Yoav

[1] http://www.thesitewizard.com/archive/registerdomain.shtml
[2] http://support.godaddy.com/search/all/TLSA/
[3] http://www.ietf.org/mail-archive/web/websec/current/msg01729.html

On Aug 25, 2013, at 9:16 AM, Eliot Lear <[email-masked]> wrote:

> Email secured by Check Point

---

From: Eliot Lear <[email-masked]>
Date: Sun, 25 Aug 2013 11:02:18 +0200

I'm answering a few messages at once, starting with Will's & Roberto's,
and then going on to Yoav's,

Will, you asked:
> Eliot, can you clarify what section of the minutes you're responding to?

Yes.  Starting with:
> SPDY introduced Madatory [sic] to Use Security; this was
> discussed for HTTP2.0; the working group declined, because of use cases like
> back end services.

Certainly home services can't be considered "backend" and most
enterprises uses could only be considered "backend" with the broadest
use of the term.  In short, there were *many *reasons why the group came
to the decision it came to.  And then moving on, Mark said:

> Mark says "mandatory to offer" is closer to what he said.

Which is in effect mandating of encryption.  After all, how can the
server offer it if it doesn't support it or if a proper certificate
isn't configured.  And the complexity issue arises as well.  The 2nd hum
as stated in the minutes was a vague question, as I wasn't in the room
at that precise moment, that's what I'm going by.

Yoav, you wrote:

> Your message implies that the choice is between cleartext HTTP and an annual fee to a certificate vendor.

Yes.  Maybe really large enterprises have their own CA or even PCA, but
the cost still has to be paid for that.
> DANE allows you to use a self-issued certificate and register the key in the DNS. This is not implemented in the many thousands of small devices that you mention, or in any browser, but then neither is HTTP/2. 

I agree with you, except for your last assertion - http2 *is* being
implemented in several browsers.  I think it would great if those who
hummed for this discussion exerted some effort to support DNSSEC and
then DANE.

> There is a deployment issue in that publishing a random RR is a non-trivial process. For example, [1] makes no mention of how to generate TLSA records, and GoDaddy (largest registrar in the world) has nothing about it in their support. But all that could change.

The principal issue with DANE is its dependency on DNSSEC.  As nearly
large an issue is the publication of different RRs.  *That* is a big
deal (see the IETF main list and the discussion of SPF), but probably
not appropriate here.

> TLS as anonymous ciphersuites that do not require a certificate at all. True, these ciphersuites do not protect against on-path attacks, but they do stop passive listeners, and there is some value…

Yes, but I would be concerned about the benefit being overstated.  I say
this because the reason the chair revisited the discussion is as follows:

> There is new information; there are widespread deployments of sniffers. More
> details have since been released. As Chair, Mark felt that this was enough to
> re-open the discussion.

Anonymous cypher suites might well have changed the character of this
problem, but probably not have reduced it, and may have introduced
unintended consequences.   They still may help with the so-called
"Starbucks" problem, but to me that problem is better dealt with at a
lower layer so that ALL communications on that network can be
protected.  I also believe that the underlying issues of the above
quoted statement lie elsewhere (about 3  to 4 layers above HTTP). 
Again, let's tease out the threat.

Eliot

---

From: Yoav Nir <[email-masked]>
Date: Sun, 25 Aug 2013 09:57:53 +0000

On Aug 25, 2013, at 12:02 PM, Eliot Lear <[email-masked]>
 wrote:
> Anonymous cypher suites might well have changed the character of this problem, but probably not have reduced it, and may have introduced unintended consequences.   They still may help with the so-called "Starbucks" problem, but to me that problem is better dealt with at a lower layer so that ALL communications on that network can be protected.  I also believe that the underlying issues of the above quoted statement lie elsewhere (about 3  to 4 layers above HTTP). 

(Opportunistic) IPsec?

---

From: "Markus Lanthaler" <[email-masked]>
Date: Sun, 25 Aug 2013 12:31:19 +0200

On Sunday, August 25, 2013 9:10 AM, Salvatore Loreto wrote:
> lets use TLS is a theater, instead we should work on a way to 
> authenticate endpoints, proxies, how to provide data integrity etc.

+1

--
Markus Lanthaler
@markuslanthaler

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sun, 25 Aug 2013 23:29:38 +0800

> Certainly home services can't be considered "backend" and most
enterprises uses could only be considered "backend" with the broadest use
of the term.  In short, there were many reasons why the group came to the
decision it came to.  And then moving on, Mark said:

OK I see. Sure, we can discuss previously decided matters on mandatory to
use security, but I'm not very interested. I'm at this moment more
interested in the discussion around mandatory to offer encryption. If
people are interested in clarifying the reasons they disagreed with
mandatory to use security, go ahead and I'll stay out of the way.

> Which is in effect mandating of encryption.  After all, how can the
server offer it if it doesn't support it or if a proper certificate isn't
configured.  And the complexity issue arises as well.  The 2nd hum as
stated in the minutes was a vague question, as I wasn't in the room at that
precise moment, that's what I'm going by.

If your point is mandatory to offer encryption => mandatory to use
encryption, then I am happy to discuss this.

There's a key distinction that may be getting lost here. Yes, the proposal
is that it is mandatory for the server to implement and offer encryption.
But it's not mandatory for a client to choose to use encrypted HTTP/2.

Another key distinction is encryption does not require authentication, so a
proper cert is not mandatory. I'm surprised you mention requiring a proper
cert given that you clearly understand a proper cert isn't necessary, given
your reply to Yoav below. I think it's worthwhile to discuss the asserted
benefit, but any statement about the current proposal requiring proper
certificates sounds factually incorrect as far as I can tell. Did I miss
something here?

>> DANE allows you to use a self-issued certificate and register the key in
the DNS. This is not implemented in the many thousands of small devices
that you mention, or in any browser, but then neither is HTTP/2.
>
>
> I agree with you, except for your last assertion - http2 is being
implemented in several browsers.  I think it would great if those who
hummed for this discussion exerted some effort to support DNSSEC and then
DANE.
>
>
>> There is a deployment issue in that publishing a random RR is a
non-trivial process. For example, [1] makes no mention of how to generate
TLSA records, and GoDaddy (largest registrar in the world) has nothing
about it in their support. But all that could change.
> The principal issue with DANE is its dependency on DNSSEC.  As nearly
large an issue is the publication of different RRs.  That is a big deal
(see the IETF main list and the discussion of SPF), but probably not
appropriate here.
>
>
>>
>>
>> TLS as anonymous ciphersuites that do not require a certificate at all.
True, these ciphersuites do not protect against on-path attacks, but they
do stop passive listeners, and there is some value in that. Not enough to
call it "HTTPS", but it is better than nothing. And the application can
still use some channel binding to discover the MitM, such as Trevor's Smart
Cookie proposal where the cookie (which is a secret shared by client and
server) is bound to the current master secret ([3]). Even without this,
defeating passive listeners is a worthy goal.
problem, but probably not have reduced it, and may have introduced
unintended consequences.   They still may help with the so-called
"Starbucks" problem, but to me that problem is better dealt with at a lower
layer so that ALL communications on that network can be protected.  I also
believe that the underlying issues of the above quoted statement lie
elsewhere (about 3  to 4 layers above HTTP).  Again, let's tease out the
threat.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 25 Aug 2013 20:46:39 +0200

Will,

On 8/25/13 5:29 PM, William Chan (陈智昌) wrote:
>
> Another key distinction is encryption does not require authentication,
> so a proper cert is not mandatory. I'm surprised you mention requiring
> a proper cert given that you clearly understand a proper cert isn't
> necessary, given your reply to Yoav below. I think it's worthwhile to
> discuss the asserted benefit, but any statement about the current
> proposal requiring proper certificates sounds factually incorrect as
> far as I can tell. Did I miss something here?
>

Possibly you did or possibly I did.  I have two specific issues with
anonymous encryption:

1.  The threat it is addressing may be better dealt with at other
layers; and
2.  It is often sold as more than it is.

As I wrote, I do like the idea of DANE + DNSSEC and then expanding on
that.  Got code for that?  If it's real privacy (not just encryption)
then I'd probably be convinced (there is a matter of responsibility, but
I think  DANE + DNSSEC could get us there, as can certs from credible CAs).

And just for the record:

> Yes, the proposal is that it is mandatory for the server to implement
> and offer encryption.

That is in fact my objection, particularly the "offer" part.  You seem
to be assuming (forgive me if you are not) that many implementations
small and large AND many deployments small and large will do a whole lot
of work for that offer where past experience shows that they won't, but
rather that it will in fact hinder implementation and deployment of the
rest of HTTP2.  There is an obvious question about the goals for HTTP2...

Eliot

---

From: Roberto Peon <[email-masked]>
Date: Sun, 25 Aug 2013 12:09:51 -0700

Remember that encryption != security.
Part of the reasons to use encryption have nothing to do with security, but
rather reliability-- encrypted bytestreams traverse the network without
modification far more successfully.

There should be no reason that the client shouldn't be able to request this
more reliable channel when the URL is HTTP.

As far as I understand, this is what we're talking about-- the client's
ability to request an encrypted channel for HTTP urls.

-=R

On Sun, Aug 25, 2013 at 11:46 AM, Eliot Lear <[email-masked]> wrote:

> Another key distinction is encryption does not require authentication, so
> a proper cert is not mandatory. I'm surprised you mention requiring a
> proper cert given that you clearly understand a proper cert isn't
> discuss the asserted benefit, but any statement about the current proposal
> requiring proper certificates sounds factually incorrect as far as I can
> tell. Did I miss something here?
>
>
> 1.  The threat it is addressing may be better dealt with at other layers;
> and
> that.  Got code for that?  If it's real privacy (not just encryption) then
> I'd probably be convinced (there is a matter of responsibility, but I
> think  DANE + DNSSEC could get us there, as can certs from credible CAs).
>
> And just for the record:
>
>
> Yes, the proposal is that it is mandatory for the server to implement and
> offer encryption.
>
>
> That is in fact my objection, particularly the "offer" part.  You seem to
> be assuming (forgive me if you are not) that many implementations small and
> large AND many deployments small and large will do a whole lot of work for
> that offer where past experience shows that they won't, but rather that it
> will in fact hinder implementation and deployment of the rest of HTTP2.
> There is an obvious question about the goals for HTTP2...
>
> Eliot
>

---

From: Mike Belshe <[email-masked]>
Date: Sun, 25 Aug 2013 13:05:06 -0700

> There is an obvious question about the goals for HTTP2...

I want to challenge your 'past experience' argument since you've said it 2
or 3 times now...

IPv6 suffered from slow deployment for reasons unrelated to security.   a)
It offered little value.  b) The main value it did offer was more easily
implemented through NAT c) it required OS-level upgrades to install.

HTTP/2 has none of these problems, while also having real monetary benefit.
 This is exactly the reason why SPDY has become the fastest deployed
protocol on the internet ever - from zero to a billion+ users in about a
year.  With HTTP/2 have the headroom to make TLS a requirement without
breaking deployment.

Finally, implementations don't have to do "a whole lot of work".
 Implementing and deploying TLS is trivial these days.

Mike

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 25 Aug 2013 22:07:57 +0200

so now I have a question
if one of the reasons to use encryption is to let the bytestreams 
traverse the networks without modifications
why don't just sign them instead that encrypt them?

/Sal

On 8/25/13 9:09 PM, Roberto Peon wrote:
> Part of the reasons to use encryption have nothing to do with 
> security, but rather reliability-- encrypted bytestreams traverse the 
> network without modification far more successfully.
>
> There should be no reason that the client shouldn't be able to request 
> this more reliable channel when the URL is HTTP.
>
> As far as I understand, this is what we're talking about-- the 
> client's ability to request an encrypted channel for HTTP urls.
>
> -=R
>
>
>
> On Sun, Aug 25, 2013 at 11:46 AM, Eliot Lear <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Will,
>
>
>>     Another key distinction is encryption does not require
>>     authentication, so a proper cert is not mandatory. I'm surprised
>>     you mention requiring a proper cert given that you clearly
>>     understand a proper cert isn't necessary, given your reply to
>>     Yoav below. I think it's worthwhile to discuss the asserted
>>     benefit, but any statement about the current proposal requiring
>>     proper certificates sounds factually incorrect as far as I can
>     Possibly you did or possibly I did.  I have two specific issues
>     with anonymous encryption:
>
>     As I wrote, I do like the idea of DANE + DNSSEC and then expanding
>     on that.  Got code for that?  If it's real privacy (not just
>     encryption) then I'd probably be convinced (there is a matter of
>     responsibility, but I think  DANE + DNSSEC could get us there, as
>     can certs from credible CAs).
>
>     And just for the record:
>
>
>>     Yes, the proposal is that it is mandatory for the server to
>>     implement and offer encryption.
>
>     That is in fact my objection, particularly the "offer" part.  You
>     seem to be assuming (forgive me if you are not) that many
>     implementations small and large AND many deployments small and
>     large will do a whole lot of work for that offer where past
>     experience shows that they won't, but rather that it will in fact
>     hinder implementation and deployment of the rest of HTTP2.  There
>     is an obvious question about the goals for HTTP2...
>
>     Eliot
>
>

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 25 Aug 2013 22:18:54 +0200

On 8/25/13 10:05 PM, Mike Belshe wrote:
> I want to challenge your 'past experience' argument since you've said 
> it 2 or 3 times now...
>
> IPv6 suffered from slow deployment for reasons unrelated to security. 
>   a) It offered little value.  b) The main value it did offer was more 
> easily implemented through NAT c) it required OS-level upgrades to 
> install.
>
> HTTP/2 has none of these problems, while also having real monetary 
> benefit.  This is exactly the reason why SPDY has become the fastest 
> deployed protocol on the internet ever - from zero to a billion+ users 
> in about a year.
well it would be better to provide the figure of the percent of SPDY 
traffic rather then the number of users that have it available in the 
browser.
Do you have it?

> With HTTP/2 have the headroom to make TLS a requirement without 
> breaking deployment.

yes TLS has helped to make the deployment fast no matter, and that what 
you have to do when you are working on something new;
but when it comes to standardize something would be much better at least 
try to integrate it more smoothly and seamlessly
with the rest of the Internet architecture

>  Implementing and deploying TLS is trivial these days.
that is true, but this is not the point

/Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Roberto Peon <[email-masked]>
Date: Sun, 25 Aug 2013 13:18:45 -0700

We've seen that the network delays bytes on some ports because (we assume)
of inspecting proxies, even when the data is incomprehensible to the proxy.
If the bytes are merely signed then the bytes are visible and modification
is still performed-- the modification becomes time-domain, e.g.
dropping/delaying packets, etc.

In any case, if you're doing the work of signing, why not just encrypt?

-=R

On Sun, Aug 25, 2013 at 1:07 PM, Salvatore Loreto <
[email-masked]> wrote:

>  so now I have a question
> if one of the reasons to use encryption is to let the bytestreams traverse
> the networks without modifications
> Part of the reasons to use encryption have nothing to do with security,
> but rather reliability-- encrypted bytestreams traverse the network without
>> to be assuming (forgive me if you are not) that many implementations small
>> and large AND many deployments small and large will do a whole lot of work
>> for that offer where past experience shows that they won't, but rather that
>> it will in fact hinder implementation and deployment of the rest of HTTP2.
> Salvatore Loreto, PhDwww.sloreto.com
>
>

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 25 Aug 2013 22:27:58 +0200

On 8/25/13 10:18 PM, Roberto Peon wrote:
> We've seen that the network delays bytes on some ports because (we 
> assume) of inspecting proxies, even when the data is incomprehensible 
> to the proxy.
maybe I am naif but the delay can be just because the proxies (lets just 
talk of HTTP here) expect HTTP traffic and they get confuse when they 
see something else

> If the bytes are merely signed then the bytes are visible and 
> modification is still performed-- the modification becomes 
> time-domain, e.g. dropping/delaying packets, etc.

If we let always possible to discover the presence of a proxy by the 
client... and the client realize that dropping/delaying packets is much 
higher
when there is that proxy in between ... it is just a matter of the time 
and the market will decide

> In any case, if you're doing the work of signing, why not just encrypt?
because you can still use all the positive aspects of the proxy/cache

/Salvatore

>
> -=R
>
>
> On Sun, Aug 25, 2013 at 1:07 PM, Salvatore Loreto 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     so now I have a question
>>     security, but rather reliability-- encrypted bytestreams traverse
>>     the network without modification far more successfully.
>>
>>     There should be no reason that the client shouldn't be able to
>>     request this more reliable channel when the URL is HTTP.
>>
>>>         authentication, so a proper cert is not mandatory. I'm
>>>         surprised you mention requiring a proper cert given that you
>>>         clearly understand a proper cert isn't necessary, given your
>>>         reply to Yoav below. I think it's worthwhile to discuss the
>>>         asserted benefit, but any statement about the current
>>>         proposal requiring proper certificates sounds factually
>>>         incorrect as far as I can tell. Did I miss something here?
>>>
>>
>>         Possibly you did or possibly I did.  I have two specific
>>         issues with anonymous encryption:
>>
>>         1.  The threat it is addressing may be better dealt with at
>>         other layers; and
>>         As I wrote, I do like the idea of DANE + DNSSEC and then
>>         expanding on that.  Got code for that?  If it's real privacy
>>         (not just encryption) then I'd probably be convinced (there
>>         is a matter of responsibility, but I think  DANE + DNSSEC
>>         could get us there, as can certs from credible CAs).
>>
>>         And just for the record:
>>
>>
>>         That is in fact my objection, particularly the "offer" part. 
>>         You seem to be assuming (forgive me if you are not) that many
>>         implementations small and large AND many deployments small
>>         and large will do a whole lot of work for that offer where
>>         past experience shows that they won't, but rather that it
>>         will in fact hinder implementation and deployment of the rest
>>         of HTTP2.  There is an obvious question about the goals for
>>         HTTP2...
>>
>>         Eliot
>>
>>
>
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 25 Aug 2013 20:40:05 +0000

>HTTP/2 has none of these problems, [...]

Or maybe you just don't want to see them ?

---

From: Roberto Peon <[email-masked]>
Date: Sun, 25 Aug 2013 13:43:47 -0700

On Sun, Aug 25, 2013 at 1:27 PM, Salvatore Loreto <
[email-masked]> wrote:

> assume) of inspecting proxies, even when the data is incomprehensible to
> the proxy.
>
> talk of HTTP here) expect HTTP traffic and they get confuse when they see
> something else
>

Oh it was worse that that :) Put correct HTTP over port 80 and it often
won't end up at the other side because you used a portion of the spec that
is not often used.

> modification is still performed-- the modification becomes time-domain,
> e.g. dropping/delaying packets, etc.
>
>

The market is efficient only when there are numerous choices and the
barrier to entry is low. That isn't true for things like this. The
endpoints currently have no choice about whether or not some portion of the
network is deploying what hardware/software, and often there is only once
choice of vendor. The only real choices clients/servers have is what the
bytes look like when they're sent.

> because you can still use all the positive aspects of the proxy/cache

You wouldn't be able to do that with a signed stream either without
allowing for proxies to do arbitrary transformations, at which point we're
back to where we are today in terms of reliability. These things are 100%
competitive with each other-- you can't both require signed data and
require not signed data!

I'd rather see explicitly configured proxies for this kind of thing-- then
the consumers are making the choice and can decide to not use it if it
doesn't provide a benefit (if the providers block encrypted traffic then
then only offer insecure traffic, which would not be tolerated in most
non-completely-backwards jurisdictions and entities).

-=R

>>> so a proper cert is not mandatory. I'm surprised you mention requiring a

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 25 Aug 2013 20:52:46 +0000

>In any case, if you're doing the work of signing, why not just encrypt?

Because signing wouldn't force Police-states intelligence services
to break, weaken or circumvent any and all encryption, in order to
comply with the mandate they were put under, by democratically
elected politicians ?

If you make encryption mandatory in HTTP/2.0, more of your tax-money
will drain into NSA[1] ?

Poul-Henning

[1] The Guardian pegs the number at around 850.000 NSA employees
and contractors:
	http://www.theguardian.com/uk/2013/jun/21/gchq-cables-secret-world-communications-nsa

---

From: Roberto Peon <[email-masked]>
Date: Sun, 25 Aug 2013 14:01:28 -0700

Such entities would have motivation to circumvent security regardless of
whether or not things are encrypted. That problem isn't technical-- it is
political.
In any case, the intent here is to negotiate for encryption, not security.
-=R

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 25 Aug 2013 21:05:03 +0000

>whether or not things are encrypted. That problem isn't technical-- it is

Correct, but if you make encrypt mandatory, they will have to break
_all_ encryption, that's what the law tells them to.

As long as encryption only affects a minority of traffic and they can
easier go around (ie: FaceBook, Google etc. delivering the goods)
they don't need to render _all_ encryption transparent.

>In any case, the intent here is to negotiate for encryption, not security.

As long as it's negotiation, and the server or client can decline that's
not a problem as such.

However, some people seem to want the server to not have a choice, that's
a no-go.

Poul-Henning

---

From: Roberto Peon <[email-masked]>
Date: Sun, 25 Aug 2013 14:09:33 -0700

On Sun, Aug 25, 2013 at 2:05 PM, Poul-Henning Kamp <[email-masked]>wrote:

> In message <
> [email-masked]>,
> Roberto Peon writes:
>
The server always gets to decline. The client doesn't even get to propose
it today :)
-=R

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 26 Aug 2013 09:59:23 +1000

To add some nuance - I believe I said that "mandatory to offer" would be the *effect* of the path proposed, *if* some clients choose not to negotiate for HTTP URLs over HTTP/2 without encryption.

I.e., we might not even make encryption mandatory to offer with a MUST. By giving the client more power to choose when encryption is used, we effectively create a market, avoiding the need to impose this kind of deus ex machina requirement. 

What's really being discussed is the creation of a profile of HTTP2-over-TLS for HTTP (not S) URIs, which can be negotiated for (just as the same thing without encryption can be negotiated for). 

We have a lot of things to discuss around what that profile looks like; e.g., whether cert validation should take place. Since the negotiation mechanism itself is vulnerable to a downgrade attack, and since HTTP URIs don't have a strong security semantic, it may be reasonable to assume that certs for HTTP URIs shouldn't be validated -- which would ease deployment considerably. Like I said, though, there will need to be a lot of discussion.

The high order bit here is that with an appropriate negotiation mechanism, we have a powerful way to re-mix the mapping of HTTP onto lower-layer substrates, whether that be TCP, SCTP, Minion, QUIC or TLS. That flexibility is a way to address the varying needs of the protocol's users without putting MUSTs into HTTP/2. If we get to a place where we have rough consensus that having such a requirement improves interop (e.g., a minimum 'profile set'), that's great, but I don't think we necessarily need the requirement to make it work.

Cheers,

On 25/08/2013, at 5:07 PM, William Chan (陈智昌) <[email-masked]> wrote:

> Just chiming in here since I'm concerned that a misinterpretation of the minutes may have led to an accidental straw man argument.
> 
> Eliot, can you clarify what section of the minutes you're responding to? I see only one hum for HTTP/2:
> """
> I don't see anything on humming on mandatory encryption. I note that there's a section of the minutes where Larry and Mark are clarifying the topic, since Larry said the topic was introduced as mandatory to implement security, whereas Mark clarified:
> """
> So, I don't believe "mandatory encryption" was even discussed at the last IETF, merely mandatory to offer [i forget if it was security or encryption, but I suspect encryption]. And let's be precise about the language, since security != encryption. You mentioned encryption, and then talked about certificate warnings. Let's remember you can try to encrypt without authenticating the peer.
> 
> Now, we can have a debate about whether or not mandatory encryption is security theater, but I think no one is beating that drum right now (although I won't preclude the possibility of someone stepping up to do so). So it's probably best to stick to the topic that we discussed at the last IETF, namely mandatory to offer [encryption?], unless someone would like to discuss mandatory encryption right now.
> 
> Cheers.
> 
>

---

From: Michael Sweet <[email-masked]>
Date: Sun, 25 Aug 2013 23:52:38 -0400

This was already done: RFC 2817

(and FWIW this is fairly widely implemented for printing - CUPS has supported it for a very long time and many printers support it today)

> chain implements support for at least the clear mode. At least that's

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Michael Sweet <[email-masked]>
Date: Sun, 25 Aug 2013 23:58:46 -0400

Mike,

I might point out that HTTP/1.1 is used over non-IP transports such as USB.  And I for one am hoping we can update IPP USB to use HTTP/2.0 to address the limited number of USB interfaces (endpoints) that are available in typical SoC implementations used in printers.

TLS in that class of device is a non-starter (and quite frankly is not needed).

On 2013-08-25, at 4:05 PM, Mike Belshe <[email-masked]> wrote:

>> Another key distinction is encryption does not require authentication, so a proper cert is not mandatory. I'm surprised you mention requiring a proper cert given that you clearly understand a proper cert isn't necessary, given your reply to Yoav below. I think it's worthwhile to discuss the asserted benefit, but any statement about the current proposal requiring proper certificates sounds factually incorrect as far as I can tell. Did I miss something here?
>> 
> 
> Possibly you did or possibly I did.  I have two specific issues with anonymous encryption:
> 
> 1.  The threat it is addressing may be better dealt with at other layers; and
> As I wrote, I do like the idea of DANE + DNSSEC and then expanding on that.  Got code for that?  If it's real privacy (not just encryption) then I'd probably be convinced (there is a matter of responsibility, but I think  DANE + DNSSEC could get us there, as can certs from credible CAs).
> 
> And just for the record:
> 
> 
>> Yes, the proposal is that it is mandatory for the server to implement and offer encryption.
> 
> That is in fact my objection, particularly the "offer" part.  You seem to be assuming (forgive me if you are not) that many implementations small and large AND many deployments small and large will do a whole lot of work for that offer where past experience shows that they won't, but rather that it will in fact hinder implementation and deployment of the rest of HTTP2.  There is an obvious question about the goals for HTTP2...
> 
> I want to challenge your 'past experience' argument since you've said it 2 or 3 times now... 
> 
> IPv6 suffered from slow deployment for reasons unrelated to security.   a) It offered little value.  b) The main value it did offer was more easily implemented through NAT c) it required OS-level upgrades to install.
> 
> HTTP/2 has none of these problems, while also having real monetary benefit.  This is exactly the reason why SPDY has become the fastest deployed protocol on the internet ever - from zero to a billion+ users in about a year.  With HTTP/2 have the headroom to make TLS a requirement without breaking deployment.
> 
> Finally, implementations don't have to do "a whole lot of work".  Implementing and deploying TLS is trivial these days.
> 
> Mike
> 
> 
>  
> 
> 
> Eliot
>

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 26 Aug 2013 07:11:01 +0200

> This was already done: RFC 2817

Indeed.

> (and FWIW this is fairly widely implemented for printing - CUPS has supported
> it for a very long time and many printers support it today)

I didn't know. Anyway, the whole idea is to allow the server to reject
the request and let the user know and decide. In my opinion it's more
of a browser design issue than a protocol one.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 26 Aug 2013 05:40:29 +0000

In message <[email-masked]>, Mark Nottingham writes:

>We have a lot of things to discuss around what that profile looks like; 
>e.g., whether cert validation should take place. 

Well,  wouldn't a good place to start be to agree what this encryption is
supposed to protect and from whom it protects it ?

Is it protecting against Samuel B. Hacker with his tcpdump(8) ?

Is it preventing Wile E. Telco from injecting ads ?

Is it keeping your bits safe from NSA and their almost-trillion dollar budget ?

Is it keeping your identity safe from NSA and their almost-trillion dollar budget ?

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 26 Aug 2013 07:59:03 +0200

On 8/25/13 10:43 PM, Roberto Peon wrote:
>
>
>
> On Sun, Aug 25, 2013 at 1:27 PM, Salvatore Loreto 
>>     We've seen that the network delays bytes on some ports because
>>     (we assume) of inspecting proxies, even when the data is
>>     incomprehensible to the proxy.
>     maybe I am naif but the delay can be just because the proxies
>     (lets just talk of HTTP here) expect HTTP traffic and they get
>     confuse when they see something else
>
>
> Oh it was worse that that :) Put correct HTTP over port 80 and it 
> often won't end up at the other side because you used a portion of the 
> spec that is not often used.
correct, there are around stacks that are incomplete or not very well 
tested and it is a problem, I concur
but that is for historical reasons and most likely the main reason of 
this situation is because some portion of the spec has not been used so 
often (if at all) till now!
if they start to be used, things will change even if slower compared to 
the browser update

>     If we let always possible to discover the presence of a proxy by
>     the client... and the client realize that dropping/delaying
>     packets is much higher
>     when there is that proxy in between ... it is just a matter of the
>     time and the market will decide
>
>
> endpoints currently have no choice about whether or not some portion 
> of the network is deploying what hardware/software, and often there is 
> only once choice of vendor. The only real choices clients/servers have 
> is what the bytes look like when they're sent.
there are different markets involved here,
from the client prospective you can choose different browsers or 
different ISP
the IPS has also the possibility to change the vendor that provide 
hardware/software (i.e. there several proxies implementations around)

> allowing for proxies to do arbitrary transformations, at which point 
> we're back to where we are today in terms of reliability. These things 
> are 100% competitive with each other-- you can't both require signed 
> data and require not signed data!
>
I am not saying it is easy, but it is something we can explore as an 
alternative

I do think we should save and bring in 2.0 all the positive aspects of 
the proxy/cache

> I'd rather see explicitly configured proxies for this kind of thing-- 
> then the consumers are making the choice and can decide to not use it 
> if it doesn't provide a benefit (if the providers block encrypted 
> traffic then then only offer insecure traffic, which would not be 
> tolerated in most non-completely-backwards jurisdictions and entities).

I also think we should start to work on how explicitly configure a 
proxy, trusted proxy, and how to make possible to discover a proxy etc. etc.

/Salvatore

---

From: Roberto Peon <[email-masked]>
Date: Sun, 25 Aug 2013 23:25:01 -0700

I'm all for people working out how to do explicit proxy configuration.
I am pro-proxy, so long as the customers want proxies and are able to
exercise choice about it.
I do believe, however, that we could do substantially better w.r.t. caching
than we do today-- I just don't have the bandwidth to deal with that and
this effort simultaneously. :)

In any case, I suspect that the entirety of the complexity here comes down
to a MAYs and two MUSTs, for instance:

An HTTP/2 client MAY send resources with an HTTP scheme down an encrypted
connection at any time.
An HTTP/2 server MAY choose not to process such a request, however if it
chooses to refuse such a request it MUST respond with (new) error code XXX
- scheme unsupported on connection, which indicates that the request was
not processed and is safe to retry on an unencrypted connection.

-=R

On Sun, Aug 25, 2013 at 10:59 PM, Salvatore Loreto <
[email-masked]> wrote:

> but that is for historical reasons and most likely the main reason of this
> situation is because some portion of the spec has not been used so often
> (if at all) till now!
> from the client prospective you can choose different browsers or different
> ISP
> I do think we should save and bring in 2.0 all the positive aspects of the
> proxy/cache
>
>
> then the consumers are making the choice and can decide to not use it if it
> I also think we should start to work on how explicitly configure a proxy,
> trusted proxy, and how to make possible to discover a proxy etc. etc.
>
>
> /Salvatore
>
>
>  -=R
>
>
>>
>>
>> /Salvatore
>>
>>
>>
>>
>>  -=R
>>
>>
>

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 26 Aug 2013 08:42:24 +0200

> not processed and is safe to retry on an unencrypted connection.

I'm generally fine with this principle. I'd rather have at least two codes,
one being "not supported for this resource" and the other one being "not
implemented on this host".

With the principle above, we could accelerate https adoption (more transparent
since there's no URL changes), let users decide if they prefer fast connections
or default encryption, and still have CDNs and porn sites continue to work fast
since we must not forget they're the ones that fill the internet pipes all over
the world.

Willy

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 26 Aug 2013 10:44:13 +0200

+1

It's horrifying to see how most HTTP/1 clients will mess around with
partial implementations to establish com, because who cares if secrets are
leaked right and left, if the TLS stack is not complaining overmuch it
must be secure. Bonus points if they manage to degrade setups that would
require their developers to handle more valid error conditions.

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 26 Aug 2013 10:48:27 +0200

Le Dim 25 août 2013 09:33, Yoav Nir a écrit :

> the DNS.

DANE is still relying on a centralized system endpoints must kowtow to.
For most appliances that means it just won't happen (sorry). What they
want is some sort of decentralized discovery system like gpg or ssh.

A lot of countries still have no mandatory id cards but that's what DANE
is for devices.

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 26 Aug 2013 11:02:34 +0200

> In any case, if you're doing the work of signing, why not just encrypt?

Because when the stream is not security-sensitive, it's the difference
between intermediaries wasting resources trying to determine if the
download if safe vie indirect means or passing it up directly

-- 
Nicolas Mailhot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Aug 2013 12:02:27 +0200

> We have a lot of things to discuss around what that profile looks like; e.g., whether cert validation should take place. Since the negotiation mechanism itself is vulnerable to a downgrade attack,…

And we discussed this in Paris and rejected it for all the reasons we
are now revisiting.  And in Paris what we discussed was the fact that
this will not solve Mike and Roberto's new feature deployment problem on
port 80, precisely because of the downgrade attack issue.  The other
issue left is the Starbucks snooping problem, and I still claim that is
better addressed at other layers.  Finally there is the snooping that
goes on in the middle of the network, which you raised at the meeting. 
I don't think this will solve that problem either, but it may cause
middlebox vendors to sell some additional features to their service
providers, based on government mandates.

I would suggest that a better focus is still honest-to-goodness easing
of end-to-end authentication issues.  This is where the hard work needs
to happen, and it will also facilitate dealing with the fundamental
issues you've raised concerns about.  This, to me, is the high order bit.

Eliot

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 26 Aug 2013 20:53:18 +1000

Eliot,

On 26/08/2013, at 8:02 PM, Eliot Lear <[email-masked]> wrote:

> port 80, precisely because of the downgrade attack issue.

I'm not saying it wasn't discussed, but it isn't in the minutes, and I don't have a recollection of that conversation. YMMV (my memory is terrible).

>  The other

Here's the thing. We argue by assertion a *lot* at the IETF. People come up with very convincing reasoning for why things should be one way or another, and sometimes we make decisions based upon that, because it's all we've got to go on.

OTOH I see a number of browser implementers who want to do something very real here. We haven't yet determined the shape of it yet, and already we have people saying "that won't work!" or "it's theatre!"

It may certainly be that you're right; maybe we won't be able to effect meaningful change within the many constraints we face*.  However, given that we have real implementer interest and willingness to experiment, I think it deserves at least some serious attention -- at least as much as the many hobby horse projects that get spawned without any sign of implementer interest at all. 

Given the risk of this becoming the mother of all ratholes, I'm inclined to think that it might be best to fork this discussion off to a design team, which can talk about it separately and come back to the WG with something more fully baked. Would that work for people, and if so, who would be interested in dedicating substantial time to it?

> issues you've raised concerns about.  This, to me, is the high order bit.

If I had confidence that we (the IETF) could get it implemented and deployed, I'd be very much on board. Attending years of countless Bar BoFs, BoFs, WG meetings and other get-togethers hasn't led me to believe that's the case yet. Again, YMMV.

Cheers,

* Personally (and perhaps to Poul-Henning's questions), while I'm very interested in solving specific and immediate problems like the ones you mention, I'm even more interested in rectifying the imbalance between clients and servers regarding how encryption is used; I think that if we do that, it'll be good for the whole Web ecosystem in the (much) longer term.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 26 Aug 2013 21:24:20 +0800

I went to
http://tools.ietf.org/wg/httpbis/minutes?item=minutes-83-httpbis.html to
look up the Paris minutes and didn't find anything about this. Can you
state for my benefit what was rejected in Paris as I don't recall?

I'm confused about the relation between new feature deployment and
downgrade attacks. Downgrade suggests an active attacker, right? The
protocol deployment issue isn't about attacks, but rather intermediaries
choking on things they don't expect.

On Mon, Aug 26, 2013 at 6:02 PM, Eliot Lear <[email-masked]> wrote:

> e.g., whether cert validation should take place. Since the negotiation
> mechanism itself is vulnerable to a downgrade attack, and since HTTP URIs
> don't have a strong security semantic, it may be reasonable to assume that
> certs for HTTP URIs shouldn't be validated -- which would ease deployment
> considerably. Like I said, though, there will need to be a lot of
> discussion.
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 26 Aug 2013 22:33:24 +0800

> 2.  It is often sold as more than it is.

Great, I think we've made progress here on narrowing in on the meat of the
discussion. I've got nothing new here other than what others have already
said, but I'll re-emphasize a particularly point. We're primarily talking
about http:// URIs here. Given that constraint, it's unclear if we want to
require server authentication. I think most people are starting with just
encryption. So while the authentication discussion is interesting, I'd
ignore authentication for now.

I think it's definitely debatable how much benefit anonymous encryption
provides. I'm interested in having that debate. I just want to make sure
we're clear on what we're discussing (encryption, not authentication) for
http:// URIs.

> There is an obvious question about the goals for HTTP2...

Just to be clear, I've actually not said much if anything yet on this
thread in support of mandatory to offer encryption. I've mostly tried to
clarify the discussion, since I felt that there were inaccurate/confusing
statements made earlier in the thread.

---

From: Leif Hedstrom <[email-masked]>
Date: Mon, 26 Aug 2013 09:22:03 -0600

On Aug 26, 2013, at 12:25 AM, Roberto Peon <[email-masked]> wrote:

> I am pro-proxy, so long as the customers want proxies and are able to exercise choice about it.
> I do believe, however, that we could do substantially better w.r.t. caching than we do today-- I just don't have the bandwidth to deal with that and this effort simultaneously. :)
> 
> In any case, I suspect that the entirety of the complexity here comes down to a MAYs and two MUSTs, for instance:

As a proxy / cache guy myself, I can't help feeling we're mostly ignoring this important issue. In the reverse proxy case, it's mostly a wash whether it's SSL or not (although, haproxy/SLB people might disagree).  However, in forward and intercepting proxy, HTTPS is a real issue. For example, youtube streams are generally cacheable on forward/intercepting proxies over HTTP today, but I'd imagine over SPDY and HTTP/2 they are not?

I'm not sure what exactly we should do here, and I don't expect Roberto to drive this (unless he wants to of course). I do however feel that we ought to look into this as part of the HTTP/2 specifications as important use cases.

Cheers,

-- Leif

---

From: Patrick McManus <[email-masked]>
Date: Mon, 26 Aug 2013 12:10:56 -0400

> about http:// URIs here. Given that constraint, it's unclear if we want
> to require server authentication. I think most people are starting with
> just encryption. So while the authentication discussion is interesting, I'd
let's not ignore authentication. The PKI situation can be improved and
there is no reason that http:// can't carry at least the levels of
guarantees that https:// provides, modulo fear of down grade attack back to
the lameness that is http/1. (so we're talking about transport level
enhancements - not web level security changes re mixed content, etc..)

that being said - I'm with the family on vacation this week. So please
don't take my silence for lack of interest.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 26 Aug 2013 12:12:17 -0400

i can work on the proposed design team.

On Mon, Aug 26, 2013 at 6:53 AM, Mark Nottingham <[email-masked]> wrote:

> I'm not saying it wasn't discussed, but it isn't in the minutes, and I
> don't have a recollection of that conversation. YMMV (my memory is
> terrible).
>
> >  The other
> Here's the thing. We argue by assertion a *lot* at the IETF. People come
> up with very convincing reasoning for why things should be one way or
> another, and sometimes we make decisions based upon that, because it's all
> we've got to go on.
>
> OTOH I see a number of browser implementers who want to do something very
> real here. We haven't yet determined the shape of it yet, and already we
> have people saying "that won't work!" or "it's theatre!"
>
> It may certainly be that you're right; maybe we won't be able to effect
> meaningful change within the many constraints we face*.  However, given
> that we have real implementer interest and willingness to experiment, I
> think it deserves at least some serious attention -- at least as much as
> the many hobby horse projects that get spawned without any sign of
> implementer interest at all.
>
> Given the risk of this becoming the mother of all ratholes, I'm inclined
> to think that it might be best to fork this discussion off to a design
> team, which can talk about it separately and come back to the WG with
> something more fully baked. Would that work for people, and if so, who
> would be interested in dedicating substantial time to it?
>
> If I had confidence that we (the IETF) could get it implemented and
> deployed, I'd be very much on board. Attending years of countless Bar BoFs,
> BoFs, WG meetings and other get-togethers hasn't led me to believe that's
> the case yet. Again, YMMV.
>
> Cheers,
>
>
> * Personally (and perhaps to Poul-Henning's questions), while I'm very
> interested in solving specific and immediate problems like the ones you
> mention, I'm even more interested in rectifying the imbalance between
> clients and servers regarding how encryption is used; I think that if we do
> that, it'll be good for the whole Web ecosystem in the (much) longer term.
>
>
> --

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 26 Aug 2013 11:47:11 -0700

There seems to be a disconnect here. The authority for https has no actual connection to the authority for http. Allowing one port to answer for another is a security hole. TLS does not make it more secure. Neither does DNS, nor any other means of hinting ports. If you trust a port other than the one defined by the URI, then you allow a site's trivial  poisoning protections to be bypassed.

....Roy

On Aug 25, 2013, at 11:25 PM, Roberto Peon <[email-masked]> wrote:

> An HTTP/2 client MAY send resources with an HTTP scheme down an encrypted connection at any time.
> An HTTP/2 server MAY choose not to process such a request, however if it chooses to refuse such a request it MUST respond with (new) error code XXX - scheme unsupported on connection, which indicates that the request was not processed and is safe to retry on an unencrypted connection.
> 
> -=R
> 
> 
> On Sun, Aug 25, 2013 at 10:59 PM, Salvatore Loreto <[email-masked]> wrote:
>>> On Sun, Aug 25, 2013 at 1:27 PM,             Salvatore Loreto <[email-masked]> wrote:
>>>>> We've seen that the network delays bytes on some ports because (we assume) of inspecting proxies, even when the data is incomprehensible to the proxy.
>>>> maybe I am naif but the delay can be just because the proxies (lets just talk of HTTP here) expect HTTP traffic and they get confuse when they see something else
>>> 
>>> Oh it was worse that that :) Put correct HTTP over port 80 and it often won't end up at the other side because you used a portion of the spec that is not often used.
>> correct, there are around stacks that are incomplete or not very well tested and it is a problem, I concur
>> but that is for historical reasons and most likely the main reason of this situation is because some portion of the spec has not been used so often (if at all) till now!
>> if they start to be used, things will change even if slower compared to the browser update
>> 
>> 
>>>  
>>>> 
>>>> 
>>>>> If the bytes are merely signed then the bytes are visible and modification is still performed-- the modification becomes time-domain, e.g. dropping/delaying packets, etc.
>>>> 
>>>> If we let always possible to discover the presence of a proxy by the client... and the client realize that dropping/delaying packets is much higher 
>>>> when there is that proxy in between ... it is just a matter of the time and the market will decide
>>> 
>>> The market is efficient only when there are numerous choices and the barrier to entry is low. That isn't true for things like this. The endpoints currently have no choice about whether or not some portion of the network is deploying what hardware/software, and often there is only once choice of vendor. The only real choices clients/servers have is what the bytes look like when they're sent.
>> from the client prospective you can choose different browsers or different ISP
>> the IPS has also the possibility to change the vendor that provide hardware/software (i.e. there several proxies implementations around)
>> 
>> 
>> 
>>>  
>>>>> 
>>> You wouldn't be able to do that with a signed stream either without allowing for proxies to do arbitrary               transformations, at which point we're back to where we are today in terms of reliability. These things are 100% competitive with each other-- you can't both require signed data and require not signed data!
>> I am not saying it is easy, but it is something we can explore as an alternative
>> 
>> I do think we should save and bring in 2.0 all the positive aspects of the proxy/cache
>> 
>> 
>>> I'd rather see explicitly configured proxies for this kind of thing-- then the consumers are making the choice and can decide to not use it if it doesn't provide a benefit (if the providers block encrypted traffic then then only offer insecure traffic, which would not be tolerated in most non-completely-backwards jurisdictions and entities).
>> 
>> I also think we should start to work on how explicitly configure a proxy, trusted proxy, and how to make possible to discover a proxy etc. etc.
>> 
>> 
>> /Salvatore
>>> 
>>> -=R
>>>  
>>>> 
>>>> 
>>>> /Salvatore
>>>> 
>>>>  
>>>>> 
>>>>> -=R
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 Aug 2013 08:14:06 +0200

Hi Will,

On 8/26/13 4:33 PM, William Chan (陈智昌) wrote:

> Great, I think we've made progress here on narrowing in on the meat of
> the discussion. I've got nothing new here other than what others have
> already said, but I'll re-emphasize a particularly point. We're
> primarily talking about http:// URIs here. Given that constraint, it's
> unclear if we want to require server authentication. I think most
> people are starting with just encryption. So while the authentication
> discussion is interesting, I'd ignore authentication for now.

I know I'm not winning an congeniality awards here for disagreeing so
much, but I wouldn't entirely ignore authentication.  As you browser
folk know, you may have retained a lot of information about the server. 
Some of that information might involve the identity of the server, which
is really what is at issue here.  Making use of that would be good, but
I don't know if it can be done properly on port 80 in a standard, unless
of course you happen to have a published DNS record with capabilities. 
It opens up a whole can of worms about whether example.com:80 and
example.com:someotherportrunningSSL are equivalent.

It's also not the most elegant idea I've ever had, I must say.

Eliot

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 27 Aug 2013 17:20:46 +0800

I guess my point is that you've repeatedly made criticisms based on the
authentication requirement (for example, your criticisms based on
certificate configuration). I agree authentication would be nice to have,
but I think it's unfair to criticize mandatory to offer *encryption*
because of authentication. This is why I complain about it being a straw
man argument.

To be clear, I'm still personally leaning towards only supporting HTTP/2
over a secure transport in chromium (and if we can get that for
http://URIs too, great!). I just don't want to see mnot's proposal get
unfairly
treated. I'd like to see where the discussion leads us. If it gains any
traction, then I need to check back with some more chromium networking
folks (like rch/akalin who may be lurking on this thread) to see how much
interest we have in unauthenticated, but encrypted HTTP/2. I myself hope we
only use secure transports.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 27 Aug 2013 09:27:11 +0000

In message <CAA4WUYjOzPQUxy97WuQSFS0XMw3meXt87eRXZi=[email-masked]>, =?UTF-8?B?V2lsbGlhbSBDaGFuIC
jpmYjmmbrmmIwp?= writes:

>I agree authentication would be nice to have,
>because of authentication.

When you say "encryption", do you mean "privacy" ?

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 27 Aug 2013 17:38:03 +0800

On Tue, Aug 27, 2013 at 5:27 PM, Poul-Henning Kamp <[email-masked]>wrote:

> In message <CAA4WUYjOzPQUxy97WuQSFS0XMw3meXt87eRXZi=
> [email-masked]>, =?UTF-8?B?V2lsbGlhbSBDaGFuIC
> jpmYjmmbrmmIwp?= writes:
>

I mean encryption, because that's AIUI what mnot hinted at in his Berlin
presentation.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 27 Aug 2013 10:37:48 +0000

In message <CAA4WUYgn5jgTojch=Z7Kv=[email-masked]>, =?UTF-8?B?V2lsbGlhbSBDaGFuIC

>I mean encryption, because that's AIUI what mnot hinted at in his Berlin

That answer doesn't really help me any...

In the email I cited, you used "encryption" as something apart from
"authentication" and that left (at least) me confused about what
the heck you were talking about ?

Referencing mnot's slides doesn't really help me there...

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 27 Aug 2013 19:25:51 +0800

On Aug 27, 2013 6:37 PM, "Poul-Henning Kamp" <[email-masked]> wrote:
>
> In message <CAA4WUYgn5jgTojch=Z7Kv=
[email-masked]>, =?UTF-8?B?V2lsbGlhbSBDaGFuIC
> the heck you were talking about ?

Sorry, let me clarify with an example: a TLS connection to a server
presenting a self-signed cert. It's encrypted, but the server is not
authenticated. Does that clarify matters?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 27 Aug 2013 11:32:15 +0000

In message <[email-masked]>, =?UTF-8?B?V2lsbGlhbSBDaGFuIC

>authenticated. Does that clarify matters?

Yes, thanks.

I tend to prefer the words "privacy" and "secrecy" myself, exactly
because "encryption" is such a catch-all concept that you never quite
know what people actually mean.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Aug 2013 09:59:05 -0700

> know what people actually mean.

I'm not sure that you get either of those properties.  Not without a
lot of other things being just right at the same time.  That's why I
think it would be wise to avoid those particular words.

And even talking about confidentiality and integrity is misleading.
They might be better choices, even if you don't know specifically who
the confidentiality property extends to.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Aug 2013 17:22:43 +0000

So just chiming in generally on this thread with no hats:

- I don't agree with the subject line - if done properly,
turning on encryption without authentication could be useful
and not simply theater - for example it could increase the
cost and/or complexity (and hence likelihood of discovery)
of deploying pervasive surveillance.

- Done badly of course, the outcome could be theater.

- I disagree that making better use of crypto might cause
authorities to be more authoritarian - while that might be
a reasonable position to hold for folks with a certain world
view, its entirely unconvincing. I suspect that folks with
that position cannot be convinced they are wrong and nor
can folks who don't have that position.

- I don't think this discussion should really have much to
do with earlier discussions about performance or middleboxes.
The WG had that discussion and this one is based on "new
information" as I think Mark put it.

- Some people might oversell the results of this discussion,
yes, but that's always a danger and shouldn't drive the WG
decision.

All in all, I'd like to see more use of HTTP/TLS for
confidentiality, even without origin authentication. (But
that's probably no surprise:-)

Cheers,
S.

---

From: Mike Belshe <[email-masked]>
Date: Tue, 27 Aug 2013 12:42:16 -0700

+1.  Encryption is not theater.   It raises the bar in a meaningful way.
On Aug 27, 2013 10:23 AM, "Stephen Farrell" <[email-masked]>

---

From: Tim Bray <[email-masked]>
Date: Tue, 27 Aug 2013 13:28:06 -0700

Yeah... we’ve had this conversation before.  But there are a lot of us who
think that every time you turn one connection from naked to TLS, that is a
step forward and something that we should be encouraging and facilitating
to the degree that we can.  -T

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 27 Aug 2013 16:41:48 -0700

I completely agree.  Just look at Firesheep...

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 27 Aug 2013 16:43:39 -0700

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

On Tue, Aug 27, 2013 at 2:20 AM, William Chan (陈智昌)
<[email-masked]>wrote:

> over a secure transport in chromium (and if we can get that for http://URIs too, great!). I just don't want to see mnot's proposal get unfairly