feedback on draft-ietf-httpbis-message-signatures-13
Dick Hardt <dick.hardt@gmail.com> Sun, 16 October 2022 22:00 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 6DC0EC14F743 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 16 Oct 2022 15:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.758
X-Spam-Level:
X-Spam-Status: No, score=-2.758 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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 VzXa363pf_ZN for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 16 Oct 2022 15:00:19 -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 ADC59C1522D2 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 16 Oct 2022 15:00:19 -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 1okBdE-00D4b6-9G for ietf-http-wg-dist@listhub.w3.org; Sun, 16 Oct 2022 21:57:16 +0000
Resent-Date: Sun, 16 Oct 2022 21:57:16 +0000
Resent-Message-Id: <E1okBdE-00D4b6-9G@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 <dick.hardt@gmail.com>) id 1okBdD-00D4aE-6k for ietf-http-wg@listhub.w3.org; Sun, 16 Oct 2022 21:57:15 +0000
Received: from mail-yb1-xb2d.google.com ([2607:f8b0:4864:20::b2d]) by titan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <dick.hardt@gmail.com>) id 1okBdB-00E7BA-ED for ietf-http-wg@w3.org; Sun, 16 Oct 2022 21:57:14 +0000
Received: by mail-yb1-xb2d.google.com with SMTP id 126so11385637ybw.3 for <ietf-http-wg@w3.org>; Sun, 16 Oct 2022 14:57:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:reply-to:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=4l8g6dFZHlBeRPHsLgyYXpzkKVsbtKnem+TjHTxVxIY=; b=awdN2EY18PVLxm8W0LmUPASA1toRUfjgDEC2DQGmUGyJ+6UnkxTylDdL2Z+nZKNo3i hhmO9wlALbVdosCVzNKLIBsMGzu2aJRX0u7ohypvwIaQOfNIio6SXTqZhAdFe+tL1p4i Br+vNQU/I75joDy9x+2wo+jUMSnFx9H14hBSFcfoz5jC++wdFKFO5u9ExrNtT6W6Fogq sWDKHAVqfUe2289M7LR3IFhVfyX0aH/FsVRo2Idf7EHY3gmFejh5NGaLuaY8RXgwz5Ah Xqge3/PVFgaU4qPQYD/2kAW4h+9kLStdvdPkqxpxgFcfVmgfSXL30QyhQoQ4IaNJpX31 osuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4l8g6dFZHlBeRPHsLgyYXpzkKVsbtKnem+TjHTxVxIY=; b=5Cn6aJTyHGZeLWQeVLBuIp1Lhp6evxaetZCrbGc+sw5wCUN2lbDPYplaLtDkKQ7KMc 1orJR42gh2Z9LV4P/s34cqc+65AUEBPPbGtm7wAiVls5H5QjHE4hX1KtN/x+pts1vMpN BnCDTGYfLXg0v7Hwd0VWH66yo70fz1RUh8qqZ8D+0/xe6XgSLG9XsynUt5VakNU48EYE pt4AfgyIk8OHytmzmfOxh3SloOEHjeXgKb2s0IDfZIlOlqAo3NN02htjy+CqfPfy/bTo EYxdikcoV7UM7CdecyTZ1oFHvxZ9H2vKVIuPRpXcoHgWpvhQAIPk7jp01ejykE536dIU 24lA==
X-Gm-Message-State: ACrzQf0n29uXwxakeEisEBYl3trKYWP7b0VuHx4Kqt2Cd/tIyVOiow4G TMwo5wrNeAv+Uk5XoK+rKHwPonpzurxDnObSg7qR5mhVepM=
X-Google-Smtp-Source: AMsMyM4VnqueWpx62FDzk6DrlZC0iDUlBZODXhNYoTR/77Y90huuddKpEwrms9zX/q84I3D+i22KIo7dXXiXdC5CVW0=
X-Received: by 2002:a25:4fc2:0:b0:6be:afb4:d392 with SMTP id d185-20020a254fc2000000b006beafb4d392mr6411184ybb.604.1665957421749; Sun, 16 Oct 2022 14:57:01 -0700 (PDT)
MIME-Version: 1.0
Reply-To: Dick.Hardt@gmail.com
From: Dick Hardt <dick.hardt@gmail.com>
Date: Sun, 16 Oct 2022 14:56:25 -0700
Message-ID: <CAD9ie-uvOK_-JxDjtZrPXGqdHUSYFNdKsaGKp6jNNhZB5bVXuA@mail.gmail.com>
To: ietf-http-wg@w3.org
Cc: tpauly@apple.com, mnot@mnot.net
Content-Type: multipart/alternative; boundary="000000000000559c7a05eb2df05f"
Received-SPF: pass client-ip=2607:f8b0:4864:20::b2d; envelope-from=dick.hardt@gmail.com; helo=mail-yb1-xb2d.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=dick.hardt@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, HTML_MESSAGE=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 1okBdB-00E7BA-ED 55e3c758dcc8ab3af8b5c0abb203079f
X-Original-To: ietf-http-wg@w3.org
Subject: feedback on draft-ietf-httpbis-message-signatures-13
Archived-At: <https://www.w3.org/mid/CAD9ie-uvOK_-JxDjtZrPXGqdHUSYFNdKsaGKp6jNNhZB5bVXuA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40453
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>
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/* the CDN may proxy the call to 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/* to 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