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

[Thomas Fossati <[e-mail]>]

Hi Klaus,

On 22/10/2019, 11:10, "Klaus Hartke" <[e-mail]> wrote:
> >   When an option value outside this range is received, the value MUST be
> >   clamped to be within this range.
> >
> > I find this sentence slightly difficult to action: it doesn't say which
> > value should the receiver pick in case of {over,under}flow -- is it one
> > of RANGE_MAX / RANGE_MIN (whatever the closest) or some arbitrary value
> > within [RANGE_MIN, RANGE_MAX] ?  A bit more clarity would help.
>
> 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.

> > Tangentially, I don't see a good reason why the receiver should silently
> > accept out-of-range values from the peer?  I appreciate that the
> > effective TKL is constrained anyway, but my preference would be to fail
> > with an explicit signal.
>
> The rationale is different for the two cases:
>
> If the server indicates it can handle tokens up to 5 MiB, then the
> client cannot send a 5 MiB token, because the maximum length supported
> by the message format is 65804. But if a server can handle tokens up
> to 5 MiB, then it clearly also can handle tokens up to 65804 bytes,
> right? So there's not really an error if a server indicates a value
> greater than what can actually be sent.
>
> If the server can only handle tokens of some length that is less than
> 8 bytes, then it's clearly not implementing RFCs 7252 and 8323
> correctly. This will never happen, so I think a client implementation
> shouldn't bother spending any more cycles than on a comparison and a
> conditional move.

OK, thanks for the rationale.  I can surely live with that.

> >   to indicate the maximum length of a token in bytes that it accepts in
> >   requests.
> >
> > Maybe: "to indicate the maximum acceptable length of the token (in bytes)"
>
> Maybe this?
>
>     A server can use the elective Extended-Token-Length Capability
>     Option to indicate the maximum token length it can accept in
>     requests.

LGTM

> >   support by a server does not oblige a client to actually make use of
> >   token lengths greater than 8.
> >
> > s/oblige/force/
>
> This wording is copied from https://tools.ietf.org/html/rfc8323#section-5.3.2

OK, it sounded slightly unfamiliar to me, but a) I'm not a native speaker,
b) if the RFC Editor is happy with that construction who am I to argue? :-)

> >   AES-CCM with a 64 bit tag is recommended
> >
> > CCM (and the tag choice) looks fine given that a) we need to buffer the
> > whole header anyway, and b) we want to limit the amount of tag bits as
> > much as possible while keeping the whole auth-enc machinery secure.
> > Maybe we should stick the usual note about nonce reuse / misuse
> > (especially for clients with low-quality entropy sources) and key
> > rotation strategies (since proxies potentially need to route a
> > considerable amount of messages).
>
> Would you like to propose some text?

Sure, will do on Github.

> >    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.  Instead, it SHOULD return a 5.03 (Service
> >    Unavailable) response.  (Returning this response requires that the
> >    server implementation is able to return a token of any length, even
> >    if it otherwise cannot handle tokens of that length.)
> >
> > This para is a tad dense.  In particular, the use of "unable" seems to
> > contradict the MUST NOT: if I'm unable to handle this how can I not
> > reject it, what should I do?
>
> Handling a request usually goes through multiple steps from receiving
> the message to handing it over to application logic. The intention
> here was to say that a server implementing the document at least needs
> to support large tokens in the first few steps (enough to return an
> error response rather than a Reset message -- which is how we
> distinguish between "server does not support extended tokens" and
> "server temporarily does not have enough memory for this extended
> token").

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.

> > I'm probably not up-to-speed with the
> > related discussion, but I don't understand why we moved from 4.xx to
> > 5.xx?
>
> Now that you're mentioning it... It seems this needs a bit more thinking.
>
> There's the case where the server temporarily doesn't have enough
> memory to handle a request with a large token (so nothing that the
> client can do about -> 5.xx). And there's the case where the client
> chose a large token that the server will never be able to handle after
> the initial steps (so not something the client should try again ->
> 4.xx? 5.xx?).

The latter looks like a 4.xx to me.

Cheers, t



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.