Re: [GNAP] Summarizing status from SECDIR IETF LC review of draft-ietf-gnap-core-protocol-16

[Justin Richer <[e-mail]>]

That’s fair, I can back that out. I knew that it dealt with both digital signatures and MACs, but I agree that it presents a much different environment so the discussion isn’t the same.

Thanks.

— Justin

On Feb 9, 2024, at 1:58 PM, Russ Housley <[e-mail]> wrote:

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’s 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’s 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’s in the HTTP Message Signatures spec introduction, which I’ve added in this PR:

https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/528

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’ve 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