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

From: Mark Nottingham <[email-masked]>
Date: Tue, 20 May 2014 13:42:50 +1000

FYI - Martin went away and did some substantial revision of this draft, and is now an author.

Regards,

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-nottingham-http2-encryption-03.txt
> Date: 20 May 2014 1:40:54 pm AEST
> To: "Mark Nottingham" <[email-masked]>, Martin Thomson <[email-masked]>, "Martin Thomson" <[email-masked]>, Mark Nottingham <[email-masked]>
> 
> 
> A new version of I-D, draft-nottingham-http2-encryption-03.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Name:		draft-nottingham-http2-encryption
> Revision:	03
> Title:		Opportunistic Encryption for HTTP URIs
> Document date:	2014-05-20
> Group:		Individual Submission
> Pages:		9
> URL:            http://www.ietf.org/internet-drafts/draft-nottingham-http2-encryption-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-nottingham-http2-encryption/
> Htmlized:       http://tools.ietf.org/html/draft-nottingham-http2-encryption-03
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-nottingham-http2-encryption-03
> 
> Abstract:
>   This describes how "http" URIs can be accessed using Transport Layer
>   Security (TLS) to mitigate pervasive monitoring attacks.
> 
> 
> 
> 
> 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: Martin Thomson <[email-masked]>
Date: Mon, 19 May 2014 20:59:40 -0700

> FYI - Martin went away and did some substantial revision of this draft, and is now an author.

The changes incorporate a draft you might have seen, but I didn't
announce.  The main innovation here is a way to make the whole thing
sticky in an effort to reduce the opportunity for downgrade attack.
Pretty standard stuff, but included as a bit of a thought experiment
as well as a bit of a test to see what people think.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 May 2014 09:31:03 +0100

Hiya,

>> FYI - Martin went away and did some substantial revision of this draft, and is now an author.

Good stuff.

> as well as a bit of a test to see what people think.

Would you be ok with s/opportunistic encryption/opportunistic
security/? The latter is the term that the saag discussion has
ended up landing on, (post bikeshed:-) so it'd be good if
that worked here too.

I wonder if the MUST and MUST NOT terms in 5.1 are ok. But
if they're there to find that out then that's fine:-)

And BTW - just in case folks here haven't seen it, some FB
folks have published stats [1] on what they've seen with
MTA-MTA STARTTLS and the interesting number for this is
that they are seeing 58% of outbound emails being encrypted
that way, with about half of those being what they call
"strict" and half being what they call opportunistic.
That seems to imply that we could perhaps double the
amount of HTTP traffic using TLS with the mechanism from
this draft, (compared to "https") and in short order. (I
don't know of historic figures for the FB stuff, but
previous guesstimates I've seen were of the order of 20%
or so and not 58%. I'd be very interested in similar
numbers/trends folks are willing to talk about for HTTP
as well.)

That seems like real evidence for a huge potential win
to me, even if the situations aren't quite the same. Fears
that opportunistic security for HTTP might be somehow
dodgy seem to me to pale into insignificance in the face
of such actual evidence.

S.

[1] https://www.facebook.com/notes/1453015901605223/

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 May 2014 05:40:47 -0700

> ended up landing on, (post bikeshed:-) so it'd be good if

Yeah, we're not looking to be revolutionary.

> if they're there to find that out then that's fine:-)

The entirety of Section 5 is there to air those sorts of questions.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 May 2014 08:26:49 -0700

The new material on what might be called "alternate service pinning" has
the advantages and faults of any of the security pinning protocols that the
IETF makes. Please note how tortured the key pinning discussion in the
websec WG has become; there is no reason why alternate service pinning will
be any easier. This isn't to say that you shouldn't do it, just that you
should expect it to be a protracted and sometimes circular discussion full
of "but what if; so the protocol now has to".

Separately, the text in Section 4 concerns me because it seems easy to
mis-implement. That is, the API flag that says "this connection is/isn't
running under authenticated TLS" becomes critical; it is even more
important than the API flag for "this connection is/isn't running under
TLS".  Please consider calling this out more strongly in Section 4, and add
it to the Security Considerations. Encouraging developers to have a unit
test for "start a connection with unauthenticated TLS and then then try to
request an https: resource and make sure that fails".

--Paul Hoffman

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 May 2014 09:54:22 -0700

On 20 May 2014 08:26, Paul Hoffman <[email-masked]> wrote:
> The new material on what might be called "alternate service pinning" has the
> advantages and faults of any of the security pinning protocols that the IETF
> makes. Please note how tortured the key pinning discussion in the websec WG
> has become; there is no reason why alternate service pinning will be any
> easier. This isn't to say that you shouldn't do it, just that you should
> expect it to be a protracted and sometimes circular discussion full of "but
> what if; so the protocol now has to".

The hope was to attract some of the expertise in the hopes that that
would help avoid all of the torture.

> running under authenticated TLS" becomes critical; it is even more important
> than the API flag for "this connection is/isn't running under TLS".  Please
> consider calling this out more strongly in Section 4, and add it to the
> Security Considerations. Encouraging developers to have a unit test for
> "start a connection with unauthenticated TLS and then then try to request an
> https: resource and make sure that fails".

The idea that TLS == security is one that has been very well
socialized.  The education programme has been very effective.  So yes,
I get your point.

Maybe there's a case for further highlighting the distinction we want
to retain, at least at the broadest level of generality: https ==
secure, http == not.  That is the point of Section 6.1, but I might be
convinced that repetition of this is necessary.

---

From: "Martin Nilsson" <[email-masked]>
Date: Wed, 21 May 2014 00:45:17 +0200

> ended up landing on, (post bikeshed:-) so it'd be good if

As a random (weak) opinion point I would be against that. It would not be  
in line with what I was taught at University; That you only have security  
when you have Confidentiality, Integrity and Availability (the CIA rule).

/Martin Nilsson

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

---

From: "Martin Nilsson" <[email-masked]>
Date: Wed, 21 May 2014 00:45:00 +0200

> convinced that repetition of this is necessary.

I assume that the set of ciphers you negotiate from would be the same here  
as for https. The performance difference isn't big, and you minimize your  
traffic analysis footprint by not having different TLS parameters for http  
and https URLs. Given this the only possible difference are the  
certificates, and they will be the same for http as https users of a  
specific site. So in practice there will be no difference between the  
actual connections for http and https in many cases. Should you still not  
show any security indicators in the UI?

/Martin Nilsson

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 May 2014 23:50:17 +0100

On 20/05/14 23:45, Martin Nilsson wrote:
> As a random (weak) opinion point I would be against that. It would not
> be in line with what I was taught at University; That you only have
> security when you have Confidentiality, Integrity and Availability (the
> CIA rule).

Personally, I think that "only" is plain wrong and the sentence
assumes that security is a binary state and also wrong. But yes,
I do fully accept that that is the kind of thing we were all
taught and that some of us ourselves taught.

And I've very much in favour of not re-opening the bikeshedding
at all.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 May 2014 23:51:42 +0100

On 20/05/14 23:45, Martin Nilsson wrote:
> I assume that the set of ciphers you negotiate from would be the same
> here as for https. The performance difference isn't big, and you
> minimize your traffic analysis footprint by not having different TLS
> parameters for http and https URLs. Given this the only possible
> difference are the certificates, and they will be the same for http as
> https users of a specific site. So in practice there will be no
> difference between the actual connections for http and https in many
> cases. Should you still not show any security indicators in the UI?

Yes. If opportunistic, then e.g. it'd be ok to defer cert validation
thus being partly MiTM'able in some cases for some (maybe short) period.
But a short period is just fine for some bad actors.

S.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 20 May 2014 15:55:42 -0700

On Tue, May 20, 2014 at 3:45 PM, Martin Nilsson <[email-masked]> wrote:

> On Tue, 20 May 2014 18:54:22 +0200, Martin Thomson <
> [email-masked]> wrote:
>
>

Transport security is very different from web security. For example, only
some of the resources in a webpage may be opportunistically encrypted with
strong authentication. If there's active content like script that's loaded
without transport security, that can compromise the entire page. Pages
loaded using opportunistic encryption definitely do not deserve the same
security indicator as an https:// page. One might argue that they deserve
something better than nothing, but explaining this difference to users is
quite difficult already, so it seems inadvisable to further muddy the
distinction by introducing a middle ground security indicator.

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 21 May 2014 04:37:03 +0000

thanks for working on this, I do believe it is really important

one clarification about it usages in http2 

If I understand correctly the draft 
a browser asking for http:// URI (no matter if using http/1.1 or http2) may get back an answer with an alt-svc: h2 
in that case the will start a TLS connection (with a an ALPN value of h2) towards the server exactly as per any http2;
the only difference will be that the browser will not check the certificate
so there won't be any difference on the wire only a different behaviour within the browser
isn't it?

br
/Salvatore

---

From: "Martin Nilsson" <[email-masked]>
Date: Wed, 21 May 2014 08:56:24 +0200

On Wed, 21 May 2014 00:55:42 +0200, William Chan (陈智昌)  
<[email-masked]> wrote:

>
> Transport security is very different from web security. For example,  
> only some of the resources in a webpage may be opportunistically  
> encrypted >with strong authentication. If there's active content like  
> script that's loaded without transport security, that can compromise the  
> entire page.

Yes, of course. I'm asking about the case where everything is equivalent  
with if the page were loaded as https. Certificates check out, all  
dependencies are secure, etc. Section 6.1 states that the page MUST NOT be  
indicated to be secure, even though there is no practical difference.

/Martin Nilsson

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 21 May 2014 01:01:26 -0700

But transport security != web security, there is plenty of practical
difference. Different schemes implies different web origins. The webpage is
*not* equivalent with if the page were loaded as https. Now you get
differences in same origin policies and CORS and referrer policies and blah
blah blah.

Not to mention it'd be a lame user experience to start out with a green
lock and then when an insecure resource is loaded (which we'd have to
allow, unless we want to block mixed content for opportunistically
encrypted webpages) to remove the security indicator. We should avoid
confusing the user with changing security indicators during a page load.

On Tue, May 20, 2014 at 11:56 PM, Martin Nilsson <[email-masked]> wrote:

>  On Wed, 21 May 2014 00:55:42 +0200, William Chan (陈智昌) <
> [email-masked]> wrote:
>
>
> without transport security, that can compromise the entire page.
>
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 May 2014 05:39:54 -0700

> so there won't be any difference on the wire only a different behaviour within the browser

No on-the-wire difference.  Assuming that the server uses an https
port that has a valid cert.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 May 2014 05:45:48 -0700

On 21 May 2014 01:01, William Chan (陈智昌) <[email-masked]> wrote:

The answer is no.  And this is important.

We're not changing the origin of the resource.  That's paramount for web
security.

We're not changing any indicators.  So users won't see anything different
(aside from perhaps latency and error resilience characteristics, plus -
maybe - failures in the presence of a MitM attack).

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 21 May 2014 17:25:03 -0700

I've skimmed the draft in more detail now and have nits:

* Grammar in section 6.3. - "A browser client MUST clear persisted all
alternative service information when clearing other origin-based state
(i.e., cookies)."
* Please consistently use "alternative services" instead of "alternate
services".

I don't feel very strongly, but I am not sure where the times for the
operational considerations are coming from. IIRC, HSTS and HPKP use much
longer max-ages. Why does this draft suggest capping at 1 month?

Cheers.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 22 May 2014 12:56:09 +1000

On 22 May 2014, at 10:25 am, William Chan (陈智昌) <[email-masked]> wrote:

> * Grammar in section 6.3. - "A browser client MUST clear persisted all alternative service information when clearing other origin-based state (i.e., cookies).”

Fixed in-repo, thanks.

> * Please consistently use "alternative services" instead of "alternate services”.

Dang, missed one.

> 
> I don't feel very strongly, but I am not sure where the times for the operational considerations are coming from. IIRC, HSTS and HPKP use much longer max-ages. Why does this draft suggest capping at 1 month?

Martin?

> 
> Cheers.
> 
> 
> On Mon, May 19, 2014 at 8:59 PM, Martin Thomson <[email-masked]> wrote:

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 May 2014 03:36:58 -0700

That was a temporary value that never got fixed up.  Mainly because I don't
think that HSTS actually has a recommendation, and that is a closer fit
than HPKP. HPKP suggests 60 days, so maybe a slightly longer value, say 90,
is appropriate.

I'm happy to take suggestions. I'm sure that folks have plenty of paint for
this.

---

From: "Martin Nilsson" <[email-masked]>
Date: Tue, 27 May 2014 02:08:36 +0200

So some thoughts on this from a proxy point of view.

#1 As a transparent proxy you could observe a client make a request, get  
an alt-svc header in the response, and then see the client make another  
clear text request. The proxy could at that point make a TLS connection  
between the proxy and destination server.

#2 As a transparent proxy you could observe a client make a request, get  
an response lacking alt-svc, and inject one to get the client to connect  
through TLS to the proxy (given client support). The proxy needs a way to  
distinguish between these TLS connections and "real" (opportunistic or  
https-initiated) TLS connections from the client, which currently can only  
be done by picking a differnt port that is unlikely (or probed not) to be  
in use. It would mess with alt-svc caching however.

If increasing the feet of encrypted cables is a goal, then both of these  
scenarios should be valid.

/Martin Nilsson

On Tue, 20 May 2014 05:42:50 +0200, Mark Nottingham <[email-masked]> wrote:

>> To: "Mark Nottingham" <[email-masked]>, Martin Thomson  
>> <[email-masked]>, "Martin Thomson"  
>> <[email-masked]>, Mark Nottingham <[email-masked]>
>>
>>
>> URL:             
>> http://www.ietf.org/internet-drafts/draft-nottingham-http2-encryption-03.txt
>> Status:          
>> https://datatracker.ietf.org/doc/draft-nottingham-http2-encryption/
>> Htmlized:        
>> http://tools.ietf.org/html/draft-nottingham-http2-encryption-03
>> Diff:            
>> http://www.ietf.org/rfcdiff?url2=draft-nottingham-http2-encryption-03
>>
>> Abstract:

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 May 2014 10:20:28 -0700

On 26 May 2014 17:08, Martin Nilsson <[email-masked]> wrote:
> #2 As a transparent proxy you could observe a client make a request, get an
> response lacking alt-svc, and inject one to get the client to connect
> be done by picking a differnt port that is unlikely (or probed not) to be in
> use. It would mess with alt-svc caching however.

I think that the decision so far has been to keep proxy use orthogonal
to its operation.

Yes, as defined, a transparent proxy could opportunistically upgrade
either (or both) links that it maintains.  It won't be able to make
this situation more permanent though, that would enable a DoS attack.