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

[Klaus Hartke <[e-mail]>]

Hi Ben,

here's the next batch. Please see inline below.

Best regards,
Klaus


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?

>    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.

>       cause other any significant side effects.  For replay protection,
>       integrity protection is REQUIRED.
>
> I'm not entirely sure if the normative keyword is needed for effect, here;
> it's simply a fact that replay protection is impossible in the absence of
> integrity protection, isn't it?

Right. The intention here was to turn the "SHOULD integrity protect
the state information" from above into a "MUST". But I can lowercase
the "REQUIRED" or remove the sentence.

>    o  If processing a response without keeping request state is
>       sensitive to the time elapsed since sending the request, then the
>       serialized state SHOULD include freshness information (e.g., a
>       timestamp).
>
> Continuing the theme, this seems like a conditional MUST (not SHOULD).
> Actually, all the rest of the SHOULDs in this section do.

See above.

> This particular one should also note that the response processing needs to
> actually check the timestamp and reject ones that are insufficiently fresh.

I've made the following change (ignoring the SHOULD/MUST discussion):

OLD:

    If processing a response without keeping request state is
    sensitive to the time elapsed since sending the request,
    then the serialized state SHOULD include freshness
    information (e.g., a timestamp).

NEW:

    If processing a response without keeping request state is
    sensitive to the time elapsed since sending the request, then the
    client SHOULD include freshness information (e.g., a timestamp) in
    the serialized state and reject any response where the freshness
    information is insufficiently fresh.

> Also, integrity protection is again required for this to work.

Right. I think I'll remove the sentence "For replay protection,
integrity protection is REQUIRED." from above so that I don't have to
repeat it for every item. I think it's quite obvious.

> Section 5.2
>
>    The use of encryption, integrity protection, and replay protection of
>    serialized state is recommended, unless a careful analysis of any
>    potential attacks to security and privacy is performed.  [...]
>
> I suggest an alternative wording:
>
> % It is generally expected that the use of encryption, integrity protection,
> % and replay protection for serialized state is appropriate.  However, a
> % careful analysis of any potential attacks to the security and privacy
> % properties of the system might reveal that there are cases where such
> % cryptographic protections do not add value in a specific case.

Sounds good. Thanks!