Subject: Re: (rephrasing, sorry for duplicate) | Re: draft-ietf-httpbis-encryption-encoding

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Jan 2017 10:26:26 +1100

(Sorry about the delay, it's silly season here and I've been offline.)

On 23 December 2016 at 18:58, Kari Hurtta <[email-masked]> wrote:
> 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.

Ahh, so you check alt1.example.com and find that it's OK, what about
alt2.example.com?  It seems unnecessary once you have authenticated a
willingness to proceed.

How about:
"""
Any authenticated strongly alternative service can provide this
response. That is, as long as the http-opportunistic response is
valid, any authenticated alternative service can be used for that
origin.
"""

I understand that you might argue that there is safety in checking
every alternative differently.  That allows all alternatives to be
configured differently.

I expect that some implementations will likely check every time rather
than rely on cached values.  More so because - if you rely on your
cache - you need special logic to avoid caching this resource from
non-authenticated sources if you do that.  But that's optimization
territory and optimization is hazardous.

To that end:
"""
Clients that use cached http-opportunistic responses MUST ensure that
their cache is cleared of any responses that were acquired over an
unauthenticated connection.  Revalidating an unauthenticated response
using an authenticated connection does not ensure the integrity of the
response.
"""

See: https://github.com/httpwg/http-extensions/pull/279

I am open to arguments that require that the check is performed every
time, but that's less flexible.  This seems preferable.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Jan 2017 11:49:00 +1100

On 23 December 2016 at 18:44, Kari Hurtta <[email-masked]> wrote:
> 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).

Yeah, it's hard to parse.  I split it up here:

https://github.com/httpwg/http-extensions/pull/280

Is that clearer?

>> 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
[...]
> Or is there something what I missed?

There was this:

"""
A client is said to
have a valid http-opportunistic response for a given origin when:

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

But no harm in making it clearer (see the above PR).

---

From: Kari Hurtta <[email-masked]>
Date: Tue, 3 Jan 2017 20:18:12 +0200 (EET)

Martin Thomson <[email-masked]>: (Tue Jan  3 01:26:26 2017)

> time, but that's less flexible.  This seems preferable.

So answer to my question:

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

is that

Alternative service does not be need to be tested for
http: -scheme support (only some (= first) alternative 
service for that origin need to be tested. )

( Client have possibility to test alternative service 
  if client considers that usefull. )

/ Kari Hurtta

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Jan 2017 09:07:04 +1100

>   if client considers that usefull. )

Correct.

---

From: Kari Hurtta <[email-masked]>
Date: Fri, 6 Jan 2017 21:35:04 +0200 (EET)

Martin Thomson <[email-masked]>: (Tue Jan  3 02:49:00 2017)
> https://github.com/httpwg/http-extensions/pull/280

Hmm. Yes. 
https://github.com/httpwg/http-extensions/blob/21ff4e285dce0a2895b9b20057a6615e1b55e8a7/draft-ietf-httpbis-http2-encryption.md

| 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}}. Using an authenticated alternative service establishes "reasonable 
| assurances" for the purposes of {RFC7838}}. In addition to authenticating the server 
| the client MUST have obtained a valid http-opportunistic response for an origin (as per 
| {{well-known}}) using the authenticated connection. An exception to this restriction is 
| made for requests for the "http-opportunistic" well-known URI.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Tue, 10 Jan 2017 19:04:38 +0200 (EET)

> every alternative differently.  That allows all alternatives to be

However I suppose that alternative services are more or less
required to return same response for same resource. So 
/.well-known/http-opportunistic does not vary.

> time, but that's less flexible.  This seems preferable.

hmm.

Client may want keep track which alternative services succeed
and which failed when reading /.well-known/http-opportunistic

( This does not mean that it needs check 
  /.well-known/http-opportunistic
  on every time. )

Client asks http://example.com/  via http -connection

got Alt-svc for h2="a1.example.com:443"

tries /.well-known/http-opportunistic from this alternative
service and got 404 (not found)

retrieves http://example.com/img/logo.png  from original connection

got Alt-svc for h2="a2.example.com:443"

tries /.well-known/http-opportunistic from this alternative
and succeed -- now that is cached (and is retrieved via authenticated connection)

retrieves http://example.com/img/background.png from this alternative connection

Later

clients asks http://example.com/page.html
(does not matter which connection is used. )

got Alt-svc for h2="a1.example.com:443"

/.well-known/http-opportunistic   is already valid
(expires on 1 year )

so /.well-known/http-opportunistic need not be probed

Tries retrieve http://example.com/img/map.png
via a1.example.com alternative service
--- oops broken image ?

That was example where test for h2="a2.example.com:443"
imply that h2="a1.example.com:443" was ok even when
test for h2="a1.example.com:443" says opposite.

Any client, which does that like on my example, 
quite likely is considered to be buggy. Therefore
it may want to keep track for these probes
of /.well-known/http-opportunistic.

/ Kari Hurtta

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jan 2017 11:29:30 +1300

> and which failed when reading /.well-known/http-opportunistic

On the one hand, if a server advertises alternatives that are broken,
that really is a server problem.  On the other, clients do these sorts
of things all the time to improve robustness, so that's entirely
reasonable to do.  I just don't think we need to *require* it.

---

From: Kari Hurtta <[email-masked]>
Date: Wed, 11 Jan 2017 08:37:44 +0200 (EET)

Martin Thomson <[email-masked]>: (Wed Jan 11 00:29:30 2017)
> reasonable to do.  I just don't think we need to *require* it.

Yes, client needs that "Opportunistic Security for HTTP"
(draft-ietf-httpbis-http2-encryption) only to improve robustness.

Otherwise "HTTP Alternative Services" (RFC7838) is enough.

( Seems that I have "draft-ietf-httpbis-encryption-encoding"
  on subject when it should be "draft-ietf-httpbis-http2-encryption".
  Paste error? )

On the other hand "Opportunistic Security for HTTP" need specify
only that part where collaboration between client and server
is needed.

/ Kari Hurtta

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jan 2017 20:52:45 +1300

Thanks for confirming.  I think that this closes the issue.  Is that right?

(And don't worry about the title, I saw draft-ietf-..... and didn't
even notice.)

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 12 Jan 2017 07:16:28 +0200 (EET)

Martin Thomson <[email-masked]>: (Wed Jan 11 09:52:45 2017)
> Thanks for confirming.  I think that this closes the issue.  Is that right?

This feels like trap. Perhaps no normative requirement, but some 
warning may be on place (both clients implementators and server
administrators).

https://github.com/httpwg/http-extensions/blob/35609f8d621a3156031a93a5b118d53a5696f396/draft-ietf-httpbis-http2-encryption.md#the-http-opportunistic-well-known-uri-well-known

You added note about another trap:

| Clients that use cached http-opportunistic responses MUST ensure that their cache is 
| cleared of any responses that were acquired over an unauthenticated connection. 
| Revalidating an unauthenticated response using an authenticated connection does not 
| ensure the integrity of the response.

Perhaps:

  Using cached http-opportunistic responses as only criteria for accepting
  provided alternative service can lead situation where alternative
  server, which previously failed to provide /.well-known/http-opportunistic,
  is used by client.

  ( And something about that client can ignore any alternative service even
    when it accpets some other alternative services. And someting that
    server administartor need ensure that all alternative services are
    equally capable. )

This almost feel like that /.well-known/http-opportunistic need
to be cached separately for different alternative servises, but
think that this is not allowed. At least that becomes messy.

> (And don't worry about the title, I saw draft-ietf-..... and didn't

I probably looked that there was "encyption" on somewhere on name:
'draft-ietf-httpbis' + 'encryption'. 

That is somewhat confusing when there
is now two draft with that pattern.

/ Kari Hurtta