From nobody Mon Jan 29 18:55:58 2018 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713ED1314D5; Mon, 29 Jan 2018 18:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L00bDtZGcJOm; Mon, 29 Jan 2018 18:55:54 -0800 (PST) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1251314E2; Mon, 29 Jan 2018 18:55:27 -0800 (PST) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0U2pxYl173146; Tue, 30 Jan 2018 02:55:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=to : from : subject : message-id : date : mime-version : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=E/y2jrj7lTuGf/iIr2gszyBn+fv08h01xXCiEa/g4pI=; b=eucs3qAo3PubYdiXZcTad4BczD9z6o/EV4galIioHSpGISoLlHJTWCyi/NavkiQh3TaI hFlVO5NeLYxYbyiXZ2WOlFPivu5o7gpY9QizclhzWdP4wM0cEIXhISwivfJaRgJICRpt yw20UjDg9wsptx4OnDzC+hDhLXJtDwuJQcDbz2YJSociWnbG9dfKVsnUjLKeX8iTZ6e1 ZnxHHbtXFI1yhCFcFIWnuSBoYWUKulLoG/HNQ2QRCeltbI02ERw8GDoJ9A0G2ghjYdEJ cE0eRMSLULGs8T0J9mtjn1KHyU/F1W63nFArOqjkr3zhndr1gNQe47FlPumxe2YRMRar Hg== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2ftfm5g3pg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 30 Jan 2018 02:55:25 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w0U2tPju015080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 30 Jan 2018 02:55:25 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w0U2tP29004245; Tue, 30 Jan 2018 02:55:25 GMT Received: from [172.19.129.2] (/216.146.45.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Jan 2018 18:55:25 -0800 To: draft-cavage-http-signatures@ietf.org, http-auth@ietf.org From: Richard Gibson Message-ID: <5d5d23b0-0947-ada6-a25e-5f521e6cace1@oracle.com> Date: Mon, 29 Jan 2018 21:55:23 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8789 signatures=668655 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801300035 Archived-At: Subject: [http-auth] Comment on "Signing HTTP Messages" X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 02:55:56 -0000 https://tools.ietf.org/html/draft-cavage-http-signatures-09#section-2.2 specifies the following: > If any of the parameters listed above are erroneously duplicated in the associated header field, then the last parameter defined MUST be used. This may expose a client security vulnerability for attacks analogous to HTTP header injection. Is there a compelling reason not to reject requests that specify the same parameter more than once? > Any parameter that is not recognized as a parameter, or is not well-formed, MUST be ignored. This will almost certainly limit future changes, since legacy clients won't implement desired behavior changes from new parameters _and_ will fail to signal that inability. Is there a compelling reason not to reject requests that specify unknown parameters? From nobody Tue Jan 30 08:54:19 2018 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E91120724; Tue, 30 Jan 2018 08:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjDw_jPz3_yY; Tue, 30 Jan 2018 08:54:14 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E961205D3; Tue, 30 Jan 2018 08:54:14 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id 143so2514826wma.5; Tue, 30 Jan 2018 08:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+Thzq0xXR2MZF6eZHdgcQJ0R35JhFHCLFT7HblxJVaw=; b=WnMrokl0d/Ru3EV2W2MDOqwKcr+kQbaEitquVuXCjy6niPxnLh4Ia8DBSvkjE69Yrx I6/6KpXQqzASySPtsz9rNhkAdwsq/jWu1yppnNaArVFQm1zvhZM1mYpB3EpjQ8fcTUNk v/Pzk4Fe5jWD9sEaXtkkffki7q/3y0NCKYPgo/cFQrPRzuoWXe2CXPEC99K2xl2Z72ce XhFrIUl7jjN/jjMgHErF3XjaeJg2CGqNT5qdxAfoi2HN68ofMecHFWYLyfUcLMDXQt7P kosYNCF6qXENai6hmjym8pBcBZGy4WqAoCfJXvfwwOYjdCBB1FcnmC1dvnoCjBX466eN qB3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+Thzq0xXR2MZF6eZHdgcQJ0R35JhFHCLFT7HblxJVaw=; b=nGKoJ0QpE/yGWtzWoXitSXLnFRJAcT5gHHlp8/OqTom8XszIzjLzCCgII/i9V/xIxF d3PbizMnDgEwsfg1wmhqYXqNHoPDxGRn5Aky7M7qM6eSLH+9xqriSKgY2kWc5aQnrg4a 5jTf8BcoUh8eBb01SgtJN3b3eYICB97nCu9MYvF7l13X8LKOM7t0bt3rmxjDiZfSpMD4 hi+wOBPfAWGUFzxjnWkmjEfz6RhCjbl7MUwUt91NlT4w8+qnqMzcPrJrxdh2X3IsUKRv v5Ky5ErvBbVC0WC2lKqa5bHCbvJUzFiOENZOSSjZMfoBRCpn8+JZhIG/2FxfQTYI+kr/ R/EA== X-Gm-Message-State: AKwxytc1wN3+UVOuYIXu0gVb5kzdTxD3jfcv+GREBVp/F7sh2/qkKXMl 271kebqrR1dJ7sfA7SAthN8= X-Google-Smtp-Source: AH8x225Hu2uX12yciGfQ7i1gjE0/4+M9s4e71dwIVAAaVEL2zs8a1xES5RJF427hOvKNMOEvevFbjw== X-Received: by 10.28.172.130 with SMTP id v124mr21781379wme.16.1517331252752; Tue, 30 Jan 2018 08:54:12 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id p12sm773692wre.83.2018.01.30.08.54.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jan 2018 08:54:11 -0800 (PST) From: Yoav Nir Message-Id: <980968C7-E802-4196-B363-BC288A520DCB@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_5EEA33A7-3C53-486B-AA09-514CEF470668"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 30 Jan 2018 18:54:08 +0200 In-Reply-To: <5d5d23b0-0947-ada6-a25e-5f521e6cace1@oracle.com> Cc: draft-cavage-http-signatures@ietf.org, http-auth@ietf.org To: Richard Gibson References: <5d5d23b0-0947-ada6-a25e-5f521e6cace1@oracle.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [http-auth] Comment on "Signing HTTP Messages" X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 16:54:17 -0000 --Apple-Mail=_5EEA33A7-3C53-486B-AA09-514CEF470668 Content-Type: multipart/alternative; boundary="Apple-Mail=_893A64E4-0820-4536-B2F5-EE7F78920D8C" --Apple-Mail=_893A64E4-0820-4536-B2F5-EE7F78920D8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Richard The http-auth mailing list is for the now-defunct working group = HTTP-Auth. The proper list for draft-cavage is the HTTP-bis WG mailing list: = ietf-http-wg@w3.org Yoav > On 30 Jan 2018, at 4:55, Richard Gibson = wrote: >=20 > = https://tools.ietf.org/html/draft-cavage-http-signatures-09#section-2.2 = specifies the following: >=20 > > If any of the parameters listed above are erroneously duplicated in = the associated header field, then the last parameter defined MUST be = used. >=20 > This may expose a client security vulnerability for attacks analogous = to HTTP header injection. Is there a compelling reason not to reject = requests that specify the same parameter more than once? >=20 > > Any parameter that is not recognized as a parameter, or is not = well-formed, MUST be ignored. >=20 > This will almost certainly limit future changes, since legacy clients = won't implement desired behavior changes from new parameters _and_ will = fail to signal that inability. Is there a compelling reason not to = reject requests that specify unknown parameters? >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth --Apple-Mail=_893A64E4-0820-4536-B2F5-EE7F78920D8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi, = Richard

The = http-auth mailing list is for the now-defunct working group = HTTP-Auth.

The = proper list for draft-cavage is the HTTP-bis WG mailing list: ietf-http-wg@w3.org

Yoav

On 30 = Jan 2018, at 4:55, Richard Gibson <richard.j.gibson@oracle.com> wrote:

https://tools.ietf.org/html/draft-cavage-http-signatures-09#sec= tion-2.2 specifies the following:

> = If any of the parameters listed above are erroneously duplicated in the = associated header field, then the last parameter defined MUST be = used.

This may expose a client security = vulnerability for attacks analogous to HTTP header injection. Is there a = compelling reason not to reject requests that specify the same parameter = more than once?

> Any parameter that is = not recognized as a parameter, or is not well-formed, MUST be = ignored.

This will almost certainly limit = future changes, since legacy clients won't implement desired behavior = changes from new parameters _and_ will fail to signal that inability. Is = there a compelling reason not to reject requests that specify unknown = parameters?

_______________________________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth

= --Apple-Mail=_893A64E4-0820-4536-B2F5-EE7F78920D8C-- --Apple-Mail=_5EEA33A7-3C53-486B-AA09-514CEF470668 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlpwozAACgkQuEkLFQpY zJnvUgf+IfepzGjrWRzsacuBKB/kEFzj1fEl3Vr3L6haHwIxQPtIZn5pipnemvVS dW7Urku8d05tyq7Vfqvb9eI2LL3jBbO4cXy3oWugRpcPg9GnvB+C8NP2jT+2BMlu 4xxUn6uQJRVXFGeOo9AV+GLVN7cCQJjGWiDpsBkFFZxIjiLKGyPiOSNP9tze0Gff rFHfZeb3yZbXyCAvwxwR02I9EMYjwT/hrMPB4YpxG5RZv6aUZSxeBZEQ/aJ8Ibaa /k7CfLRwMl2mifV7xTdyDkesxAcLDgVjkbn8BOnv8kuktapycIOkSvKI5iipor7s dROCkdKJXBS8ZVUhtMuLD24gNPIL7A== =b7NY -----END PGP SIGNATURE----- --Apple-Mail=_5EEA33A7-3C53-486B-AA09-514CEF470668--