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

[Klaus Hartke <[e-mail]>]

Hi Thomas,

thanks a lot for your review!

>    Section 3 of this document provides considerations clients opting
>    into becoming "stateless" in this way.
>
> This sentence doesn't parse right; it looks like it's missing a "for"
> just before "clients"?

Fixed.

>    The maximum token length that sender and
>    recipient implementations support may be more limited
>
> s/more limited/shorter/

Done.

>   The active value of the Extended-Token-Length Option is replaced each
>   time the option is sent with a modified value.
>
> s/replaced/updated/
> s/is sent with a modified value/is received/
>
>   Its starting value is its base value
>
> The starting value is the Option's base value.

This wording is copied from https://tools.ietf.org/html/rfc8323#section-5.3.1

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

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

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

>   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

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

>   Discovery needs to be performed for each pair of hops.
>
> s/each pair of hops/each hop/

Done.

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

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

What do you think?

Klaus