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

[Stephen Farrell <[e-mail]>]

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)