- From: James M Snell <jasnell@gmail.com>
- Date: Fri, 13 Jul 2012 11:10:08 -0700
- To: Tim Bray <tbray@textuality.com>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Phillip Hallam-Baker <hallam@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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