Re: draft-ietf-httpbis-encryption-encoding

Martin Thomson <martin.thomson@gmail.com>: (Fri Dec 23 07:58:52 2016)
> Thanks for the prompt review.  Inline.
> 
> On 22 December 2016 at 17:01, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote:
> > 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.
> [...]
> > What are connections  that use client certificates for other reasons
> > 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.
> 
> > I'm not sure that this
> >
> >     "they have obtained a valid http-opportunistic response for an origin (as
> >     per Section 2.3)."
> >
> > is saying.
> 
> Section 2.3 defines a valid http-opportunistic response:
> 
>    [...] A client is said to have a valid http-opportunistic
>    response for a given origin when:

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

I note that

https://github.com/httpwg/http-extensions/commit/467d6b2773304e47cad09f6a8af62a7448fe3312
 
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).

> > 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?
> 
> Yes, that's an oversight.  The only requirement is that the request is
> 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?

> And the contradiction is a problem.  I've pushed a commit that should fix this:
> 
> https://github.com/httpwg/http-extensions/commit/467d6b2773304e47cad09f6a8af62a7448fe3312

/ Kari Hurtta

Received on Friday, 23 December 2016 07:45:29 UTC