From housley@vigilsec.com Fri Feb 9 10:59:09 2024 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31DFC14F690 for ; Fri, 9 Feb 2024 10:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no 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 KNLmqmIqgirY for ; Fri, 9 Feb 2024 10:59:07 -0800 (PST) Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0258C14F610 for ; Fri, 9 Feb 2024 10:59:07 -0800 (PST) Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id B3EE71239A4; Fri, 9 Feb 2024 13:59:06 -0500 (EST) Received: from smtpclient.apple (unknown [96.241.2.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 9CFD01238D8; Fri, 9 Feb 2024 13:59:06 -0500 (EST) From: Russ Housley Message-Id: <264AA826-1353-4F10-947A-4740DBD18D9E@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_60212AA7-3081-4B4E-89CF-FE1AD534562E" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Date: Fri, 9 Feb 2024 13:58:56 -0500 In-Reply-To: Cc: "Roman D. Danyliw" , "txauth@ietf.org" To: Justin Richer References: <05C47833-3C63-4588-B9BB-8FB1673F68FD@mit.edu> <348E9604-64C9-4281-8A32-23C9A08C5E22@vigilsec.com> <228DFDD9-EF1D-4D7C-BDBF-3B1914E8BBCA@mit.edu> X-Mailer: Apple Mail (2.3731.700.6) X-Scanned-By: mailmunge 3.11 on 66.39.134.11 Archived-At: Subject: Re: [GNAP] Summarizing status from SECDIR IETF LC review of draft-ietf-gnap-core-protocol-16 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2024 18:59:10 -0000 --Apple-Mail=_60212AA7-3081-4B4E-89CF-FE1AD534562E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Justin: >>=20 >>>>>> ** (Russ on -16) Section 7: Please consider a reference to RFC = 4107. I'm not sure where >>>>>> in this section is the best place to add a cite. >>>>>>=20 >>>>>> [Roman] -16 already contained a reference to RFC4107 in Section = 13.7. The discussion thread seems to indicate that additional pointers = would be added in a version after -16. I don't see it. >>>>>=20 >>>>> It seemed to make more sense to keep the reference in the security = considerations section as opposed to making a reference to it (normative = or otherwise) in the client-signing section (7). Yes, clients and AS=E2=80= =99s need to manage and store their keys well. But the thrust of section = 7 is how those are presented on the wire and used to bind request = messages to keys, not how the keys themselves are managed. There=E2=80=99s= already a forward reference to the security section that mentions = RFC4107 in section 7, so we felt that was sufficient. >>>>=20 >>>> I really dislike the notion of a symmetric key being used for = "signing". In my view, digital signatures require asymmetric = cryptography. Is there a way to avoid this in the first paragraph of = Section 13.7. >>>=20 >>> I think we can add same definitions paragraph that=E2=80=99s in the = HTTP Message Signatures spec introduction, which I=E2=80=99ve added in = this PR: >>>=20 >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/528 >>=20 >> Thanks. I'd like to see a sentence or two about the difference in = the security service offered by a MAC. RFC 5652 has these words that = capture my point: >>=20 >> When more than two parties share the same message-authentication = key, >> data origin authentication is not provided. Any party that knows = the >> message-authentication key can compute a valid MAC; therefore, the >> contents could originate from any one of the parties. >>=20 >> You might also want to say that MAC computation is oftem much more = efficient than an asymmetric digital signature. >>=20 >> With these two points, an implementer gets the information to decide = which type of algorithm to use. >>=20 >=20 > I=E2=80=99ve adapted the text and reference into the security = consideration on symmetric cryptography, in the above PR. Thank you for = the reference!=20 >=20 > The section already had a note about performance, so I think this is = the only addition we needed. One nit: I do not thisn you want to reference CMS [RFC5652] here. The = overall protocol environment is quite different. Russ --Apple-Mail=_60212AA7-3081-4B4E-89CF-FE1AD534562E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Justin:


** (Russ on -16) Section 7: Please consider a reference to RFC = 4107.  I'm not sure where
in this section is the best place to add a cite.

[Roman] -16 already contained a reference to RFC4107 in Section 13.7. =  The discussion thread seems to indicate that additional pointers = would be added in a version after -16.  I don't see it.

It seemed to make more sense to keep the reference in the security = considerations section as opposed to making a reference to it (normative = or otherwise) in the client-signing section (7). Yes, clients and AS=E2=80= =99s need to manage and store their keys well. But the thrust of section 7 is how those are presented on the wire and = used to bind request messages to keys, not how the keys themselves are = managed. There=E2=80=99s already a forward reference to the security = section that mentions RFC4107 in section 7, so we felt that was sufficient.

I really dislike the notion of a symmetric key being used for "signing". =  In my view, digital signatures require asymmetric cryptography. =  Is there a way to avoid this in the first paragraph of Section = 13.7.

I think we can add same definitions paragraph that=E2=80=99s in the = HTTP Message Signatures spec introduction, which I=E2=80=99ve added in = this PR:


Thanks.  I'd like to see a sentence or two about the difference in = the security service offered by a MAC.  RFC 5652 has these words = that capture my point:

   When more than two parties share the same = message-authentication key,
   data origin authentication is not provided.  Any = party that knows the
   message-authentication key can compute a valid MAC; = therefore, the
   contents could originate from any one of the = parties.

You might also want to say that MAC computation is oftem much more = efficient than an asymmetric digital signature.

With these two points, an implementer gets the information to = decide which type of algorithm to use.


I=E2=80=99ve adapted the text and reference into the security = consideration on symmetric cryptography, in the above PR. Thank you for = the reference! 

The section already had a note about performance, so I think this = is the only addition we needed.

One nit:  I do not thisn you = want to reference CMS [RFC5652] here.  The overall protocol = environment is quite = different.

Russ

= --Apple-Mail=_60212AA7-3081-4B4E-89CF-FE1AD534562E--