Subject: Fwd: New Version Notification for draft-ietf-httpbis-http2-encryption-06.txt

From: Mark Nottingham <[email-masked]>
Date: Tue, 21 Jun 2016 13:41:25 +1000

We think that this draft fixes the issues that came up in WGLC - 

* https://github.com/httpwg/http-extensions/issues/192 - Prohibit client certs from being used with Opp-Sec
* https://github.com/httpwg/http-extensions/issues/188 - Don't mix secure and insecure schemes on a connection
* https://github.com/httpwg/http-extensions/issues/162 - Separate lifetime from commitment element

Please have a look and come back to the list if you have concerns or comments; once Mike judges we have consensus (as the Document Shepherd), we'll hand it over to the IESG.

Cheers,

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-ietf-httpbis-http2-encryption-06.txt
> Date: 21 June 2016 at 1:37:48 PM AEST
> To: "Mark Nottingham" <[email-masked]>, "Martin Thomson" <[email-masked]>
> 
> 
> A new version of I-D, draft-ietf-httpbis-http2-encryption-06.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Name:		draft-ietf-httpbis-http2-encryption
> Revision:	06
> Title:		Opportunistic Security for HTTP
> Document date:	2016-06-21
> Group:		httpbis
> Pages:		12
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-httpbis-http2-encryption-06.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2-encryption/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-06
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-http2-encryption-06
> 
> Abstract:
>   This document describes how "http" URIs can be accessed using
>   Transport Layer Security (TLS) to mitigate pervasive monitoring
>   attacks.
> 
> Note to Readers
> 
>   Discussion of this draft takes place on the HTTP working group
>   mailing list ([email-masked]), which is archived at
>   https://lists.w3.org/Archives/Public/ietf-http-wg/ .
> 
>   Working Group information can be found at http://httpwg.github.io/ ;
>   source code and issues list for this draft can be found at
>   https://github.com/httpwg/http-extensions/labels/opp-sec .
> 
> 
> 
> 
> 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   https://www.mnot.net/

---

From: Kari Hurtta <[email-masked]>
Date: Wed, 22 Jun 2016 19:36:14 +0300 (EEST)

Opportunistic Security for HTTP
https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-06

https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-06#section-5.1

|   When the value of the "tls-commit" member is "true" ([RFC7159],
|   Section 3), it indicates that the origin makes such a commitment for
|   the duration of the origin object lifetime.

|   Including "tls-commit" creates a commitment to provide a secured
|   alternative service for the advertised period.  Clients that receive
|   this commitment can assume that a secured alternative service will be
|   available for the origin object lifetime.  Clients might however
|   choose to limit this time (see Section 5.3).

https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-06#section-6

|   o  The origin object has a "lifetime" member, whose value is a number
|      indicating the number of seconds which the origin object is valid
|      for (hereafter, the "origin object lifetime"), and
|
|   o  The origin object lifetime is greater than the "current_age" (as
|      per [RFC7234], Section 4.2.3).

I think that this does not say when origin's object lifitime starts.
This seems imply that object lifetime start from that point what "current_age"
calculation uses but that is not required.

Therefore I guess that remaining lifetime (and possible remaining commitment)

   = lifetime - "current_age"

But seem that remaining commintment time
    = value of "lifitime"

is also possible reading.  This does not look dangerous.

|   Including "tls-commit" creates a commitment to provide a secured
|   alternative service for the advertised period.  Clients that receive
|   this commitment can assume that a secured alternative service will be
|   available for the origin object lifetime.  Clients might however
|   choose to limit this time (see Section 5.3).

This may do create variation of

https://github.com/httpwg/http-extensions/issues/162

Client limits commintment liftime and therefore does not consider
http-opportunistic for commintment but otherwise
http-opportunistic is valid because "lifetime" member value is
smaller than "current_age".

Now this does not look very dangerous, because if http-opportunistic
is used only for commintment, then there is no "tls-ports".

/ Kari Hurtta

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Jun 2016 16:18:30 +1000

> is used only for commintment, then there is no "tls-ports".

That was my assessment.  The entire structure is either valid or
invalid as a whole.

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 23 Jun 2016 17:56:39 +0300 (EEST)

|   When the value of the "tls-commit" member is "true" ([RFC7159],
|   Section 3), it indicates that the origin makes such a commitment for
|   the duration of the origin object lifetime.
|
| 
|   {
|     "http://www.example.com": {
|       "tls-ports": [443,8080],
|       "tls-commit": true,
|       "lifetime": 3600
|     }
|   }

Should this example omit "tls-ports" member ?

"tls-commit" requires valid certificate:

|   be applied to authenticating the alternative.  Minimum authentication
|   requirements for HTTP over TLS are described in Section 2.1 of
|   [RFC7838] and Section 3.1 of [RFC2818].  As noted in [RFC7838],
|   clients can impose other checks in addition to this minimum set.  For
|   instance, a client might choose to apply key pinning [RFC7469].

And "tls-ports" is use for situation when there is no valid certificate:

https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-06#section-3

|   This allows deployment without the use of valid certificates, to
|   encourage deployment of opportunistic security.  When it is in use,
|   the alternative service can provide any certificate, or even select
|   TLS cipher suites that do not include authentication.

|   o  The origin object of the http-opportunistic response has a `tls-
|      ports' member, whose value is an array of numbers, one of which
|      matches the port of the alternative service in question, and

/ Kari Hurtta

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Jun 2016 06:54:50 +1000

> Should this example omit "tls-ports" member ?

I don't think so.  If this is going to be used, we need to know where
it is both possible and allowable to use the alternative.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 23 Jun 2016 21:44:38 +0000

Having "tls-ports" and "tls-commit" in the same response seems mildly nonsensical.  If "tls-commit" is present, then for the lifetime of that origin object, I would expect a "secured, authenticated alternative" to be available.  I should therefore disregard any unauthenticated alternatives.  But "tls-ports" at the same time tells me what ports I should accept referrals to *without* requiring authentication.  It may not break anything to have both, but an implementation that respects tls-commit will likely disregard the tls-ports value, so it's an odd example to provide.

Or is there a scenario where offering both makes sense?

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Thursday, June 23, 2016 1:55 PM
To: Kari Hurtta <[email-masked]>
Cc: HTTP working group mailing list <[email-masked]>; Mark Nottingham <[email-masked]>; Mike Bishop <[email-masked]>
Subject: Re: draft-ietf-httpbis-http2-encryption-06.txt

> Should this example omit "tls-ports" member ?

I don't think so.  If this is going to be used, we need to know where it is both possible and allowable to use the alternative.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Jun 2016 09:38:07 +1000

On 24 June 2016 at 07:44, Mike Bishop <[email-masked]> wrote:
> But "tls-ports" at the same time tells me what ports I should accept referrals to *without* requiring authentication.

So you are saying that any port is OK if you can authenticate the
server.  That's true.  Is this as simple as removing the example, or
do you think we need to say that the two members are mutually
exclusive?

---

From: Mike Bishop <[email-masked]>
Date: Thu, 23 Jun 2016 23:52:29 +0000

Kari's feedback, I'll let him weigh in with his own opinion.

As I understand the issue, I think removing "tls-ports" from this particular example is sufficient.  As noted, there's nothing that breaks if they're both present (so normative prohibition probably not needed); it's just silly to do so, and we shouldn't encourage it by including it in an example.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Thursday, June 23, 2016 4:38 PM
To: Mike Bishop <[email-masked]>
Cc: Kari Hurtta <[email-masked]>; HTTP working group mailing list <[email-masked]>; Mark Nottingham <[email-masked]>
Subject: Re: draft-ietf-httpbis-http2-encryption-06.txt

> But "tls-ports" at the same time tells me what ports I should accept referrals to *without* requiring authentication.

So you are saying that any port is OK if you can authenticate the server.  That's true.  Is this as simple as removing the example, or do you think we need to say that the two members are mutually exclusive?

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Jun 2016 09:56:59 +1000

Would it help to adjust the Introduction to portray them more as alternative options?

> On 24 Jun 2016, at 9:52 AM, Mike Bishop <[email-masked]> wrote:
>

---

From: Mike Bishop <[email-masked]>
Date: Thu, 23 Jun 2016 23:58:02 +0000

Yes, I think that would also be a worthwhile improvement.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 24 Jun 2016 15:55:06 +1200

On 24/06/2016 11:52 a.m., Mike Bishop wrote:
> As I understand the issue, I think removing "tls-ports" from this
> particular example is sufficient.  As noted, there's nothing that
> breaks if they're both present (so normative prohibition probably not
> needed); it's just silly to do so, and we shouldn't encourage it by
> including it in an example.

It seems to me that this use of tls-ports is a mechanism to say that
both an authenticated path is available and certain ports are *not* safe
to use that way. The parameter name is just very odd for that meaning.

Use case would along the lines of a load balancer sitting in front of
the server diverts those ports somewhere else special that has
authentication but not for the service wanted.

(just throwing up wild ideas in case nones thought about it yet).

Amos

---

From: Kari Hurtta <[email-masked]>
Date: Fri, 24 Jun 2016 09:26:28 +0300 (EEST)

Mike Bishop <[email-masked]>: (Fri Jun 24 02:58:02 2016)
> > As I understand the issue, I think removing "tls-ports" from this particular example is sufficient.  As noted, there's nothing that breaks if they're both present (so normative prohibition probab…

Yes. "tls-ports" should removed from that example.
So that it is not encouraged that both are used
same time.

The Introduction (or some other place) should mention 
that "tls-ports" and "tls-commit" are alternative options. 
And also mention that including them both on same origin 
object is likely mistake.

They not need to be formally mutually exclusive
(that is: including both members does not make 
 /.well-known/http-opportunistic invalid).

This allows clients, which does not support
commintment, totally ignore "tls-commit"
member. If they are formally exclusive,
then client need still check "tls-commit"
to see is /.well-known/http-opportunistic
valid).

/ Kari Hurtta

---

From: Kari hurtta <[email-masked]>
Date: Fri, 24 Jun 2016 10:52:05 +0300 (EEST)

( Using same time "tls-ports" and "tls-commit" member )

| It seems to me that this use of tls-ports is a mechanism to say that
| both an authenticated path is available and certain ports are *not* safe
| to use that way. The parameter name is just very odd for that meaning.
|  
| Use case would along the lines of a load balancer sitting in front of
| the server diverts those ports somewhere else special that has
| authentication but not for the service wanted.

| (just throwing up wild ideas in case nones thought about it yet).

Intresting idea.

So "tls-ports" lists safe ports and that imply that other ports
are not safe to use for that origin.

Was that what you mean ?

I'm not sure that this works.

1) 

Per RFC7838 client does not need even read
/.well-known/http-opportunistic
It is enough that there is valid certificate.

I guess that load balancer can just filter
Alt-Svc: -header fields from response instead.

2) 

If there is no service wanted, then that port
does not include same /.well-known/http-opportunistic
(I guess).

However "tls-commit" does not require that that
alternative port gives same /.well-known/http-opportunistic
representation as the origin did for the http-opportunistic 
resource.

On that case it does make sense to require 
that /.well-known/http-opportunistic are same
on both on alternative and origin.

( I suggested that on
  https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0481.html

| 3. Server Authentication requires that
| 
| | The chosen alternative service returns the same response as above.
| 
| Should there be same requirement before "commit" is accepted ?
| Now that is not required for commit.

)

3) 

Currently "tls-ports" does not have specified that way.
It does not have negating power.

/ Kari Hurtta
( Away until 2016-06-27 )

---

From: Kari hurtta <[email-masked]>
Date: Tue, 28 Jun 2016 11:23:30 +0300 (EEST)

https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-06#section-2

|   A client can also explicitly probe for an alternative service
|   advertisement by sending a request that bears little or no sensitive
|   information, such as one with the OPTIONS method.  Likewise, clients
|   with existing alternative services information could make such a
|   request before they expire, in order minimize the delays that might
|   be incurred.

Side note:

I think that

GET /.well-known/http-opportunistic HTTP/1.1

works even better than OPTIONS for probe. If this gives 
Alt-Svc: header then there is no even need to lookup for 
http-opportunistic  -resource.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Tue, 28 Jun 2016 11:59:30 +0300 (EEST)

Kari Hurtta <[email-masked]>: (Wed Jun 22 19:36:14 2016)
> is used only for commintment, then there is no "tls-ports".

Better:

   Clients might however choose to limit the origin object lifetime

https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-06#section-5.3

|   To avoid situations where a commitment causes errors, clients MAY
|   limit the time over which a commitment is respected for a given
|   origin.

this comes:

    limit the origin object lifetime (and that way limit the time over 
    which a commitment is respected for a given origin).

Not very critical if using of "tls-ports" and "tls-commit"
on same origin object is discouraged.

/ Kari Hurtta

---

From: Kari hurtta <[email-masked]>
Date: Tue, 28 Jun 2016 19:09:45 +0300 (EEST)

|   o  The root object contains a member whose name is a case-insensitive
|      character-for-character match for the origin in question,
|      serialised into Unicode as per Section 6.1 of [RFC6454], and whose
|      value is an object (hereafter, the "origin object"),

If there is several members whose name is a case-insensitive
character-for-character match for the origin in question,
which one is the origin object ?

First, Last ?

Is this invalid ?

https://tools.ietf.org/html/rfc7159#section-4

|   An object whose names are all unique is interoperable in the sense
|   that all software implementations receiving that object will agree on
|   the name-value mappings.  When the names within an object are not
|   unique, the behavior of software that receives such an object is
|   unpredictable.  Many implementations report the last name/value pair
|   only.  Other implementations report an error or fail to parse the
|   object, and some implementations report all of the name/value pairs,
|   including duplicates.

Even when all member names are unique, there can be several members
which are case-insensitive character-for-character match for the origin 
in question.

I think thare there is perhaps 4 different possible implementatio
startego for this (if this is not specified)

1) Pick first matching member
2) Pick last matching member
3) Treat "http-opportunistic" as invalid
4) Merge some way all matching members

/ Kari Hurtta

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Jun 2016 11:18:57 +1000

> 4) Merge some way all matching members

Or 5) pick any matching member.
Or 6) leave it to chance.

I think that given the state of JSON parsers, we should take option 6.
Not all parsers will make duplicate keys detectable.  And some
generate fatal errors.

Thus: A client MAY use any matching origin object, but by preference
they SHOULD pretend that conflicting values don't exist.

I think that's it's worth explaining why we choose this option too.
How does https://github.com/httpwg/http-extensions/pull/205 look to
you?

---

From: Mike Bishop <[email-masked]>
Date: Thu, 30 Jun 2016 16:01:40 +0000

WFM.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Wednesday, June 29, 2016 6:19 PM
To: Kari hurtta <[email-masked]>
Cc: HTTP working group mailing list <[email-masked]>; Mike Bishop <[email-masked]>; Mark Nottingham <[email-masked]>
Subject: Re: The "http-opportunistic" well-known URI | draft-ietf-httpbis-http2-encryption-06

I think that given the state of JSON parsers, we should take option 6.
Not all parsers will make duplicate keys detectable.  And some generate fatal errors.

Thus: A client MAY use any matching origin object, but by preference they SHOULD pretend that conflicting values don't exist.

I think that's it's worth explaining why we choose this option too.
How does https://github.com/httpwg/http-extensions/pull/205 look to you?

---

From: Kari hurtta <[email-masked]>
Date: Thu, 30 Jun 2016 23:25:55 +0300 (EEST)

Martin Thomson <[email-masked]>: (Thu Jun 30 04:18:57 2016)
> How does https://github.com/httpwg/http-extensions/pull/205 look to

| The JSON format for the http-opportunistic resource makes it possible to 
| include multiple values for the same origin. Variations in case allow for duplicate 
| keys that a JSON parser will treat as different.  Duplicated keys might not be 
| detected by a client (see Section 4 of {{RFC7159}}). A client SHOULD NOT use 
| origin objects if multiple keys match, though it MAY  use any origin
| object with a matching key.

Looks good.

I see that requiring more means that client must implement JSON parser
itself.

| Many implementations report the last name/value pair
| only.  Other implementations report an error or fail to parse the
| object, and some implementations report all of the name/value pairs,
| including duplicates.

So there may be similar problem also with "lifetime", "tls-ports" and
"tls-commit" members.

Perhaps:

" A client MAY treate http-opportunistic invalid as whole if it includes 
  duplicate member names on some object. A client SHOULD NOT use the origin 
  object, if it includes duplicate member names. "

This allows fatal errors when there is duplicate on some object (even when
it is not current origin). 

/ Kari Hurtta

---

From: Martin Thomson <[email-masked]>
Date: Fri, 1 Jul 2016 07:50:37 +1000

>   object, if it includes duplicate member names. "

Isn't the first part implied by us using JSON?  After all, the text
you quoted from 7159 makes it apparent that duplicate member names
risks generating an error.

I'm happy to include this for the second part, though I'm also happy
to leave it on the basis that we're not doing anything special with
origin object members.

---

From: Kari hurtta <[email-masked]>
Date: Fri, 1 Jul 2016 09:35:34 +0300 (EEST)

Martin Thomson <[email-masked]>: (Fri Jul  1 00:50:37 2016)
> risks generating an error.

More or less. It is also "SHOULD".

| The names within an object SHOULD be unique.

This is requirement for generating http-opportunistic, but perhaps
there should be text in case where that generator requirement
is not followed.

Seems that it can be considered to be JSON when member names
are not unique.

|   o  That response's payload, when parsed as JSON [RFC7159], contains
|      an object as the root, and

So this alone does not make it, I think.

/ Kari Hurtta