Subject: [COSE] Replay Protection

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 1 Oct 2015 09:58:10 +0200

Hi all,

currently there are no fields that help with reply protection in the
COSE specification (although in practice with other protocols the nonce
will be re-purposed as a sequence number field).

I was wondering whether others in the group thought it would be useful
to add a sequence number and a timestamp field to the header parameter
registry for those applications that do not want to use the externally
supplied data capability for providing replay protection.

Ciao
Hannes

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 1 Oct 2015 21:39:49 -0700

I think this would be useful, but would like to see some details on what should be there.

For timestamp - what format of timestamp should be used.

For replay protection - do you need just a nonce, or to do you think we need the full set of three values:  Transaction ID, Sender Nonce, Recipient Nonce?

Jim

> -----Original Message-----
> From: COSE [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Thursday, October 01, 2015 12:58 AM
> To: [email-masked]
> Subject: [COSE] Replay Protection
> 
> Hi all,
> 
> currently there are no fields that help with reply protection in the COSE
> specification (although in practice with other protocols the nonce will be re-
> purposed as a sequence number field).
> 
> I was wondering whether others in the group thought it would be useful to add a
> sequence number and a timestamp field to the header parameter registry for
> those applications that do not want to use the externally supplied data capability
> for providing replay protection.
> 
> Ciao
> Hannes
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 2 Oct 2015 05:07:59 +0000

The answer is very much "it depends".  Different applications need different kinds of replay protection.  That's why this field should be part of the application payload and defined by the application - not part of the cryptographic envelope.

				-- Mike

-----Original Message-----
From: COSE [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Thursday, October 01, 2015 9:40 PM
To: 'Hannes Tschofenig'; [email-masked]
Subject: Re: [COSE] Replay Protection

Jim

> COSE specification (although in practice with other protocols the 
> nonce will be re- purposed as a sequence number field).
> 

_______________________________________________
COSE mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40microsoft.com%7c4806246199e746df6c1d08d2cae3dde2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=oYaVCwskkw32KHv3%2bFI7T7EaP9%2fKAJaf9arHSCnOVks%3d

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 3 Oct 2015 13:14:38 -0700

Hannes,

I have been thinking a bit about the concept of timestamp.  When you say this, do you mean a creating time rather than a third party timestamp?  If you are looking at something other than a statement of creation time, what would it be?

Jim

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 04 Oct 2015 04:15:23 +0200

The TCG "TPM_CURRENT_TICKS"/"TickStampBlob" [sic] is one time stamp that
is not dependent on real time (which a constrained node may not have
available to it):

Tick Count Value (TCV) – The count of ticks for the session.
Tick Increment Rate (TIR) – The rate at which the TCV is incremented.
There is a set relationship between TIR and seconds, the relationship is
set during manufacturing of the TPM and platform. This is the
TPM_CURRENT_TICKS -> tickRate parameter.
Tick Session Nonce (TSN) – The session nonce is set at the start of each
tick session.

(I don't think we need the TIR.)

Grüße, Carsten

Jim Schaad wrote:
> https://www.ietf.org/mailman/listinfo/cose
>

---

From: Göran Selander <[email-masked]>
Date: Sun, 4 Oct 2015 08:45:59 +0000

> On 1 okt. 2015, at 09:59, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
> 

I think there should be a compact way of representing at least sequence numbers. Considering the various candidates I would say that nonces and timestamp are of less general applicability for the most constrained settings, which is where the need for a very compact message matters. 

Göran

---

From: Mike Jones <[email-masked]>
Date: Sun, 4 Oct 2015 18:13:07 +0000

The fact that we're even having a discussion about what the best content for the sequence number/timestamp is means that there are multiple good choices and that applications will want to use the choice appropriate to the application's needs.  That's why this information should be part of the application payload - not part of the cryptographic wrapper.

I think part of why this is coming up is that we don't have a CBOR spec for defining standard application payload content elements like we did for JOSE.  For JOSE, the cryptographic content is defined in JWS, JWE, JWK, and JWA [RFCs 7515-7518].  Whereas, standard application content appropriate for some contexts was defined by the JSON Web Token spec [RFC 7519].  There isn't an equivalent to JWT for CBOR at present.  I think that's behind part of the urge to jam things into the COSE headers - since we haven't defined a right place to put them in the application payload.

				My 2¢ worth…
				-- Mike

-----Original Message-----
From: COSE [mailto:[email-masked]] On Behalf Of Göran Selander
Sent: Sunday, October 04, 2015 1:46 AM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [COSE] Replay Protection

> nonce will be re-purposed as a sequence number field).
> 

Göran

> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> etf.org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40mic
> rosoft.com%7ce6e977e21bdb46388edb08d2cc983ef2%7c72f988bf86f141af91ab2d
> 7cd011db47%7c1&sdata=bUvJjpCSj4sEaxiL86yq88eekIh9wyKzEKZSd7PGLEo%3d

---

From: Göran Selander <[email-masked]>
Date: Thu, 8 Oct 2015 07:20:40 +0000

On 2015-10-04 20:13, "Mike Jones" <[email-masked]> wrote:

>The fact that we're even having a discussion about what the best content
>for the sequence number/timestamp is means that there are multiple good
>choices and that applications will want to use the choice appropriate to
>the application's needs.  That's why this information should be part of
>the application payload - not part of the cryptographic wrapper.

So far when we discussed replay protection for the most constrained
devices no one has disagreed with sequence number being a good measure in
general. I’m thinking of devices which sleep almost always to save energy
and where storing and searching through large amounts of nonces is not an
option. As an additional benefit a counter starting from 0 encoded in CBOR
incurs most of the time less transmission overhead than a nonce or a
timestamp would do.

There are cases where synchronised time is available and where you could
potentially use integrity protected timestamp for other things than just
replay protection, like in the 6tisch setting. But as far as I understand
there is also a concern about message size and just for replay protection
sequence numbers could be appropriate in that case too.

So the claim is not that you MUST use sequence numbers, but that in cases
where an optimized format is most needed is where the use of sequence
numbers is the most feasible method for replay protection.

I would be happy to stand corrected here to learn when this assumption is
wrong. 

If not, whether this would go into the message specification or become a
"COSE profile” of some sort is another question.

Göran

>
>I think part of why this is coming up is that we don't have a CBOR spec
>for defining standard application payload content elements like we did
>for JOSE.  For JOSE, the cryptographic content is defined in JWS, JWE,
>JWK, and JWA [RFCs 7515-7518].  Whereas, standard application content
>appropriate for some contexts was defined by the JSON Web Token spec [RFC
>7519].  There isn't an equivalent to JWT for CBOR at present.  I think
>that's behind part of the urge to jam things into the COSE headers -
>since we haven't defined a right place to put them in the application
>payload.
>
>				My 2¢ worth…
>				-- Mike
>
>I think there should be a compact way of representing at least sequence
>numbers. Considering the various candidates I would say that nonces and
>timestamp are of less general applicability for the most constrained
>settings, which is where the need for a very compact message matters.
>
>Göran
>
>> 
>> Ciao
>> Hannes
>> 
>>

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 9 Oct 2015 13:42:28 -0700

When we are saying that we want to do "replay detection", exactly what are we talking about? 

1.  I want to detect if this is the same as the last (n) message(s) that I processed.

2.  I want to detect if this message was "sent" before the last message I processed.

3.  Some message of both - please expand.

4.  Something entirely different.

Jim

> Sent: Thursday, October 08, 2015 12:21 AM
> To: Mike Jones <[email-masked]>; Hannes Tschofenig
> <[email-masked]>
> Cc: [email-masked]
> >The fact that we're even having a discussion about what the best
> >content for the sequence number/timestamp is means that there are
> >multiple good choices and that applications will want to use the choice
> >appropriate to the application's needs.  That's why this information
> >should be part of the application payload - not part of the cryptographic
> wrapper.
> 
> So far when we discussed replay protection for the most constrained devices no
> one has disagreed with sequence number being a good measure in general. I’m
> thinking of devices which sleep almost always to save energy and where storing
> and searching through large amounts of nonces is not an option. As an
> additional benefit a counter starting from 0 encoded in CBOR incurs most of the
> time less transmission overhead than a nonce or a timestamp would do.
> 
> potentially use integrity protected timestamp for other things than just replay
> protection, like in the 6tisch setting. But as far as I understand there is also a
> concern about message size and just for replay protection sequence numbers
> could be appropriate in that case too.
> 
> If not, whether this would go into the message specification or become a "COSE
> profile” of some sort is another question.
> 
> 
> 
> Göran
> 
> 
> >
> >appropriate for some contexts was defined by the JSON Web Token spec
> >[RFC 7519].  There isn't an equivalent to JWT for CBOR at present.  I
> >think that's behind part of the urge to jam things into the COSE
> >headers - since we haven't defined a right place to put them in the
> >application payload.
> >
> >				My 2¢ worth…
> >				-- Mike
> >
> >> On 1 okt. 2015, at 09:59, Hannes Tschofenig
> >><[email-masked]>
> >>wrote:
> >>
> >> Hi all,
> >>
> >> I was wondering whether others in the group thought it would be
> >> useful to add a sequence number and a timestamp field to the header
> >> parameter registry for those applications that do not want to use the
> >> externally supplied data capability for providing replay protection.
> >
> rosoft.com%7ce6e977e21bdb46388edb08d2cc983ef2%7c72f988bf86f141af91a
> b2
> >> d

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 12 Oct 2015 10:00:18 +0200

> 1.  I want to detect if this is the same as the last (n) message(s) that I processed.

Something like that, but rather "I want to detect if this is a message I 
already processed, or if I have processed a significant number of 
messages with higher sequence numbers".

The idea is detailed in RFC 6347 section 4.1.2.6

When the sequence number space wraps, we do a rekeying so that all old 
messages become invalid.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Göran Selander <[email-masked]>
Date: Tue, 13 Oct 2015 07:28:46 +0000

On 2015-10-09 22:42, "Jim Schaad" <[email-masked]> wrote:

>When we are saying that we want to do "replay detection",

I probably missed the point but let me make a try:
Is the term "replay detection” used to signify that it is left to the
application to actually perform the processing encompassing "replay
protection” (i.e. dropping message with recurring sequence number). This
in contrast to “integrity protection" where the COSE message format/cipher
suite defines the processing. (Or if not, why don’t we also speak of
"integrity detection”?)

>exactly what are we talking about?
> 
>

I think this is application dependent. Ludwig pointed at one scheme. Other
applications may require strict monotonicity, e.g. when the latest message
obsoletes previous.

Göran

>>devices no