- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Wed, 11 Jul 2012 21:51:51 -0400
- To: James M Snell <jasnell@gmail.com>
- Cc: Nico Williams <nico@cryptonector.com>, ietf-http-wg@w3.org
What are the problems inherent in using Content-Integrity as a Trailer? Do the legacy clients botch chunked encoding? On Wed, Jul 11, 2012 at 7:44 PM, James M Snell <jasnell@gmail.com> wrote: > Phillip, just want to make sure that I'm keeping up with the > conversation thus far... Because of the problems inherent in using > Content-Integrity as a Trailer, is the idea then that > Content-Integrity would be a standard Header and that a new Transfer > or Content Encoding would be defined that supports an incremental > integrity check as a component of the encoding? > > GET /some/uri HTTP/1.1 > Host: example.org > TE: integrity > > For instance... something like... > > HTTP/1.1 200 OK > Content-Type: application/octet-stream > Content-Integrity: SHA-256; modifier=123...; param="..." > Transfer-Encoding: integrity > > 10 > {chunk of bytes} > {digest} > 10 > {chunk of bytes} > {digest} > 0 > > - James > > On Wed, Jul 11, 2012 at 4:07 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote: >> On Wed, Jul 11, 2012 at 2:43 PM, Nico Williams <nico@cryptonector.com> wrote: >>> I agree that we need something better, and in particular that we ought >>> to have a MAC instead of a plain hash. The problem with a MAC is: >>> whence the key? Also, what should the MAC be applied to? >> >> The MAC should be applied to the 8-bit clean message content (i.e. >> precisely that which is bounded by Content-Length) >> >> If we are talking about Web Services then the key would be established >> through some application layer key exchange (TBS). >> >> The key requirement from a performance standpoint as I see it is that >> the server has to be able to operate in a stateless fashion which >> means using a ticket like approach. >> >> >>> Using a MAC, having a shared session key, ties into HTTP >>> authentication. We can definitely have a generic MAC for HTTP and say >>> that HTTP authentication mechanisms that can should output session >>> keys. And the HTTP authentication would also have to take care of MAC >>> algorithm negotiation. I'd be quite happy with this approach. >> >> I think that there is definitely an opportunity to make use of a >> ticket mode to tie the HTTP authentication to the HTTP channel. >> >> >>> One issue with this approach is: if we always use TLS (but we might >>> not), why do the extra session crypto? What do we gain? Do we need >>> to worry about content re-writing proxies, say, as in some 3G >>> networks? If we always use TLS then it suffices to ensure that a) TLS >>> provides confidentiality protection, b) the server cert remains the >>> same for the length of the login session, c) we have a unique, >>> unpredictable session ID in the headers (what we might call a cookie, >>> though we don't want it to be a cookie as such). >> >> TLS is very large, very complex and was engineered from the assumption >> that there would be public key credentials on the client. Yes, people >> can train it to do other tricks, but doing that is a lot more complex >> than doing what we need in HTTP. >> >> In my particular Web Service I am using TLS but still want to have a >> transport layer authentication protection because I don't want to do a >> TLS public key negotiation on each transaction and I don't want to be >> bound to TLS session expiry. >> >> In a large commercial environment the TLS processing is often >> completely offloaded onto an accelerator that strips out the TLS and >> hands clean IP packets to the Web Service. Another frequent screw case >> is TLS proxies like bluecoat devices. >> >> >> But even in the simplest TLS use case, the TLS security context is >> really not exposed to the Web Server or the client in the way you >> would need to use it for Web Services authentication in the commonly >> used APIs. The problem is that TLS is designed to conceal all the >> complexity of crypto from the application. That is why it was called >> SSL at the start. >> >> >>> In one post you talked about sequencing and replay protection for >>> chunks. Adding that to the MAC really gets us close to the MIC token >>> features/design from RFCs 1964/4121 (Kerberos GSS mech). We're >>> talking about having a sequence number. As you say: this isn't >>> difficult; we've been doing this for a loooong time in Kerberos land. >> >> Heh, you could use a Kerberos token in my Omnibroker protocol if you >> wanted to. But since it is an opaque string of bytes as far as the >> client is concerned, well there is no reason to tie it to any one >> approach. >> >> People have been using kerberized cookies for years. The problem being >> that the cookie is not at all bound to the requests or responses. >> >>> Note that there's no need for sequence numbers to randomized given >>> that we have session keys, but sequence number windows add to the >>> state to be kept on the server side -- can we tolerate that? Note that >>> while session key state might be kept on the client in an encrypted >>> state ticket, session number windows cannot safely be kept that way -- >>> they must be kept locally. I tend to think that sequencing and replay >>> protection are the responsibility of the application -- all it needs >>> to do is add a sequence number to the chunks and manage its own >>> [per-resource] sequence number windows. >> >> The way I was thinking of helping the application was to provide a >> feature that allows Content-Integrity header to specify a key modifier >> as well as a ticket. The key used to calculate the MAC would then be >> the XOR of the modifier and the authentication key associated with the >> ticket. >> >> >>> Altogether we need: a session key identifier in the headers (this >>> should imply algorithm selection), a direction identifier (or separate >>> keys for each direction), a sequence number if we need sequencing >>> and/or replay detection, what content to MAC, and the MAC itself. >> >> Direction is already implicit in HTTP requests/responses. >> >> I don't think we need sequencing, we do need a modifier capability though. >> >>> Regarding what to MAC: the direction flag (unless we have diff keys >>> for each direction), the channel binding for the TLS channel (if we >>> have it), the URL?, some subset of headers? and the body. Note that >>> applying the MAC to any headers requires that we say something about >>> canonicalization (e.g., "use the headers exactly as sent") and >>> canonical order (if a subset of headers) (e.g., "in the relative order >>> of appearance"). Header and body content need to be unambiguously >>> separated in the MAC input. Obviously we can't MAC all headers: some >>> might be added by proxies, for example. >> >> I don't see the need to MAC any headers for a Web Service application. >> Put all the information in the content block. >> >> Otherwise we would have to do the sort of thing that DKIM does to sign >> headers and copy them. >> >> >> -- >> Website: http://hallambaker.com/ >> -- Website: http://hallambaker.com/
Received on Thursday, 12 July 2012 01:52:19 UTC