Re: Content-Integrity header
Phillip Hallam-Baker <hallam@gmail.com> Fri, 06 July 2012 21:18 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE1B11E80F3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 6 Jul 2012 14:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.155
X-Spam-Level:
X-Spam-Status: No, score=-7.155 tagged_above=-999 required=5 tests=[AWL=3.444, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djtjx6veSzLW for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 6 Jul 2012 14:18:19 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 25DAE11E80F5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 6 Jul 2012 14:18:19 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1SnFtY-0002zZ-AC for ietf-http-wg-dist@listhub.w3.org; Fri, 06 Jul 2012 21:16:56 +0000
Resent-Date: Fri, 06 Jul 2012 21:16:56 +0000
Resent-Message-Id: <E1SnFtY-0002zZ-AC@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <hallam@gmail.com>) id 1SnFtF-0002y9-V1 for ietf-http-wg@listhub.w3.org; Fri, 06 Jul 2012 21:16:37 +0000
Received: from mail-ob0-f171.google.com ([209.85.214.171]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <hallam@gmail.com>) id 1SnFtE-0000EP-7D for ietf-http-wg@w3.org; Fri, 06 Jul 2012 21:16:37 +0000
Received: by obqv19 with SMTP id v19so2614587obq.2 for <ietf-http-wg@w3.org>; Fri, 06 Jul 2012 14:16:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i/wX5MStfTqJtcVmF+Qq2414JpPewH75eV+4r/bxq4w=; b=eCzv2uq5cqHACip6PhQFDBz4K68TTr+mSMX8+cVSHxXvz71QhJTmV7iLqXXZeaj0Nj N3eg2ndYDgE+ZhE4OQkA+hYi+2zSzWfqIZnDXUkBI0f2/JqsJAWGbhMl5qv/ZGFmdMuk Q7dX+mvihugxbHM7W681Cz00JmZjQw9k2hB/Rqv11zSr6o0Rv0KTRzXdtsPd6oRvt1Nz H0hlAwoOc9+DM2NC4ooX4maauQQKAhePywZ0ogJZPVYHAGkOZGM+KFp1NH9L5KDUkx+r 0NYWVNE7yIz6HfEHtHAuxtQRezDzvT/tAIJZ93mS6vuYLHg9svmhT7sM2Oq4w+WfGtvY +f2Q==
MIME-Version: 1.0
Received: by 10.60.12.37 with SMTP id v5mr641831oeb.25.1341609370566; Fri, 06 Jul 2012 14:16:10 -0700 (PDT)
Received: by 10.182.64.166 with HTTP; Fri, 6 Jul 2012 14:16:10 -0700 (PDT)
In-Reply-To: <6FAC5870-5A9D-48B0-9610-D5E6B3CBFA3B@gbiv.com>
References: <CAMm+LwhYqO0NFxW6BnreaWB0TEhpW8nAMMy2YzobC429CmtqPA@mail.gmail.com> <6FAC5870-5A9D-48B0-9610-D5E6B3CBFA3B@gbiv.com>
Date: Fri, 06 Jul 2012 17:16:10 -0400
Message-ID: <CAMm+Lwi3dq7H6_1JQDAX65aurw7dSnDLtvEqLhoENhc8fKHHWg@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: ietf-http-wg@w3.org
Content-Type: text/plain; charset="ISO-8859-1"
Received-SPF: pass client-ip=209.85.214.171; envelope-from=hallam@gmail.com; helo=mail-ob0-f171.google.com
X-W3C-Hub-Spam-Status: No, score=-2.7
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1SnFtE-0000EP-7D 04ecbc0114fb036c0d32b08a4c9377e1
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Content-Integrity header
Archived-At: <http://www.w3.org/mid/CAMm+Lwi3dq7H6_1JQDAX65aurw7dSnDLtvEqLhoENhc8fKHHWg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/14032
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
On Fri, Jul 6, 2012 at 4:02 PM, Roy T. Fielding <fielding@gbiv.com> wrote: > On Jul 6, 2012, at 11:43 AM, Phillip Hallam-Baker wrote: > >> HTTP 1.0 specifies a header Content-MD5. > > Actually, HTTP/1.1 (draft-ietf-http-v11-spec-02.txt, April 1995). > >> This is a bad header for all sorts of reasons, not least that the >> header was added despite the fact that I told people that MD5 had just >> been severely compromised. > > Compromised in 1995? I don't think so, and certainly not in a way > that would have effected a MIC for *accidental* modification > (which is all it was intended to be). Yes, Dobertin circulated his paper showing an initial collision result in private before the header was put in the spec. I remember arguing against the header before it was put in the spec knowing that it was broken. > It was never intended for > authentication because the field can be altered by an attacker > just as easily as the content. It is not intended for authentication but the ability to create collisions does have some very significant security consequences. >> In particular there is only one digest >> algorithm specified and no way to use others. > > Of course there is another way -- just define another field for > that algorithm. Defining a new content-sha256 (or whatever) field > is just as effective (and efficient) as trying to put all integrity > checks into a single field with an alg parameter. Moreover, the > new field definition could be used without worrying about all of > the broken implementations of poorly defined integrity checks > like content-md5. > >> A better approach would be: >> >> Content-Integrity: <base64-value> ;alg=<ID> > > That is another approach. It means that a recipient that only > understands alg A has to parse each content-integrity field-value > to look for a matching A parameter, as opposed to simply checking > for the presence of a content-A field. It has benefit if we expect > integrity checks to be performed by a multi-algo processor like > openssl, but is a nuisance if we expect only one or two algorithms > to be in common use at the same time. If you are using something like IIS where the header values are mapped to class members or attributes, adding a new header is a big deal, adding a parameter value is not. >> For many Web Services, what we would like to do is to specify a MAC >> rather than a digest and to use a preshared key identified by some >> form of kerberos-like ticket. We don't need to specify the internal >> structure of the ticket, just accept that we will have some sort of >> key exchange service interaction at the end of which the client ends >> up with a shared secret, an algorithm and an identifier that can be >> passed to the service where the interaction takes place: >> >> Content-Integrity: <base64-value> ;ticket=<ticket-data> >> >> Note that the method of establishing that ticket in the first place is >> out of scope for HTTP. Just think of it as something akin to a cookie. > > Why implement a MAC using the same field as a MIC? > Digital signatures are much harder to implement. This is not a Digital Signature. In fact repudiation is quite often an undesirable property. > Why don't the existing digital signature mechanisms suffice? > I know they haven't been deployed well for HTTP, but I don't know > why other than the expired patents and chicken/egg problems. Because they are digital signature mechanisms for a start. And that means they are tied to things like PKI that are really application layer not platform layer. > Why do you think a generic integrity check processor would want > to implement anything that complex? MACs are not complex, see Kerberos. > I agree that some common Dsig standard is needed, and that a good > way to do that is to simply assume that the shared key is already > known via other means, but I don't see any need to tie that to a > generic integrity check field when two different fields would be > easier to define, argue, and implement. One of the crossover cases is where a MAC is used with a specified key. This has some interesting properties as it allows a proof of knowledge of a content item to be established. For example, say we have a HEAD request that specifies a key to be used to calculate a MAC value. We have a lightweight means of seeing if the service actually stores the content it claims. > In any case, the hard part is deciding what content is included > in the hash. Sometimes folks want to include the whole representation > (as it exists at the source), others want to include only the payload > of the current message, and still others want the payload and some > odd set of header fields. And then we start talking about canonical > forms, and pretty soon we are just sick of arguing about it and ship > some gunk that doesn't actually solve a real problem. No, the content-integrity header would only cover the content and nothing else. That is why it is Content-Integrity and not 'Content-and-random-headers-Integrity. > Trying to do everything at once is a recipe for madness. Just pick > a very specific problem to solve, solve it the most efficient way > for that problem, and use a field name specific to the solution. > If it turns out to be useful beyond that, that's gravy. Then we end up with the detritus of everyone's legacy one-off solutions like Content-MD5. -- Website: http://hallambaker.com/
- Content-Integrity header Phillip Hallam-Baker
- Re: Content-Integrity header Poul-Henning Kamp
- Re: Content-Integrity header Roy T. Fielding
- Re: Content-Integrity header Phillip Hallam-Baker
- Re: Content-Integrity header Phillip Hallam-Baker
- Re: Content-Integrity header Phillip Hallam-Baker
- Re: Content-Integrity header James M Snell
- Re: Content-Integrity header Martin Thomson
- Re: Content-Integrity header Phillip Hallam-Baker
- Re: Content-Integrity header HAYASHI, Tatsuya
- Re: Content-Integrity header Amos Jeffries
- Re: Content-Integrity header Ludin, Stephen
- Re: Content-Integrity header Phillip Hallam-Baker
- Using HTTP Trailers [was: Content-Integrity heade… Mark Nottingham
- Re: Using HTTP Trailers [was: Content-Integrity h… James M Snell
- Re: Using HTTP Trailers [was: Content-Integrity h… Brian Pane
- Re: Using HTTP Trailers [was: Content-Integrity h… James M Snell
- Re: Content-Integrity header Yutaka OIWA
- Re: Using HTTP Trailers [was: Content-Integrity h… Zhong Yu
- Re: Using HTTP Trailers [was: Content-Integrity h… Wenbo Zhu
- Re: Content-Integrity header Phillip Hallam-Baker
- Re: Using HTTP Trailers [was: Content-Integrity h… Zhong Yu
- Re: Using HTTP Trailers [was: Content-Integrity h… Ludin, Stephen
- Re: Content-Integrity header Ludin, Stephen
- Re: Content-Integrity header Nico Williams
- Re: Using HTTP Trailers [was: Content-Integrity h… Zhong Yu
- Re: Content-Integrity header Phillip Hallam-Baker
- Re: Using HTTP Trailers [was: Content-Integrity h… Phillip Hallam-Baker
- Re: Content-Integrity header Nico Williams
- Re: Using HTTP Trailers [was: Content-Integrity h… Amos Jeffries
- Re: Using HTTP Trailers [was: Content-Integrity h… Zhong Yu
- Re: Using HTTP Trailers [was: Content-Integrity h… Amos Jeffries
- Re: Using HTTP Trailers [was: Content-Integrity h… Zhong Yu