- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Wed, 11 Jul 2012 18:35:02 -0400
- To: "Ludin, Stephen" <sludin@akamai.com>
- Cc: Yutaka OIWA <y.oiwa@aist.go.jp>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
A message digest should be more than sufficient for detecting non-malicious modification. But it turns out that we already have a header for that. Still, it makes good sense to look at both together as I don't think the Integrity header has had as much play as it deserves and adding in a MAC capability (separate or same header) will stir up much of the same muck. On Wed, Jul 11, 2012 at 5:36 PM, Ludin, Stephen <sludin@akamai.com> wrote: > > > On 7/10/12 10:04 PM, "Yutaka OIWA" <y.oiwa@aist.go.jp> wrote: > >>P.S. >>As a personal feeling, the value of integrity protection on >>this moment is more on protection against intentional content-forging >>attacks, rather than unintentional communication failure >>(except premature termination of streams). >>To this extent, re-requesting the broken chunk is personally out of >>my interest. This may need discussion, because it may affect >>the design of inter-chunk chaining of integrity signatures. > > This was where I started when I began looking into corruption issues in > downloaded objects. What we discovered is that in a large enough sample > size, such as what we see at Akamai, random bit shifting that manages to > still get by the TCP chucksum happens regularly enough this feature is of > high interest. I actually see this as relatively useless for content > forgery cases because, as mentioned elsewhere in this thread, the forger > would probably simply change the digest to match the forgery. The > digesting feature in general is an act-of-nature (or act of bad hardware / > software) detection mechanism, and building in an efficient recover > mechanism seem to be a reasonable step. > > -stephen > > >> >>2012/7/11 Ludin, Stephen <sludin@akamai.com>: >>> I really like the idea of placing the Digest in the chunk trailers. >>>Being >>> able to calculate these digests on the fly and not buffer the entire >>> message is critical in my opinion. >>> >>> Another concept that I have been playing with is providing digests on >>> individual chunks using chunk-extension. The rational for this is for >>> very large objects. With per-chunk digests the client would have the >>> ability to re-request a specific corrupted section of an object using a >>> range request rather than the entire object. This can have enormous >>> perceived performance and reliability benefits for consumers of things >>> such as software download and large media files. >>> >>> I was working on a draft to propose this, but I didn't feel it was well >>> baked enough to share. If there is interest in this type of >>>functionality >>> I will polish it up and post it. >>> >>> One issue to point is is that for these types of "frame" based integrity >>> checks I generally feel like we are reinventing the content integrity >>> portion of SSL/TLS. Though I see the value in begin able to do this >>>apart >>> from SSL it forces the question at what point do you just switch over to >>> SSL to get the desired functionality? >>> >>> -stephen >>> >>> >>> >>> On 7/9/12 4:00 PM, "Amos Jeffries" <squid3@treenet.co.nz> wrote: >>> >>>>On 10.07.2012 07:08, HAYASHI, Tatsuya wrote: >>>>> +1 >>>>> >>>>> I know that this is demanded. >>>>> When I discussion about http-authentication and phishing, >>>>> it is requested by many people. >>>>> It is a difficult problem. >>>>> ex) proxy... >>>>> >>>>> I think that it is good to do this discussion now. >>>>> >>>>> --- >>>>> Tatsuya >>>>> >>>>> On Sat, Jul 7, 2012 at 8:23 AM, James M Snell wrote: >>>>>> In general, I'm +1 on the general idea albeit with a few caveats... >>>>>> >>>>>> 1. To minimize complexity, only a single Content-Integrity header >>>>>> should be used. I don't want, as Roy points out, to have to iterated >>>>>> through a bunch of unsupported header values looking for the one I >>>>>> want. Just as it makes very little sense for an implementor to >>>>>> provide >>>>>> multiple Last-Modified, Etag and Content-Type headers in a single >>>>>> message; there should be only a single Content-Integrity statement >>>>>> and >>>>>> I either understand it or I don't. >>>> >>>>Either the client advertises what it supports (opening itself to >>>>middleware erasing options they can't modify). Or the server uses >>>>multiple algorithms in hopes that the middleware cannot violate them >>>>all. >>>>It makes perfect sense to have several levels of integrity check. MD5, >>>>SHA1, AES in one response and allow the client to validate the strongest >>>>it can handle. >>>> >>>>There is also an arguable case for middleware wanting to add its own >>>>hash to inform the client essentially "this is what I got given". So the >>>>point of manipulation can be back-traced when the more secure end-to-end >>>>checks fail. >>>> >>>>If you want end-to-end integrity, don't stop at half measures. >>>>Particularly at half measures which can be corrupted. >>>> >>>> >>>>>> >>>>>> 2. The performance impact of calculating the digest needs to be >>>>>> carefully considered. I'd rather not be required to buffer a full >>>>>> representation in memory all the time just to calculate a header >>>>>> value. I know it's largely unavoidable, but perhaps there's some >>>>>> currently elusive solution that can be considered. For instance.. >>>>>> allowing Content-Integrity to appear as a trailer at the end of a >>>>>> chunked response. >>>> >>>>As has been said Trailers happen here. >>>> >>>>>> >>>>>> 3. Something needs to be said about what happens if the >>>>>> Content-Integrity check fails. For instance, if a request containing >>>>>> Content-Integrity is sent to the server and the server detects that >>>>>> the signature is invalid, what should happen? what must happen? >>>>>> Likewise, how are intermediaries expected to treat the >>>>>> Content-Integrity header given that any intermediary is able to >>>>>> modify >>>>>> the payload at any time? >>>> >>>>This is going to be most useful on request/responses sent with >>>>"no-transform" of course. >>>> If the integrity was only a MD5 or SHA1 hash which middleware can edit >>>>easily there is no end-to-end integrity, just hop-by-hop integrity. >>>> >>>> >>>>Also, there has to be a mutual secret between origin server and client. >>>>Without that, when integrity is compromised the transforming hop will >>>>simply erase or replace the Content-Integrity header value. A secret key >>>>unknown to that middleware is required to make the integrity hash break >>>>when it tries this. >>>> >>>>AYJ >>>> >>> >>> >> >> >> >>-- >>Yutaka OIWA, Ph.D. Leader, Software Reliability Research >>Group >> Research Institute for Secure Systems (RISEC) >> National Institute of Advanced Industrial Science and Technology (AIST) >> Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp> >>OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 >>46B5] > > -- Website: http://hallambaker.com/
Received on Wednesday, 11 July 2012 22:35:30 UTC