Re: New Version Notification for draft-nottingham-http2-encryption-00.txt

On 08/10/2013, at 11:25 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
>>> Having thought about this at great length, I wonder why Upgrade isn't
>>> appropriate here, aside from the obvious deficiencies we've already
>>> identified.
>> 
>> What are you including in that?
> 
> The non-zero probability of outright failure, the probability of
> failure that looks like success, the extra round trips needed to some
> types of requests, plus all the other things I'm not aware of around
> use of Upgrade that causes things like websockets to fail.

Yes.


>> The biggest for me is perf, and that's pretty much a showstopper.
> 
> I have only the vaguest of inklings as to what you are talking about
> here.  I'm not sure that others have even that much context.  I was
> hoping that you could elaborate.

Upgrade would necessitate at least one extra RT, perhaps many; it's like STARTTLS. You'd be left with a useless connection while the connection upgraded. 

In contrast, the Alt-Svc approach would allow you to continue to use the existing non-TLS connection if you wanted to (acknowledging that some -- maybe many -- won't). 

More to the point, because the state of alternate services is cached across more than one connection, the impact is mitigated to only one connection per freshness lifetime period.

It's true that we could come up with some backwards-compatible caching scheme for Upgrade semantics, but IME retrofitting semantics onto existing fields is always nasty, and like you say, there are a lot of other problems. Fundamentally, using *another* connection is much more interesting than using *this* connection is. Upgrade only applies to this connection.

There's yet another motivation for Alt-Svc which I don't want to entwine in this discussion *too* much, since it's not a security requirement, and it's not fleshed out yet. 

HTTP/2 is introducing much longer-lived connections to the protocol, and that has significant impact on servers, load balancers and CDNs, who current rely on the short-lived session semantics of HTTP (often assisted by DNS trickery) to do their thing. The new abstraction of "alternate service" gives us a way to accommodate their needs to shift traffic around gracefully, while preserving the performance benefits of HTTP/2 (if we get it right).

All of that aside, an idea buried deep inside this draft is that the use of TLS is surfacing in the ALPN protocol now; how you discover it is a separable thing (and there may be many answers; e.g., Alt-Svc, Upgrade, DNS). The first question I'd like to see answered is whether people are comfortable with that.


>>> After all, we're already requiring the use of Upgrade for
>>> HTTP/2.0 (at least for the in-the-clear cases).  The use of the header
>>> seems unnecessary, and with the same-hostname restriction bound to it
>>> (the escape clause too hand-wavey for me to take it seriously), it's
>>> effectively the same.
>> 
>> Sorry, you're going to have to expand that a bit. What escape clause is too hand-wavey?
> 
> The "unless additional checks are performed" is the escape clause:
> 
>   Upon initial adoption of this proposal, it is expected that no such
>   additional checks will be performed.  Therefore, the client MUST NOT
>   use the "http2-tls-relaxed" profile to connect to alternate services
>   whose host does not match that of the origin, unless additional
>   checks are performed.
> 
>   This requirement bounds the risk of a service being hijacked and
>   redirected to another host; see Security Considerations for details.

Ah, that part. I know where you're coming from; this is really to start the discussion. AIUI some people feel that the hand-waviness is a good thing; hopefully that'll come out. OTOH if we can agree to tighten it up, I have absolutely no problem with that.


>>> I also wonder why you bothered to introduce the concept of a
>>> "http2-tls-relaxed" profile.  To my mind, since the decision to use
>>> TLS for the "http" resource was discretionary on the part of the
>>> client, then the decision to validate the server certificate is
>>> equally discretionary.  I would have thought that the logic would go
>>> something like:
>> 
>> The server needs to know whether the cert is being validated (as discussed in a note near the end, there's more work to do on this).
> 
> I read through this draft several times, but didn't find a note that
> explained it.  

Here you go:

"""
* Indicating Chosen Service: It's likely necessary for the server to know which
  protocol the client has chosen, and perhaps even the hostname (for load
  balancing). This could be conveyed as part of the "magic", or as a request
  header. There are also security implications here; for example, without this
  information, the server doesn't know if the client has checked the
  certificate, leading to a situation where an intermediary can downgrade a
  HTTPS connection to relaxed HTTP.
"""

This is the attack that Eliot highlighted earlier. I'm still not 100% convinced that this is significant, but it needs to be discussed.


> Even assuming Mike Bishop's inference, which is at
> least superficially plausible, I don't see how that creates any
> expectation that (thanks Paul) the server needs to know:
> 
> 1) Whether or not the client authenticated [the server]
> 2) If (1) is true, whether there is a host name was in the cert's identity
> 3) If both (1) and (2) are true, what the host name is

Imagine a server with both HTTPS URIs and HTTP URIs pointing at the same (host, port). 

I acknowledge that a suitable outcome might be "don't do that."

Back to the original question - as I alluded to in the draft, it may be that we don't need to define http2-tls-relaxed, because we can define the semantics of HTTP URIs using http2-tls with sufficient clarity.

Personally, I'm a big fan of being explicit, rather than relying on combinations of things ("http" uri + TLS profile) to infer things, especially when security is involved.

Additionally, I'm not yet convinced we're going to be able to agree on *one* way to do things here, which means we'll need a few different explicit options. I'd love to be proven wrong, of course.

In the meantime, feel free to read the http2-tls-relaxed section as "how we use http2-tls with HTTP URIs" if that makes it go down easier.


> If the intent is to learn what resources or origins a client might be
> inclined to accept when pushed, then perhaps that needs to be explored
> more.  The above is one of many solutions to that particular problem.

To be honest, I hasn't considered the implications of push here; it is definitely an interesting (and necessary) avenue to explore.


> I suggest that foremost amoungst those solutions for consideration
> should be "no protocol machinery".

“Make things as simple as possible, but not simpler.”


--
Mark Nottingham   http://www.mnot.net/

Received on Tuesday, 8 October 2013 06:47:47 UTC