Subject: New versions of encryption drafts

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Dec 2016 16:33:55 +1100

I've just uploaded new versions of the two encryption-y drafts that I'm editing.

https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2-encryption/

This captures the discussion on the list, which is really just two changes:
  - Coalescing on HTTP and with HTTP is now verboten.
  - The .well-known resource is much simpler.

https://datatracker.ietf.org/doc/draft-ietf-httpbis-encryption-encoding/

This also captures what has been discussed, primarily the removal of
the header fields.

I have not addressed the concern raised about the format of the key
identifier. I realize that some protocols are unable to handle binary
identifiers, but others rely on them.  There's probably some text that
can be added that will help here, but I'm not seeing it right now.

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 22 Dec 2016 08:01:22 +0200 (EET)

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

|                   Connections that use client certificates for other
|   reasons MAY be reused, though client certificates MUST NOT affect the
|   responses to requests for "http" resources.

https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-09#section-2.2

|   Clients MUST NOT send "http" requests and "https" requests on the
|   same connection. 

What are connections  that use client certificates for other reasons
because they can not be connections which are used for "https" requests ?

https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-09#section-2.1

|   Clients MUST NOT send "http" requests over a secured connection,
|   unless the chosen alternative service presents a certificate that is
|   valid for the origin - as per [RFC2818] (this also establishes
|   "reasonable assurances" for the purposes of {RFC7838}}) - and they
|   have obtained a valid http-opportunistic response for an origin (as
|   per Section 2.3).

I'm not sure that this 

    "they have obtained a valid http-opportunistic response for an origin (as
    per Section 2.3)."

is saying.

This text or example after that seems not say from read /.well-known/http-opportunistic
need to be read. From original connection or from putative alternative service.
Or is it irrelevant?

|   For example, assuming the following request is made over a TLS
|   connection that is successfully authenticated for those origins, the
|   following request/response pair would allow requests for the origins
|   "http://www.example.com" or "http://example.com" to be sent using a
|   secured connection:
|
|   HEADERS
|     + END_STREAM
|     + END_HEADERS
|       :method = GET
|       :scheme = http
|       :path = /.well-known/http-opportunistic
|       host: example.com
|
|   HEADERS
|       :status = 200
|       content-type = application/json
|   DATA
|     + END_STREAM
|   [ "http://www.example.com", "http://example.com" ]

/ Kari Hurtta

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Dec 2016 23:19:51 +1100

Ugh, I just realized that I didn't open an issue for the record size
issue that was opened on the list earlier.  That means that I didn't
fix that either.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 23 Dec 2016 13:47:11 +1100

And I have now corrected that oversight.  I have also added text about
use of UTF-8.  It's SHOULD.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 23 Dec 2016 16:58:52 +1100

Thanks for the prompt review.  Inline.

> |   responses to requests for "http" resources.
[...]
> because they can not be connections which are used for "https" requests ?

That's an editorial snafu.  I've fixed it.  It now reads (in full):

   Client certificates are not meaningful for URLs with the "http"
   scheme, and therefore clients creating new TLS connections to
   alternative services for the purposes of this specification MUST NOT
   present them.  A server that also provides "https" resources on the
   same port can request a certificate during the TLS handshake, but it
   MUST NOT abort the handshake if the client does not provide one.

>     "they have obtained a valid http-opportunistic response for an origin (as

Section 2.3 defines a valid http-opportunistic response:

   [...] A client is said to have a valid http-opportunistic

> need to be read. From original connection or from putative alternative service.

Yes, that's an oversight.  The only requirement is that the request is
made to the authenticated alternative.

And the contradiction is a problem.  I've pushed a commit that should fix this:

https://github.com/httpwg/http-extensions/commit/467d6b2773304e47cad09f6a8af62a7448fe3312

---

From: Kari Hurtta <[email-masked]>
Date: Fri, 23 Dec 2016 09:44:53 +0200 (EET)

Martin Thomson <[email-masked]>: (Fri Dec 23 07:58:52 2016)
>    response for a given origin when:

It was that " - and they " what confused me.

I note that

you made that back to one sentence, so "they" refers to "Clients".

This is still quite long sentence to parse.

|  Clients MUST NOT send http requests over a secured connection, unless the chosen 
|  alternative service presents a certificate that is valid for the origin as defined in 
|  {{RFC2818}} (this also establishes "reasonable assurances" for the purposes of 
|  {RFC7838}}) and they have obtained a valid http-opportunistic response for an origin 
|  (as per {{well-known}}). 

OK that is manageable (if I read that several times).

> made to the authenticated alternative.

I'm not sure that I understand that from

https://github.com/httpwg/http-extensions/blob/467d6b2773304e47cad09f6a8af62a7448fe3312/draft-ietf-httpbis-http2-encryption.md

text.  Yes, this

   "An exception to the last restriction is made for requests for the 
    "http-opportunistic" well-known URI."
 
gives strong hint.

You mean that on

   "The client has requested the well-known URI from the origin over an authenticated 
    connection and a 200 (OK) response was provided, and"

authenticated connection is authenticated alternative.

Or is there something what I missed?

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Fri, 23 Dec 2016 09:58:49 +0200 (EET)

Kari Hurtta <[email-masked]>: (Fri Dec 23 09:44:53 2016)
> authenticated connection is authenticated alternative.

Hmm. I need rephrase.  Sorry for duplicate mail.

Question is that well-known URI need to requested from all putative
alternatives or not?. Yes, you can not request that from clear text 
connection now.

But need you request it from new alternative service when you
are requsted from previous alaternative service?

In other words is there requirement that given alternative service
is tested ?

/ Kari Hurtta