Re: feedback on draft-ietf-httpbis-message-signatures-13
Anders Rundgren <anders.rundgren.net@gmail.com> Mon, 17 October 2022 10:48 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 96747C1524A8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 17 Oct 2022 03:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.762
X-Spam-Level:
X-Spam-Status: No, score=-7.762 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DK6Eh3w8dn1e for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 17 Oct 2022 03:48:07 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA67DC14F72F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 17 Oct 2022 03:48:06 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1okNcM-00EUO2-Ec for ietf-http-wg-dist@listhub.w3.org; Mon, 17 Oct 2022 10:45:10 +0000
Resent-Date: Mon, 17 Oct 2022 10:45:10 +0000
Resent-Message-Id: <E1okNcM-00EUO2-Ec@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <anders.rundgren.net@gmail.com>) id 1okNcL-00EUN3-AF for ietf-http-wg@listhub.w3.org; Mon, 17 Oct 2022 10:45:09 +0000
Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]) by titan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <anders.rundgren.net@gmail.com>) id 1okNcJ-00EQ4G-N7 for ietf-http-wg@w3.org; Mon, 17 Oct 2022 10:45:08 +0000
Received: by mail-wr1-x429.google.com with SMTP id f11so17800160wrm.6 for <ietf-http-wg@w3.org>; Mon, 17 Oct 2022 03:45:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=1I9I3aq7yaC40/brn21GDVuiUeDuX2P5A3BPUeeBMIs=; b=arJFcAIINFmYDStLDLw7DbC6JStCIJmhqnikPJzUJJtnHgdELq/MsjgyKdwoJnxuNn gIs3/WTG1VVOhHI1yxQjLqJ8m6EXn8/r7nsxczDUJdhbqnPa1EMQkOxzTH+4Wwqw4fbq nKe/VnqerHGxBkV7GXu9t7zKjb0KL2FsQCZ8qUhUtPo4NHMxpFXFyOqXJSKxNpB0e+DA GQOUg3a4pbLkxiRnFlNYmtlzl5GoJmHYZBMH13njmErbkhOfha6w7kvWRqnwJ/y68Q+J OPAQid1swEy3sMtJt10iSIkoe5Gecoc3mPt4WeOYTzGh0JfHDNtQfxEP2zUwqGiA8nP3 H46w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1I9I3aq7yaC40/brn21GDVuiUeDuX2P5A3BPUeeBMIs=; b=uHailz0QptTfoJmeduwznR6rE1O6083rPjozfuL+Zt3Q5DT6XyD+S7BSrDJFrO7ElH bUh6S5FJg7RThP4Z4czoTCfUDGU5XcON7y5FRoBTL8572yFyOdyZR9tHY13ghT1Jihk5 289d2NR+tT8KvF9Bv2dhHiMQhPOIjU4wO+SFiNryBJUrQr5MVbT8kthJct342p/EDh3K 04Kc6NC7PO0cIVOqvhM4iPuyI/uIRrhYYly/r/hlpuD7sUbu82mJIHeJ4ImGAQwLiQY2 Irk8FybZs30GflCs+WK1HSGxoUGWgvCdlHV/xA3e2Y6EyrRCRKrzlufQk6r/JBSl2IH9 1Bxg==
X-Gm-Message-State: ACrzQf172UbGY7pyjSt8GSz2ilNVMtSlnkTIjc7B9Js70flHW9jDVE6w 9ofsq3aAscculKT4iFAUNhpMNz731cU=
X-Google-Smtp-Source: AMsMyM5wa1u8nPrtXzf90fxKJ1xEpwAiutMM3/o+AB45++ryIczdR473x/HR1A3AKFQkZRubbHlxqg==
X-Received: by 2002:a05:6000:144d:b0:231:5786:f763 with SMTP id v13-20020a056000144d00b002315786f763mr5684635wrx.313.1666003496149; Mon, 17 Oct 2022 03:44:56 -0700 (PDT)
Received: from ?IPV6:2a01:e34:ec4e:5670:4c67:9df8:3c18:a7ca? ([2a01:e34:ec4e:5670:4c67:9df8:3c18:a7ca]) by smtp.googlemail.com with ESMTPSA id a21-20020a05600c2d5500b003b50428cf66sm9595539wmg.33.2022.10.17.03.44.53 for <ietf-http-wg@w3.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Oct 2022 03:44:54 -0700 (PDT)
Message-ID: <37363932-a747-8d28-0f6e-f3fedfcef7f4@gmail.com>
Date: Mon, 17 Oct 2022 12:44:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3
Content-Language: en-US
To: ietf-http-wg@w3.org
References: <CAD9ie-uvOK_-JxDjtZrPXGqdHUSYFNdKsaGKp6jNNhZB5bVXuA@mail.gmail.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
In-Reply-To: <CAD9ie-uvOK_-JxDjtZrPXGqdHUSYFNdKsaGKp6jNNhZB5bVXuA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=2a00:1450:4864:20::429; envelope-from=anders.rundgren.net@gmail.com; helo=mail-wr1-x429.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=anders.rundgren.net@gmail.com domain=gmail.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1okNcJ-00EQ4G-N7 bc6d09d7d11ec9065d081609835cfe67
X-Original-To: ietf-http-wg@w3.org
Subject: Re: feedback on draft-ietf-httpbis-message-signatures-13
Archived-At: <https://www.w3.org/mid/37363932-a747-8d28-0f6e-f3fedfcef7f4@gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40454
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: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
+1 Target URI and Method (as well as other data related to the message), may equally well be put in the payload. HTTP header signing is an unnecessary complication. Anders On 2022-10-16 23:56, Dick Hardt wrote: > Hello > > I have feedback on the positioning of HTTP Message Signatures, and am sharing some history on message signing. > > FWIW I do *not* plan to implement or support HTTP Message Signatures (presuming I have a choice) > > *Draft Feedback* > Section 1.4 > > "HTTP Message Signatures are designed to be a general-purpose security mechanism applicable in a wide variety of circumstances and applications. " > > > This is a very broad statement. While true, there is no guidance to an implementer when HTTP Message Signatures would be preferable to other signature mechanisms. For example, if one only needs to sign the payload, JOSE and COSE are widely deployed and available mechanisms to ensure message integrity, and have the added benefit of supporting message secrecy. > > The one use case where HTTP Message Signatures are differentiated from JOSE and COSE is that HTTP headers in addition to the payload can be signed. From what I glean from the examples, the @target-uri and @method seem to be the most interesting. (please add more examples if there are others!). These message attributes are often critical to a web API, and the desire to provide integrity of these attributes is clear as there the integrity of the client's intent is preserved through intermediaries -- or so would seem. > > There are a number of common deployment models where HTTP Message Signature will not preserve @target-uri as the @target-uri is different at the application server than what the client called. > > One of these is where a CDN such as CloudFront serves both static and dynamic content. The CDN routes requests that match certain paths to different hosts. For example when receiving a call to https://www.example.com/api/v1/* <https://www.example.com/api/v1/*> the CDN may proxy the call to https://v1.api.example.com/* <https://v1.api.example.com/*> > > Another is where messages are routed between microservices. A message router may route calls to https://www.example.com/api/v1/people/* <https://www.example.com/api/v1/people/*> to http://people <http://people> within the services network. > > In these two examples, using JOSE or COSE and including the @target-uri and @method values in the payload would provide the desired integrity protection, and optionally enable secrecy with end to end encryption. > > *Message Signing Experience* > > I provide the following stories as a cautionary tale on the challenges of message signing. > > Remember XML-DSig? I do. One of my ventures took on a consulting contract to write XML-DSig libraries for a number of popular languages. While the OSS libraries we shipped all worked -- the canonicalization was non-trivial and if I recall, there were a number of non-deterministic flows. I don't see XML-DSig used in the wild anymore besides SAML. > > OAuth 1.0 was another example of a painful message signing standard. The initial group did not want to require HTTPS -- so they sort of reinvented it. Despite the development of libraries to use, developers had challenges in getting it all working. I recall having code that called Twitter APIs (one of the last OAuth 1.0 holdouts) that would work intermittently depending on which one of the Twitter load balancers I hit. > > I led the design on what became OAuth 2.0 primarily because of the message signing concerns. The first requirement we agreed to was requiring HTTPS. > > My experience with XML-DSig and the messaging signing challenges of OAuth 1.0 were key inputs in the design work I did on what became JOSE. One of the first requirements was no canonicalization. Take the JSON string as is and base64url encode it. Done. > > /Dick > >
- feedback on draft-ietf-httpbis-message-signatures… Dick Hardt
- Re: feedback on draft-ietf-httpbis-message-signat… Anders Rundgren
- Re: feedback on draft-ietf-httpbis-message-signat… Julian Reschke
- Re: feedback on draft-ietf-httpbis-message-signat… Anders Rundgren
- Re: feedback on draft-ietf-httpbis-message-signat… Julian Reschke
- Re: feedback on draft-ietf-httpbis-message-signat… Anders Rundgren
- Re: feedback on draft-ietf-httpbis-message-signat… Backman, Annabelle
- Re: feedback on draft-ietf-httpbis-message-signat… Dick Hardt
- extension for feedback on draft-ietf-httpbis-mess… Henry Story
- CBOR versus HTTP Message Signature Anders Rundgren
- Re: CBOR versus HTTP Message Signature Justin Richer
- Re: CBOR versus HTTP Message Signature Anders Rundgren
- Re: CBOR versus HTTP Message Signature Justin Richer
- Re: CBOR versus HTTP Message Signature Anders Rundgren