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

On 6 October 2013 00:23, Mark Nottingham <mnot@mnot.net> wrote:
> On 02/10/2013, at 2:02 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>
>> On 30 September 2013 17:54, Mark Nottingham <mnot@mnot.net> wrote:
>>> It proposes a way to optimistically encrypt communication for http:// URIs that is resistant to passive attacks, but is not (yet) resistant to active attacks. Full details are in the draft.
>>
>> 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.

> 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.

>>  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.

Note that using Upgrade provides a (marginally) stronger bound on this risk :)

>> 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.  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

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.
I suggest that foremost amoungst those solutions for consideration
should be "no protocol machinery".

Received on Monday, 7 October 2013 22:25:37 UTC