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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 29 Sep 2020 13:45:33 -0700

Hi Klaus,

If I understand correctly, all the remaining discussion threads have come
to a resolution.  Can you prepare an updated I-D so that the
Discuss-holders can confirm on the final text, and the document proceed to
publication?

Thanks,

Ben

On Fri, May 08, 2020 at 07:01:28PM -0700, Benjamin Kaduk wrote:
> On Mon, May 04, 2020 at 07:40:39PM +0200, Klaus Hartke wrote:
> > 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?
> 
> I think so (for both cases), though some note about it being impossible to
> implement replay protection without integrity protection (while still
> avoiding per-request state) would probably still be in order.
> 
> Thanks,
> 
> Ben
>