Re: Response to HTTP2 expresions of interest

Definitely a tricky thing here because of the competing interests and
requirements at play. Transport-layer secure provides the necessary
protection against snoopers but makes the efficient routing and
handling of the communication via intermediaries far more difficult.
Given the revised framing allowed in SPDY, is conceivable that two
distinct layers of security can be utilized here... one protecting the
envelope and another protecting the data end to end. The question then
becomes: which information is part of the envelope and which is part
of the payload... the fact that intermediaries need to be able to
route based on request URI and cookies is what makes this question
difficult to answer.

Perhaps something along the following lines would work:

1. Allow for an additional set of control frames that allow for the
negotiation of keys for use with encrypted streams...
2. Once established, a SYN_STREAM can be sent in the clear containing
ONLY the information the sender is willing to share "in the clear"
with the intermediary. This may or may not include cookie and request
URI details. The intermediary can determine, based on what is shared,
whether it is capable of properly handling the request with the
information given. If it's not, it can refuse the stream. The
intermediary could also potentially send it's own control frame
indicating which information it requires in order to do it's job.
Either end can choose to accept or reject the stream based on the
stated requirements.
3. Assuming the stream is accepted, either end can choose to send
encrypted data frames interleaved with clear text data frames.
encrypted data frames would include the ID of the negotiated key.
4. A sender can choose to send an unencrypted data frame if the frame
contains information that it feels is ok for the intermediary to see
and operate on. At any time, if the intermediary feels it does not
have sufficient access to the data in the stream to do it's job, it
can reject the stream.
5. With this Transport Layer Security can continue to be used. At the
intermediary level, it would only need to deal with encryption at the
TLS level, while leaving it to the client and server to deal with the
stream-level encryption.

This definitely adds an additional layer of complexity to the whole
process but I think the benefits would be worth it. For one, done
properly, it would allow two endpoints to negotiate encryption of the
data on the fly based on individual requests, even when transport
layer security is not being used... and encrypted data could be sent
interleaved with non-encrypted data on the same connection... even
within the same stream...

- James

On Fri, Jul 13, 2012 at 10:41 AM, Tim Bray <tbray@textuality.com> wrote:
> How much information needs to be in the unprotected envelope?  Because one
> of the benefits of transport-level security is that a snooper, for example a
> government tracking dissidents, knows little/nothing about my traffic aside
> from the routing.  Not a rhetorical question.  -Tim
>
>
> On Fri, Jul 13, 2012 at 10:37 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>
> wrote:
>>
>> In message
>> <CAMm+Lwgr1cnM3-iz_quKhN9N_dS1d6qdv26kSvKZ+T_Hr9L+hw@mail.gmail.com>
>> , Phillip Hallam-Baker writes:
>>
>> >5a) The TLS-HTTP gap
>> >
>> >Now as far as HTTP is concerned, headers have security implications
>> >and so HTTP is not going to be acceptably secure without either
>> >transport layer or packet layer security.
>>
>> I disagree.
>>
>> What HTTP lacks is a clear distinction between "envelope" and "body"
>> the way SMTP and NNTP have it.
>>
>> HTTP/2.0 would enable a lot more sites to run with cryptographic
>> security, if there were an unprotected envelope for load-balancers
>> to act on.
>>
>> I also think it should be possible to mix protected and unprotected
>> requests on the same TCP session.
>>
>> --
>> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>> phk@FreeBSD.ORG         | TCP/IP since RFC 956
>> FreeBSD committer       | BSD since 4.3-tahoe
>> Never attribute to malice what can adequately be explained by
>> incompetence.
>>
>

Received on Friday, 13 July 2012 18:10:57 UTC