Re: New Version Notification for draft-snell-httpbis-keynego-01.txt

This approach definitely leaves room for some additional leakage.
Using the CONNECT tunnel approach described in the draft would address
at least *some* of this but even that is no where near a "complete"

Agreements negotiated with this model could be defined in such a way
as to introduce obfuscating factors, such as space and time padding,
out-of-sequence frames, etc) but you're absolutely right that there is
an increased risk.

Another potential risk factor is introduced by multiplexing. With
attacks like CRIME, part of the overall attack technique is to send
multiple slightly different requests over time, then statistically
analyzing the results. With TLS, we (at the very least) have the added
"benefit" that establishing each secured connection is relatively
expensive. That cost drops significantly when running over a
multiplexed connection.

- James

On Tue, Nov 19, 2013 at 3:50 PM, Mark Nottingham <> wrote:
> Thanks, James. A number of people have contacted me privately to express interest in a SHTTP-like approach, so it's good to see proposals written down.
> For me, one of the key questions about this general approach is whether the extra information leakage will be acceptable. I.e., an attacker will now know the "shape" of messages -- request and response -- on the wire, including their timing, size, relationships, etc.
> It's easy to imagine a way to characterise interactions with a given Web site and thus be able to correlate the observed messages with certain activities; e.g., "Bob is surfing the login page now, because he sent four requests, one request was significantly larger (due to a payload body on a POST), and the responses were of such-and-such a size."
> Is this significantly worse than HTTPS? AIUI TLS has leakage too, but it doesn't seem like it's as much as this would offer. I'd love to hear the security folks' opinions on that.
> Cheers,
> On 20/11/2013, at 8:13 AM, James M Snell <> wrote:
>> At Mark's urging, I've posted a significantly updated draft of the
>> "in-session key negotiation" draft that I had published last year.
>> Please treat this as purely experimental at this point. I am not
>> pushing this as a proposal just yet, just offering it up as one
>> possible approach to providing message-level security as opposed to
>> transport-level security. What this proposal does, in effect, is make
>> it possible to negotiate and use cryptographic keys from *inside* an
>> HTTP/2 connection as opposed to the TLS approach. A key benefit of
>> this approach is that it allows peers to establish secure
>> communication even over potentially insecure transports. Of course,
>> it's not a perfect solution.
>> As always, feedback is welcomed and requested.
>> - James
>> ---------- Forwarded message ----------
>> From:  <>
>> Date: Tue, Nov 19, 2013 at 1:08 PM
>> Subject: New Version Notification for draft-snell-httpbis-keynego-01.txt
>> To: "James M. Snell" <>
>> A new version of I-D, draft-snell-httpbis-keynego-01.txt
>> has been successfully submitted by James M Snell and posted to the
>> IETF repository.
>> Filename:        draft-snell-httpbis-keynego
>> Revision:        01
>> Title:           HTTP/2.0 Intra-Connection Negotiation
>> Creation date:   2013-11-19
>> Group:           Individual Submission
>> Number of pages: 6
>> URL:
>> Status:
>> Htmlized:
>> Diff:  
>> Abstract:
>>   This memo describes a proposed modification to HTTP/2.0 that
>>   introduces the concepts of Intra-Connection Negotiation and Secure
>>   Framing.
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at
>> The IETF Secretariat
> --
> Mark Nottingham

Received on Wednesday, 20 November 2013 00:22:08 UTC