Re: [core] I-D Action: draft-ietf-core-stateless-02.txt

[Thomas Fossati <[e-mail]>]

Hi Klaus,

On 22/10/2019, 12:08, "Klaus Hartke" <[e-mail]> wrote:
> Thomas Fossati wrote:
> > > The intention was to say: If the value is less than 8, then it shall
> > > be set to 8. If it's greater than 65804, then it shall be set to
> > > 65804. I though that's what clamping means, no?
> >
> > Sure, it's not "clamp" but the following "to be *within* this range"
> > that creates the ambiguity.
>
> So maybe just this?
>
>             The option value MUST NOT be less than 8 or greater than
>             65804.  When an option value outside this range is
>             received, the value MUST be clamped to this range.
>
> (I'm not a native speaker; help is appreciated.)

The poor soul version:

The option value MUST NOT be less than 8 or greater than 65804.  If
the received option has a value greater than 65804, then it MUST be
set to 65804.  If the received option has a value less than 8,
then it MUST be set to 8.

> > Thanks.  This is exactly what I meant by "dense": it looks like there is
> > an interesting amount of relevant information that is left implicit.  I
> > think articulating the assumptions as you just did will make it easier
> > on future readers.
> >
> > [...]
> >
> > The latter looks like a 4.xx to me.
>
> Like so?
>
>    If a server supports extended token lengths but receives a request
>    with a token of a length it is unwilling or unable to handle, it MUST
>    NOT reject the message, as that would imply that extended token
>    lengths are not supported at all.  Instead, if the condition is
>    temporary, it SHOULD return a 5.03 (Service Unavailable) response.
>    If the condition is permanent,

     such as when the client is sending a large token that the server
     will never be able to handle,

>    it SHOULD return a 4.00 (Bad Request)
>    response.
>
>    Design Note:  The requirement to return an error response when a
>       request cannot be handled might seem somewhat contradictory.
>       However, handling a request usually involves a number of steps
>       from receiving the message to handing it over to application
>       logic.  The idea is that a server implementing this document at
>       least should support large tokens in the first few steps (enough
>       to return an error response rather than a Reset message).

Looks great, thanks.

Cheers, t

PS: I couldn't find the Github repo, so I'm sticking here what I'd have
    written there:

Unfortunately, it is easy to misuse counter mode.  If counter block
values are ever used for more than one encryption operation with the
same key then the same key stream will be used to encrypt both
plaintexts and the confidentiality guarantees are voided. Devices with
low-entropy sources -- as is typical with constrained devices, which
incidentally happen to be a natural candidate for the stateless
mechanism described in this document -- need to carefully pick a nonce
generation mechanism that provides the above uniqueness guarantee.
Besides, since it can be extremely difficult to use AES-CCM securely
when using statically configured keys, implementations SHOULD use
automated key management [BCP107].

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.