Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-stateless-06: (with DISCUSS and COMMENT)

[Klaus Hartke <[e-mail]>]

Benjamin Kaduk wrote:
> Klaus Hartke wrote:
> > Benjamin Kaduk wrote:
> > > Section 3.1
> > >
> > >    o  A client SHOULD integrity protect the state information serialized
> > >       in a token, unless processing a response does not modify state or
> > >       cause any other significant side effects.
> > >
> > > If the intent is that the "does not modify state" clause is the only case
> > > when one would disregard the need for integrity protection, "MUST [...]
> > > unless" seems more appropriate.  (I would prefer unconditional MUST and am
> > > not sure I understand the cases where there is a need to skip integrity
> > > protection.)
> >
> > The intent here is that a client must do integrity protection, but
> > there may exist valid reasons in particular circumstances to ignore
> > this requirement. In this case, the full implications must be
> > understood and carefully weighed.
> >
> > All of the circumstances that come to my mind here are those where a
> > modified token doesn't actually hurt. For example, if a client sends a
> > request to some server at regular intervals, it might only be
> > interested in whether the response has an error or success code and
> > not even deserialise the token.
> >
> > What's the best way to capture this?
>
> Before I get into suggested text, I want to check that I understand the
> situation properly -- in such a case where the client is not even
> deserializing the token, why would the client not be able to use a regular
> token and not look at that token's value?  It doesn't seem like the client
> is gaining anything from having the serialized state available.
>
> Your description makes it sound like we may have to just do "SHOULD
> integrity protect" without the "unless [...]" clause.

Hmm... the top-level section is about clients that avoid keeping
per-request state, which a client can be regardless of whether it uses
<=8 byte tokens or >8 byte tokens; but this sub-section talks about
serialized state, from which indeed the client doesn't get anything if
it's never deserialized...

Maybe the best way forward is indeed to use SHOULD with the "unless
[...]" part... If we change to MUST, then I can already anticipate
people complaining that in their particular use case any integrity
protection is just wasting precious bytes. The SHOULD would take care
of that. And maybe we don't have to go into detail under which
circumstances it might be justified to ignore this SHOULD.

OLD:

   o  A client SHOULD integrity protect the state information serialized
      in a token, unless processing a response does not modify state or
      cause any other significant side effects.

NEW:

   o  A client SHOULD integrity protect the state information serialized
      in a token.

> > >    o  Even when the serialized state is integrity protected, an attacker
> > >       may still replay a response, making the client believe it sent the
> > >       same request twice.  For this reason, the client SHOULD implement
> > >
> > > (Basically the same comments about "SHOULD".)
> >
> > See above.
> >
> > This section is about protecting the serialized state, but of course
> > the requests and responses need to be protected as a whole as well
> > (e.g., using DTLS or OSCORE). In some circumstances, receiving a
> > replayed token might not hurt if the client can verify that the
> > response is coming from the right server.
>
> Presumably the same cases where a replayed response from the right server
> would be tolerable?  Such cases are ... rare, in my opinion.

OLD:

   o  Even when the serialized state is integrity protected, an attacker
      may still replay a response, making the client believe it sent the
      same request twice.  For this reason, the client SHOULD implement
      replay protection (e.g., by using sequence numbers and a replay
      window), unless processing a response does not modify state or
      cause other any significant side effects.  For replay protection,
      integrity protection is REQUIRED.

NEW:

   o  Even when the serialized state is integrity protected, an attacker
      may still replay a response, making the client believe it sent the
      same request twice.  For this reason, the client SHOULD implement
      replay protection (e.g., by using sequence numbers and a replay
      window).

Does it look OK without the "unless [...]" parts?

Klaus