Subject: [Lake] WGLC for draft-ietf-lake-reqs-01

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Feb 2020 15:32:07 +0000

Hi all,

The authors have asked to start a WGLC for the requirements
document. [1] This mail is to start that. The deadline for
comments is March 19th in order to give the authors time to
prepare for discussion at the upcoming IETF meeting. Since
my co-chair Mališa is a co-author of this draft, I'll be
the one calling consensus on the WGLC. (If that gets tricky,
I'll likely ask for help from our AD.)

If you can, it'd be great to get comments in the next week,
to give the authors a chance to publish an update before
the March 9th I-D cutoff, should they think that'll help
us get done.

If you think this is ready, sending a comment to that
effect is fine. If you think it's not ready, you do need
to say why and ideally suggest changes that'd, in your
opinion, make it ready.

As a reminder - our charter calls for us to park this draft
after WGLC has successfully completed, and we'll not be
sending this on for publication as an RFC at this time. So
please try keep the focus of your comments on the meat of
the content rather than on crossing all the i's and dotting
all the t's:-)

Thanks,
Stephen.

PS: I'll send my own comments (with no hats) in a separate
mail shortly.

[1] https://tools.ietf.org/html/draft-ietf-lake-reqs-01

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Feb 2020 16:26:34 +0000

Hiya,

Here are my comments, as a participant, not as a chair.
Please handle them alongside any other comments from WG
participants. (The purely editorial and nitty comments
at the end are probably ok to ignore if you prefer.)
If any of my comments contradict earlier discussion,
on the list or in the github issue handling: apologies,
just say so, and then ignore 'em:-)

Cheers,
S.

#1. Is section 3 intended to be all that an AKE designer
needs to cross-check against their design? That doesn't
seem to be true at the moment. For example, 2.3 now calls
for KCI, but that's not mentioned in section 3.  If section
3 is not intended to be that, then what's the benefit in
having it? Might be easiest to just delete it since the
draft isn't that long.

#2. 2.1: The Sender ID as described in RFC8613, section 3.2
has additional uniqueness requirements not (re-)stated
here that aim to protect against nonce re-use in the AEAD.
Do those requirements apply and/or need to be stated here?
(I'm not sure they do, as I just quickly looked at 8613,
so this is just a question.)

#3. 2.1: says "COSE... shall therefore be used also by the
AKE" - is that too strong? Perhaps all we need to say is
that it must be possible for an AKE meeting these
requirements to use COSE? The statement as-is could be
considered a showstopper for a claim that ctls can meet
these requirements, which seems like a bad plan.  An editing
pass to check that we're not stating requirements that can't
really be met by ctls may be a good idea I'd say.  (The 3rd
bullet in section 3 also states this requirement.)

#4. 2.1: "It is therefore assumed that the AKE is being
transported in a protocol that provides reliable
transport, that can preserve packet ordering and handle
message duplication, that can perform fragmentation and
protect against denial of service attacks..." That seems too
strongly-stated. s/assumed/desirable/ would seem better to
me. There may also be applications where an unreliable or
partially-reliable transport is what's needed, e.g. for a
sensor where we can easily survive the loss of occasional
cumulative measurements.

#5. 2.2: "the AKE must support different schemes for
transporting and identifying credentials, including those
identified in Section 2 of [I-D.ietf-cose-x509]." I seem to
recall there being some (possibly now expired) IPR in that
space. It might be worth s/including/such as/ there to give
some wriggle room in case one of those methods were still
encumbered.

#6. 2.5: "all the COSE algorithms" - that could do with a
reference and that IANA registry [7] can change and
already has quite a few entries - do we really need all of
those?  HSS-LMS is there for example and no doubt PQC algs
will be added soonish. Perhaps what we want to say is that
an AKE meeting these requirements has to be able to
support negotiation of (some of?) the recommended algorithms
from [7] or else from equivalent TLS registries?

   [1] https://www.iana.org/assignments/cose/cose.xhtml#algorithms

#7. 2.6: "In the case of public key identities, the AKE is
required to protect the identity of one of the peers
against active attackers and the identity of the other peer
against passive attackers." That's unclear (to me). I think
you more-or-less mean that "server" or "listening peer"
identifiers can be probed by active attackers, but that
"client" or "initiator" identifiers ought not be visible,
even if the other peer contacted in that case is bogus.  Is
that it? (If so, e.g. that'd mean that a server cert had
to be verified before a client cert was sent for client
auth.) Could that be worded better?

#8. 2.9: I'm unclear if we are or are not calling for some
form of DoS mitigation (e.g. a cookie scheme) when under
excessive load here. There are also trade-offs in terms of
bytes on the wire vs. external references (e.g. to certs,
cert-status) where more of the latter can create a DoS
vector. I wasn't clear what 2.9 was meant to say TBH.
It's probably ok to leave it there, and not try make
it perfect but it might equally be ok to just delete
the section.

editorial:

- abstract: Given the charter of the WG calls for not
publishing this as an RFC (at least for now, we could
revisit that later), it may be useful to include a statement
to that effect in the abstract, so readers don't get
confused now or later. Perhaps something like: "This draft
[is in|has completed] a working group last call (WGLC) in
the LAKE working group.  Post-WGLC, the requirements [will
be|are] considered sufficiently stable for the working group
to proceed with its work. It is not currently planned to
publish this draft as an RFC." (The square-bracketed text
could be made to match the correct state whenever a revised
I-D is published.)

- intro: there's a mention of OCF without a reference. When
I went and checked [2] I didn't find the string "OSCORE",
am I looking in the wrong place? ([2] is 195 pages long
though, so I may have just missed it;-) [FairHair] now also
seems to be part of OCF, and I also didn't find the string
"OSCORE" in [3]. I guess that bit of text needs an update or
could be deleted?

   [2]
https://openconnectivity.org/specs/OCF_Security_Specification_v2.1.1.pdf
   [3]
https://openconnectivity.org/wp-content/uploads/2019/11/fairhair-specification-version-10_approved_april-2019.pdf

- 2.3: KCI and the other threats in that bullet list could
benefit from references (to avoid AKE designers
disagreeing on what's meant, which'd be good to avoid
later). The references below (well, all but one:-), might
work for those.

    [4]
https://www.usenix.org/system/files/conference/woot15/woot15-paper-hlauschek.pdf
    [5] https://arxiv.org/pdf/1902.07550.pdf
    [6]
https://eu.azcentral.com/story/news/local/southwest-valley/2019/03/10/90-seconds-terror-wildlife-world-zoo-started-jaguar-selfie-litchfield-park/3125031002/
    [7] https://eprint.iacr.org/2019/347

- 2.6: "For certain data we therefore need to make an
exemption in order to obtain an efficient protocol." I
don't think you actually need to say that, but if there's a
desire to say something, maybe better to turn it around, and
e.g. say "An AKE that protects identifiers is preferable to
one that does not." (The sentence before already makes the
point that trade-offs may be needed.)

- 2.10: "per power": in my experience the aspect of radio
power consumption one would most like to reduce is
listening time and not transmitting time. This text doesn't
seem to reflect that.

very nitty stuff:

- intro, 1st para: be good to have a URL for LAKE somewhere
in case a reader doesn't know about the WG.

- intro: Why the versioning related to other WG charters?
E.g. the "(-02)" for 6ticsh. Not objecting but seems
unnecessary.

- 2.1: COSE should have a reference on 1st use.

- 2.2: "IoT deployments differ..." is a little ambiguous.
You could mean that they differ from non-IoT deployments
or that different IoT deployments differ. I guess it's the
latter. s/differ/differ from one another/ would fix I guess.

- 2.2: "Considering the wide variety of deployments the AKE
must support different schemes for transporting and
identifying credentials, including those identified in
Section 2 of [I-D.ietf-cose-x509]." That's not a sentence.
s/deployments/deployments,/ would make it one:-)

- 2.6: It might be good to use "identifier" rather than
"identity" in a number of places here.

- 2.7: Just a comment in passing:
[I-D.selander-ace-ake-authz] seems to have a bunch in
common with ESNI.

- 2.10: (In somewhat self-aggrandising mode:-) a reference
to RFC8376 might provide some more useful background here.

- refs: the URL for the PDF referenced by [LwM2M] is an
http-schemed URL. Better to use https.

- refs: [FairHair] - the https URL here generates a cert
error (wrong name in some URL shortener or something)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Feb 2020 14:12:57 -0500

> prepare for discussion at the upcoming IETF meeting. Since

Hi, it is my understanding that we do not plan to publish this document, so I
guess maybe this is better called a WG Consensus Call?  :-)

I have read the document again from beginning to end today.
I haven't read Stephen's review yet.

In reading the AKE Frequency section a thought occured to me.
Is the NVRAM/storage requirement of the AKE important?
In the 6tisch zero-touch situation (including 6tisch-minimal-security, where
we do not use an AKE), there is a need to keep the resulting OSCORE context
alive long term because there is a need to rotate the network keys
(and sometimes the 2-byte address).
[ draft-ietf-6tisch-minimal-security-15 section 8.2 ]

That's just the infrastructure usage of OSCORE.
The device also performs some application, and that application may need one
or more contexts to remain "live" to continue.  I thought we had some text
somewhere about resumption as well.  I'm not sure what to do with this
thought, maybe this belongs in section 2.10?

Overall, the document is "good enough".

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Feb 2020 14:17:15 -0500

> some wriggle room in case one of those methods were still

https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-cose-x509
I can't find any IPR on this.
I prefer to use the UDF: scheme that mathmesh proposes over the x5u mechanism.

    > error (wrong name in some URL shortener or something)

It's moved to:
     https://openconnectivity.org/developer/specifications/fairhair

seems an odd thing for fairhair to do.