Re: Content-Integrity header

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]

Received on Wednesday, 11 July 2012 21:37:06 UTC