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

[Russ Housley <[e-mail]>]

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