Re: [Teep] OTrP Signature Security issue

On 2018-11-23 09:11, Hannes Tschofenig wrote:
> Hi Anders,
> 
> Ignoring the details of the OTrP, if you want to have an effective signature scheme you need to hash the messages parts you are interested in protecting. Then, you sign the hash value.
> 
> What makes some of the message signature schemes complex is that you the message parts may be in multiple places of the message (which then requires arranging them before hashing) and some message parts should not be included in the hashing process itself (since they may change in transit). This is, however, not the case with OTrP.
> 
> Did this answer your message? Did I miss the point?

Well...the point I raised is (IMO) pretty generic.

I don't think the argument would be affected by possible TEEP architectural changes unless they go very deep like using a "session" concept like my SKS/KeyGen2 system does.

Note: I didn't say that the OTrP signature scheme is flawed, I only introduced a MUST (which I believe is currently missing), as well as pointing to an alternative solution based on work-in-progress.

thanx,
Anders

> 
> Ciao
> Hannes
> 
> PS: FWIW we are still at a stage in TEEP where we are working our way through the architecture and hence I expect OTrP to change accordingly.
> 
> -----Original Message-----
> From: TEEP <teep-bounces@ietf.org> On Behalf Of Anders Rundgren
> Sent: Friday, November 23, 2018 7:55 AM
> To: teep@ietf.org
> Subject: Re: [Teep] OTrP Signature Security issue
> 
> Would it be possible getting a confirmation of my security analysis of the OTrP signature scheme?
> 
> That is, a complete signature validation MUST compare the outer (unsigned) object type ID with a mandatory inner (signed) counterpart like for the TAInformation/TAInformationTBS pair.
> 
> Note: This issue is not specific for OTrP; it applies to any system using outer level type IDs.  I only used OTrP as an example since my own designs (which had exactly the same problem), apparently weren't considered as representative.  I addressed this issue through JSON canonicalization since it supported several other use cases as well including a counter signature scheme only needing a hash a of JSON-formatted request.  The latter is completely out of scope for JOSE/COSE.
> 
> Anders
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
> https://mobilepki.org/jws-jcs
> 
> _______________________________________________
> TEEP mailing list
> TEEP@ietf.org
> https://www.ietf.org/mailman/listinfo/teep
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> 