Subject: Re: [core] Chairs' review of draft-ietf-core-stateless-03.txt

From: Thomas Fossati <[email-masked]>
Date: Fri, 1 Nov 2019 09:27:17 +0000

On 01/11/2019, 06:44, "Carsten Bormann" <[email-masked]> wrote:
> > On Oct 31, 2019, at 23:19, Thomas Fossati <[email-masked]> wrote:
> > On 31/10/2019, 17:08, "core on behalf of Carsten Bormann" <[email-masked] on behalf of [email-masked]> wrote:
> > >
> > >   When using AES-CCM, repeated use of the same nonce under the
> > >   same key
> > >
> > > Not just AES-CCM, just about any AEAD.
> >
> > The problem is not with AEAD per se, we could have picked GCM-SIV
> > and there would have been no trouble.  The problem is with the
> > underlying CTR.
>
> Right, that’s why my proposed text specifically talks about
> "encryption mode that depends on a nonce".

Yes, I think your suggestion is a good one.

> > Quibbles aside, the document recommends CCM -- over other AEAD
> > constructions -- and does so consciously, I think, to provide the
> > best trade-off between overall security, wire efficiency and
> > processing cost.
> >
> > This point does not surface in the current text, but the
> > recommendation for CCM is actually quite precise, and maybe worth an
> > upper-case RECOMMENDED?
>
> I agree that this is a good recommendation.  It is not an
> interoperability requirement, though (and 64 bits of authenticator may
> actually be a bit low for some applications), so the purist in me
> isn’t thrilled about using a BCP 14 keyword.

Correct. I was pondering over a "strongly recommends" instead, but it's
probably not the right thing to say either.

OK, apologies for the noise :-)

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.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 1 Nov 2019 10:50:49 +0100

On Nov 1, 2019, at 10:27, Thomas Fossati <[email-masked]> wrote:
>> the purist in me

I think it is a “highly recommended” (use this if you don’t know what to use, you can’t really go wrong with it) and not a “strongly recommended” (don’t dare to use something else unless you have a really good reason).  BCP14 RECOMMENDED is more of the latter kind.  At some point we MAY WISH TO [1] identify a separate set of keywords for implementation advice.

Grüße, Carsten

[1]: https://tools.ietf.org/html/rfc6919#section-6

---

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Nov 2019 16:09:50 -0400

Thomas Fossati <[email-masked]> wrote:
    > constructions -- and does so consciously, I think, to provide the best
    > trade-off between overall security, wire efficiency and processing cost.

... because CCM is most likely to be available accelerated in small devices?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 2 Nov 2019 21:12:33 +0100

On Nov 2, 2019, at 21:09, Michael Richardson <[email-masked]> wrote:
> … because CCM is most likely to be available accelerated in small devices?

It is used both in 802.15.4 and WiFi, so you are likely to have some support.
Whether that is easily accessible from the application layer is another question.
It is slightly more robust against nonce reuse than, say, GCM (reuse only jeopardizes the confidentiality of the two data items encrypted with the same nonce, instead of essentially giving away your hash key as with GCM).
It also has been out for a while, so implementations tend to be mature.

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 20 Nov 2019 13:23:04 +0100

Carsten Bormann wrote:
>            The option value MUST NOT be less than 8 or greater than 65804.  If
>            an option value outside this range is received, the value MUST be
>            clamped to this range.
>
> I am still not a fan of re-interpreting disallowed values.
> (Assuming there was later any reason to go beyond 65804, of course allowing
> larger values and interpreting these as 65804 because a client knowing
> just this specification cannot make use of lengths >65804 makes sense.
> Not so sure about the values 0..7 though.)

Well, the option is elective. So, for example, if a server says "I
support tokens only up to 3 bytes" and the client doesn't understand
the option, the client would still send requests with 4-8 byte tokens.
Requiring a client that does understand the option to send an error
for values 0..7 wouldn't change that.

Of course, we could use values 0..7 to signal special cases to clients
that understand the options (though I don't know why we wouldn't use
dedicated options for that). This document won't define any special
cases, so this is about a future possibility. The question then is,
how we would introduce these special cases in the future and what we
want clients to do with those values until then. IMO letting clients
that understand the option but not values 0..7 handle the option
exactly like clients that don't understand the option at all is the
best answer.

>            have been forwarded by an intermediary.  To ensure that this does not
>            lead to inconsistent resource state, a stateless intermediary MUST
>            include the Request-Tag Option [I-D.ietf-core-echo-request-tag] in
>            block-wise transfers with a value that uniquely identifies the client
>            in the intermediary's namespace.
>
> -> To ensure that this does not lead to inconsistent resource state, a
> stateless intermediary that wants to forward requests with Block1
> options will need to also include a distinguishing option such as the Request-Tag Option
> [I-D.ietf-core-echo-request-tag] in a way that uniquely...

Done.

>            When using AES-CCM, repeated use of the same nonce under the same key
>
> Not just AES-CCM, just about any AEAD.  Maybe say: When using an
> encryption mode that depends on a nonce, such as AES-CCM, ...

Done.

> ## Nits
>
>            A client SHOULD NOT assume that extended token lengths are supported
>            by a server 60 minutes after receiving a response with an extended
>            token length, as network addresses may change.
>
> s/60/later than 60/

Done.

Klaus