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

From: Göran Selander <[email-masked]>
Date: Wed, 4 Mar 2020 11:11:24 +0000

Hi Stephen,

Sorry for the delay, I was on vacation last week. 

Thanks for the review,  comments inline.  I made two PRs, one for the non-editorial, another for the editorials and nits:
https://github.com/lake-wg/reqs/pull/17
https://github.com/lake-wg/reqs/pull/18
	
Göran

On 2020-02-21, 17:27, "Lake on behalf of Stephen Farrell" <[email-masked] on behalf of [email-masked]> wrote:
    
    #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.

<GS> Good point, section 3 removed.
    
    #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.)

<GS> We were hesitant to bring in the full uniqueness requirement, since it introduces terms that are not needed for the requirements, like e.g. "ID Context".  I added sub-bullet to try it out, is that better?

"   Sender IDs are expected to be unique for a given Master Secret, more precisely the quartet (Master Secret, Master Salt, ID Context, Sender ID) MUST be unique, see Section 3.3. of [RFC8613]."
    
    #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.)

<GS> As is mentioned in the same paragraph there are several reasons for requiring COSE to be used. COSE already provides the crypto primitives for OSCORE, schemes for standardized compact identification of credentials and algorithms for OSCORE and the AKE, and an extension point for new schemes. One main target for LAKE are devices with an existing OSCORE and COSE implementation and this requirement avoids duplicating implementation or representation of algorithms etc. for reduced storage and maintenance.

I have two other concerns with this comment:
1. It is not clear to me that "can't be met by CTLS" is well defined. 
2. Why should existing solution candidates at all be considered in the formulation of requirements?

Moreover, I find "it must be possible to use COSE" slightly theoretical. It could be interpreted as compliance with that requirement if it is in theory possible to make a mapping, but that could be of little value unless the specification actually defines how COSE algorithms are used for identification of credentials, algorithms and as extension point for new schemes.

Here is a proposed update:

OLD
COSE provides the crypto primitives for OSCORE, and shall therefore be used also by the AKE, for several reasons including maintenance of crypto library. COSE provides identification of credentials and algorithms for OSCORE and the AKE, and an extension point for new schemes.

NEW
COSE provides the crypto primitives for OSCORE. The AKE shall specify how COSE can be reused for identification of credentials and algorithms of the AKE, as extension point for new schemes, and to avoid duplicated maintenance of crypto library.

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

<GS> Yes, it must be possible to run the AKE on top of unreliable link layers, but it is not clear that the AKE should have to care about that. Given that there already is a CoAP implemention available the device should make use of that instead of duplicating the functionality in the AKE. Or, alternatively use some other transport protocol X could provides the same features. Independently of which transport protocol that provides these features it should be out of scope for LAKE. Does that make more sense?
    
    #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.

<GS>Again, the assumption is that COSE is implemented and in use in the device. I think potential encumbering IPR related to a COSE draft and how to handle that should be the responsibility of the COSE WG, not LAKE. Does that sound reasonable?
    
    #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

<GS> A reference is added. I think it would defeat the purpose to state here which algorithms are possible to negotiate, as one feature is that this should be extensible. We state elsewhere that, e.g., PQC is out of scope for now. How about this:

OLD
The AKE shall support negotiation of all the COSE algorithms to be used in the AKE and in OSCORE.

NEW
The AKE shall support negotiation of COSE algorithms [ref] to be used in the AKE and in OSCORE.

[ref] 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?

<GS>This is, as far as I understand, the identity protection provided by SIGMA without going into SIGMA. SIGMA-I provides the protection of initiator identity against active attackers since the responder reveals its identity (identifier) first (encrypted by shared secret derived from ephemeral keys) in the message when it authenticates to the initiator. Since the responder identity is encrypted with key derived from ephemeral DH, it is protected against passive attacks but could be subject to MITM. Conversely SIGMA-R protects the responder against active attackers. If this is still unclear, please propose what needs to 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.

<GS>I agree this section is not in in any way extensive, but it was requested to mention DoS. The CoAP Echo option, mentioned in Section 2.1, provides something like a cookie scheme. Your point with DoS against third parties was missing so I substituted "attacks on responder and initiator" with "attacks on responder, initiator and third parties ".    

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

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

<GS> Thanks for checking the references. OCF provided requirements on OSCORE during the development and expressed an interest to adopt OSCORE once it had become an RFC which happened in July 2019 (after this text was drafted) but since it is still not include in any reference we can delete that bullet. Fairhair Alliance which is now OCF included OSCORE in their security architecture for IoT in commercial buildings white paper, but that reference is now moved to the OCF domain so I kept the reference but changed to the new location.

    - 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

<GS> OK. I left out the jaguar attack though :D
    
    - 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.)

<GS> Sentence removed.
    
    - 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.

<GS> Indeed, listening has a high cost, and there are techniques to reduce that cost like time slots, DRX, etc. IIRC, the reason why listening time is omitted is because it is not believed to impact the design of an AKE on application layer. I added some text on this.

    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.

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

<GS> This was copied from input to the secdispatch discussion, now versions are removed.
    
    - 2.1: COSE should have a reference on 1st use.

<GS> Done, added reference to CoAP and CBOR too.
    
    - 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.

<GS> Done.
    
    - 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:-)

<GS> Done.

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

<GS> I find it difficult to do this consistently. There are already a number of terms expressed in terms of "identity". The SIGMA paper speaks of "identity". The requirements are expressed in terms of "identity protection" and "identity misbinding", should we change that to "identifier protection" and "identifier misbinding"? When I've tried I ended up in formulations like "the identifier identifying the identity" and then I gave up. So, not done. Please provide concrete proposal if you think this is worth doing.

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

<GS> Interesting. I didn't see any implications on any of the drafts though.
    
    - 2.10: (In somewhat self-aggrandising mode:-) a reference
    to RFC8376 might provide some more useful background here.

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

<GS> Done.

    - refs: [FairHair] - the https URL here generates a cert
    error (wrong name in some URL shortener or something)
    
 <GS> Fixed by the updated location for this reference.

---

From: Göran Selander <[email-masked]>
Date: Thu, 5 Mar 2020 06:32:20 +0000

Hi Stephen,

I was made aware of that there is a minor difference in the proposed update written in the mail and in the PR in response to comment #3. 

I copied some of the changes to the draft from the PR to the mail for easy access, but that of course opened up for different versions - bad idea. 

Sorry about that. Please disregard the OLD/NEW and read the PRs. 

Göran

> 4 mars 2020 kl. 12:12 skrev Göran Selander <goran.selander=[email-masked]>:
> 
> Hi Stephen,
> 
> https://protect2.fireeye.com/v1/url?k=75ec52db-2966992f-75ec1240-86cd58c48020-6fad257f20bb0616&q=1&e=7a35cab1-a649-47de-95b5-0e6b0348ab11&u=https%3A%2F%2Fgithub.com%2Flake-wg%2Freqs%2Fpull%2F17
> https://protect2.fireeye.com/v1/url?k=3c22b196-60a87a62-3c22f10d-86cd58c48020-3d4caf50a871db19&q=1&e=7a35cab1-a649-47de-95b5-0e6b0348ab11&u=https%3A%2F%2Fgithub.com%2Flake-wg%2Freqs%2Fpull%2F18
> 
> Göran
> 
> 
>   https://protect2.fireeye.com/v1/url?k=bfcc30c8-e346fb3c-bfcc7053-86cd58c48020-a6ee78aa0ea1898d&q=1&e=7a35cab1-a649-47de-95b5-0e6b0348ab11&u=https%3A%2F%2Fopenconnectivity.org%2Fspecs%2FOCF_Security_Specification_v2.1.1.pdf
>      [3]
>   https://protect2.fireeye.com/v1/url?k=7ea70362-222dc896-7ea743f9-86cd58c48020-387f3301be17e2d1&q=1&e=7a35cab1-a649-47de-95b5-0e6b0348ab11&u=https%3A%2F%2Fopenconnectivity.org%2Fwp-content%2Fuploads%2F2019%2F11%2Ffairhair-specification-version-10_approved_april-2019.pdf
> 
>       [7] https://protect2.fireeye.com/v1/url?k=209283f4-7c184800-2092c36f-86cd58c48020-9a49deb13e0e55ca&q=1&e=7a35cab1-a649-47de-95b5-0e6b0348ab11&u=https%3A%2F%2Feprint.iacr.org%2F2019%2F347
> 
> -- 
> Lake mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lake

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Mar 2020 16:05:52 +0000

Ping! Today's the deadline day for this. Please do try
get your comments in on time.

While this hasn't been controversial in the WG, I would
like to see more comment as there hasn't been enough to
determine if we have consensus to proceed. So some more
mails saying you've read this version and are ok with it
would be good if that's the case. Or if not, why not.

Thanks,
S.

On 21/02/2020 15:32, Stephen Farrell wrote:
> 
> 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: "Christopher Wood" <[email-masked]>
Date: Thu, 19 Mar 2020 09:46:49 -0700

Thanks to the authors for compiling this list of requirements. I think the
document is in good enough shape to move forward in LAKE. I have some clarifying
questions and comments, which I list below. I hope they're helpful.

Best,
Chris

~~~

Section 2.1:

   Furthermore, there is no assumption of
   dependence between CoAP client/server and AKE initiator/responder
   roles, and an OSCORE context may be used with CoAP client and server
   roles interchanged as is done, for example, in [LwM2M].

Does this imply that a single OSCORE context, which I assume (maybe incorrectly)
has credentials configured, may be used in both initiator and responder roles?
If so, should we be mindful of Selfie-style issues? (It's referenced later, so 
perhaps not.)

Section 2.2:

   The security of these
   systems can be improved by adding PFS through an AKE authenticated by
   the provisioned PSK.

Is it worth mentioning the hash-based ratchet technique for improving forward 
secrecy as an alternate?

   In order to allow for these different schemes, the AKE must support
   PSK- (shared between two nodes), RPK- and certificate-based
   authentication.

2.3: 

   Moreover, it shall be possible for the receiving endpoint to detect a
   replayed AKE message.

Why is this in the mutual authentication requirements section, and why does it
need to be a requirement on the AKE? Would it be better to require that replays
do no affect the security of other AKE sessions?

2.4: 

   The AKE shall provide a mechanism to use the output of one handshake
   to optimize future handshakes, e.g., by generating keying material
   which can be used to authenticate a future handshake, thus avoiding
   the need for public key authentication in that handshake.

Do we need to constrain how (often) endpoints use this state for future 
connections?

2.5: 

   PAKE and post-quantum key exchange is out of
   scope, but may be supported in a later version.

Hybrid variants likely don't make sense for LAKE deployment scenarios. However, 
it's unclear if the AKE shall allow hybrid KEX algorithms. (Perhaps this might 
be mentioned in Section 2.8 instead?)

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.

Should we be more precise with respect to which role (initiator or responder)
has passive or active protection? SIGMA-I and SIGMA-R differ in this respect,
at the cost of an additional flight, so it's probably worth clarifying.

On Thu, Mar 19, 2020, at 9:05 AM, Stephen Farrell wrote:
> Attachments:
> * 0x5AB2FAF17B172BEA.asc
> * signature.asc

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 Mar 2020 15:06:21 -0400

> get your comments in on time.

I have read the document, and I have nothing further to add, nor anything
that I would remove.

--
]               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: Richard Barnes <[email-masked]>
Date: Thu, 19 Mar 2020 15:21:30 -0400

Hi LAKE folks,

I have reviewed this document as part of the WGLC.  I do not believe it is
ready yet.

Detailed notes follow, pointing out a bunch of inaccuracies and
ambiguities, but the overriding problem is that this document doesn't
provide a clear framework for evaluating protocols, which is the whole
point of a requirements document.

Section 2.10 in particular is still quite hand-wavy, lacking even basic
quantification for at least one link layer.  It seems like what we need to
do a real evaluation (in addition to a bunch of more minor things noted
below) is a set of scenarios, in terms of network environment and protocol
functions, that we can evaluate different protocol candidates against.
Things like, "PSK mode with X25519/Ed25519/CCM8 over LoRa" or "RPK+PKI mode
with P-256/GCM NB-IoT".

===

General - The document could be more clearly organized.  I would expect a
structure something like:

* What the AKE can assume about the transport
* What it needs to provide for OSCORE
* What security properties it needs to provide
* What operational constraints it needs to meet

The content is largely there, but jumbled together and often insufficently
specified (more details below).

Section 1 - The mention of the Fairhair Alliance here seems unhelpful.  I
thought we were agreed that the AKE we're discussing here would be 1-1, not
group; the latter would call for quite different designs.  Assuming that
agreement holds, the document should clearly reflect it.  This reference
muddies the water.

Section 2.1, "The AKE shall specify how COSE can be reused for
identification of credentials and algorithms of OSCORE and the AKE" - This
requirement should be deleted.  For one thing, OSCORE doesn't have
credentials.  And it's not clear that re-using COSE is the lightest-weight
path.

Section 2.1, "the AKE must support transport over CoAP" - Does this mean
that COAP framing needs to be included in the message size allocations?

Section 2.1, "The AKE may use other transport than CoAP" - This section is
a good start, but should be expanded to a normative list of things the AKE
may depend on for transport.  These will be important design parameters for
the AKE.  This would also be a good point to clarify that this is a
two-party protocol and assign names to the parties (say, "client" and
"server").

Section 2.2 - You've laid out a massive number of possible scenarios here.
I count at least 17, by the time you count PSK plus all the combinations of
(a) RPK vs. PKI (b) value vs. reference (c) both of the above for
sender/receiver.  While this is possible (TLS does it for the most part),
it might be helpful in an evaluation of candidates to understand which are
the priority cases.

Section 2.3 - Do you really want to always require mutual authentication?
Are there not scenarios where it is acceptable for one party to be
anonymous?

Section 2.3 - This section talks in terms of attacks, but doesn't say
anything about actual authentication properties.  The latter would be
helpful in supporting analyses of the protocol.

Section 2.6, "the AKE is required to protect the identity of one of the
peers against active attackers" - It's pretty clear from the constraints
which peer is which in any practical protocol (server/passive,
client/active, as in TLS 1.3).  You should just say that.

Section 2.6, "Other identifying information that needs to be transported in
plain text is cipher suites and connection identifiers" - This is the first
and only mention of connection identifiers (!)  Section 2.1 talks about
OSCORE sender IDs, but only as an *output* of the AKE, not something used
within the AKE protocol.  I suspect this should just be dropped.

Section 2.6, "Encrypting crypto algorithms does not allow negotiation of
cipher suite within 3 flights" - If you contrast this with the ESNI/ECHO
work being done with TLS, it may or may not be true, depending on how you
account for pre-configuration of server information.

Section 2.7 - This section should be dropped or tightened up.  My
preference would be to drop it, since the AKE's job is to negotiate keys,
not carry application data.  If we're going to keep it, we need to be clear
about what properties are expected, for example, by saying that the
auxiliary data must be protected to the same level as AKE data in the same
flight.

Section 2.7, "The auxiliary data must not violate the AKE security
properties" - This is super vague.  Can you provide an example of what you
mean?

Section 2.8, "Note that by supporting COSE" - The AKE is unspecified here.
It doesn't necessariliy support COSE.  This sentence should be struck.

Section 2.9 - Surprised to see this here, given that Section 2.1 says that
DoS protection is provided by the transport.

Section 2.10 - There's lots of information here, but not much of it
actionable.  ISTM that in order to evaluate different protocols, we'll need
to be able to predict how they perform in different network environments,
on different platforms.  This section does not provide enough detail to
support that analysis.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Mar 2020 14:30:34 -0700

I do not believe this document is ready for WGLC. With some important
exceptions, it does a tolerable job of laying out the security
objectives, but does not really meet the need of describing the
specific resource constraints that make this a lightweight protocol
(which was the point of this requirements exercise).

Let's take the basic question of how big messages can be. Here's
what this document has to say about LoRaWAN, the technology
about what is most specific.

   LoRaWAN has a variable MTU depending on the Spreading Factor (SF).
   The higher the spreading factor, the higher distances can be achieved
   and/or better reception.  If the coverage and distance allows it,
   with SF7 - corresponding to higher data rates - the maximum payload
   is 222 bytes.  For a SF12 - and low data rates - the maximum payload
   is 51 bytes on data link layer.

   The benchmark used here is Data Rates 0-2 corresponding to a packet
   size of 51 bytes [LoRaWAN].  The use of larger frame size depend on
   good radio conditions which are not always present.  Some libraries/
   providers only support 51-bytes packet size.
   providers only support 51-bytes packet size.

I'm not sure what I am supposed to do with this: it seems like we have
packet sizes that range from 51 to 222. I think what this is saying is
that I am supposed to assume 51-byte packets, but even that is
unclear. And it leaves open more questions than it answers. For
instance:

- What is the additional penalty for (say) 5 packets over 4?
  Some additional power? Latency?

- I understand that some of these protocols are stop-and-wait.
  Is LoWaRAN? How many packets can I have outstanding at once?

- How does the CoAP overhead factor in? What about when I fragment?

The descriptions for the other technologies are even more vague:

   Increasing the number of bytes on the wire in a protocol message has
   an important effect on the 6TiSCH network in case the fragmentation
   is triggered.  More fragments contribute to congestion of shared
   cells (and concomitant error rates) in a non-linear way.

   The available size for key exchange messages depends on the topology
   of the network, whether the message is traveling uplink or downlink,
   and other stack parameters.  A key performance indicator for a 6TiSCH
   network is "network formation", i.e. the time it takes from switching
   on all devices, until the last device has executed the AKE and
   securely joined.  As an example, given the size limit on the frames
   and taking into account the different headers (including link-layer
   security), if a 6TiSCH network is 5 hops deep, the maximum CoAP
   payload size to avoid fragmentation is 47/45 bytes (uplink/downlink)
   [AKE-for-6TiSCH].

So should I be assuming 47? 45? Should I be assuming 5 hops? More?

The answers in this document are frankly pretty unsatisfactory. For
instance, it says:

   Considering the duty cycle of LoRaWAN and associated unavailable
   times, the round trips and number of LoRaWAN packets needs to be
   reduced as much as possible.

 What I would expect to see is something to the effect of: "this is
the incremental cost in {power, bandwidth, time to complete} of an
additional packet and therefore we should be able to keep to <X
packets", but really the only thing we get is in 2.10.4, which says:

   Considering that an AKE protocol complying with these
   requirements is expected to have at least 3 messages, the optimal AKE
   has 3 messages and each message fits into as few frames as possible,
   ideally 1 frame per message.

The problem here is that we *know* we are going to have to accept
some level of messages that span multiple radio units and so
getting a sense of where the real boundaries are is critical,
but this document frankly isn't much of a help.

I would suggest that we try to take one of these protocols
(say 6LoRaWAN) and do this exercise in detail and then we
will have a template for the others.

SPECIFIC COMMENTS:
Abstract:
   authenticated key exchange protocol for OSCORE.  This draft is in a
   working group last call (WGLC) in the LAKE working group.  Post-WGLC,
   the requirements will be considered sufficiently stable for the
   working group to proceed with its work.  It is not currently planned
   to publish this draft as an RFC.

You'll want to change this, obviously.

S 2.1.
   COSE provides the crypto primitives for OSCORE.  The AKE shall
   specify how COSE can be reused for identification of credentials and
   algorithms of OSCORE and the AKE, as extension point for new schemes,
   and to avoid duplicated maintenance of crypto library.

This is the first of a number of places where this document tries
to pre-make design decisions. The requirement here is lightwightness,
not COSE. In general, this document should not be making any
such decisions; I've tried to call them out but may have missed
some.

   Moreover, the AKE must support transport over CoAP.  Since the AKE
   messages most commonly will be encapsulated in CoAP, the AKE must not
   duplicate functionality provided by CoAP, or at least not duplicate
   functionality in such a way that it adds extra costs in terms of code
   size, code maintenance, etc.  It is therefore assumed that the AKE is

This too is too strong. If it required .001% more of something, that might
be a totally reasonable tradeoff for some other feature.

S 2.2.
   To further minimize the bandwidth consumption it is required to
   support transporting certificates and raw public keys by reference
   rather than by value.  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].

Really? so we need to support both x509bag and x509chain? Why?

This also needs to be a lot clearer about what the identity misbinding
properties that apply here when we refer to references.

   Assuming that both signature public keys and static DH public keys
   are in use, then also the case of mixed credentials need to be
   supported with one endpoint using a static DH public key and the
   other using a signature public key.  The AKE shall support the
   initiator signaling which public key credential mix to be used in the
   protocol such that the responder knows and can verify that the
   intended variant was executed.

I don't understand what this means. The initiator doesn't know what
the responder can use and so can offer but can't dictate it.

S 2.3.
   The AKE must provide mutual authentication during the protocol run.

So unilateral authentication is completely out of scope? Why?

   authenticated the other's credential.  In particular, both endpoints
   must agree on a fresh session identifier, and the roles and
   credentials of both endpoints.

What are the properties of this identifier? I don't see it described.
Is this a CK-style session identifier?

   *  The AKE shall protect against identity misbinding attacks
      [Misbinding].  Note that the identity may be directly related to a
      public key such as for example the public key itself, a hash of
      the public key, or data unrelated to a key.

I don't understand what this means, but it seems like having names
that are public keys is a potential cause of misbinding attacks.

What does this mean? I don't know how to detect replay of the initial
message without maintaining infinite state or an extra round trip
(or catching it later in the protocol run) do you.

   Furthermore, the endpoints shall be able to verify that the identity
   of the other endpoint is an acceptable identity that it is intended
   to authenticate to.  (This requirement extends beyond the AKE in that

What does this text mean?

S 2.4.
   Perfect Forward Secrecy may alternatively be achieved with a nonce
   exchange followed by appropriately derived new session keys provided
   that state can be kept in the form of a session counter.  Note that
   OSCORE specifies a method for session key update involving a nonce
   exchange (see Appendix B in [RFC8613]).

As noted in my comments on SAAG, the whole FS landscape is pretty
complicated, and this doesn't do that great a job of capturing it. For
instance, where do session tickets fit in?

Do we expect to need a 0-RTT feature? Because that has different FS
properties.

   To mitigate against bad random number generators the AKE shall
   mandate randomness improvements such as
   [I-D.irtf-cfrg-randomness-improvements].

I don't think this should be a requirement. It's an implementation
technique and in any case is not a differentiator for selecting
protocols.

S 2.5.
   *  The protocol shall allow multiple elliptic curves for Diffie-
      Hellman operations and signature-based authentication.

Does this need to be negotiable, as in the responder might have > 1
certificate differentiated by EC group?

   *  The AKE shall support negotiation of COSE algorithms
      [IANA-COSE-Algorithms] to be used in the AKE and in OSCORE.  A
      successful negotiation shall result in the most preferred
      algorithms of one of the parties which are supported by the other.

This is overly specific, and I don't see why it's a requirement. The
way you want to phrase this is that it resists downgrade.

   The AKE negotiation must provide strong integrity guarantees against
   active attackers.  At the end of the AKE protocol, both endpoints
   must agree on both the crypto algorithms that were proposed and those
   that were chosen.  In particular, the protocol must protect against
   downgrade attacks.

Would be good to quantify "strong". I suggest >= 128 bits.

S 2.6.
   In case of a PSK identifier, this may be protected against passive
   attackers, for example with a key derived from a Diffie-Hellman
   shared secret at the earliest in flight 3.  As a consequence, in
   order to authenticate the responder within the AKE, at least four
   protocol flights are needed in case of symmetric key authentication
   with identity protection.  Considering the need to keep the number of
   round-trips at a minimum (see Section 2.10.4), unless there are other
   good reasons for having more than 3 flights, it is not required to
   protect the PSK identifier, and it may thus be sent in the first
   flight.

This kind of buries the lede. I would just say it's not a requirement.

   Other identifying information that needs to be transported in plain
   text is cipher suites and connection identifiers.  Encrypting crypto

What is a connection identifier.

S 2.8

   The main objective with this work is to create a simple yet secure
   AKE.  The AKE should avoid having multiple ways to express the same
   thing.  When the underlying encodings offered by CBOR offer multiple
   possibility the AKE should be strongly opinioniated, and clearly
   specify which one will be used.

This seems to assume that CBOR will be used, but that's not decided.

   While remaining extensible, the AKE should avoid optional mechanisms
   which introduce code paths that are less well tested.

I don't think this is a requirement that is actionable.

   The AKE should avoid mechanisms where an initiator takes a guess at
   the policy, and when it receives a negative response, must guess,
   based upon what it has tried, what to do next.

I don't agree with this at all, and I'm not sure why this is
here. There are good reasons to do this. In fact, it's the main way to
get a three message protocol with confidentiality for the server's
first flight.

S 2.10.5.

   3.  To limit the impact of a kseley compromise, BSI, NIST and ANSSI and
       other organizations recommend in other contexts frequent renewal
       of keys by means of Diffie-Hellman key exchange.  This may be a
       symmetric key authenticated key exchange, where the symmetric key
       is obtained from a previous asymmetric key based run of the AKE.

Or hash ratcheting.

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 19 Mar 2020 17:30:35 -0700

FWIW, I think Richard and Eric raise excellent points worth considering before moving forward. 

Best,
Chris

On Thu, Mar 19, 2020, at 2:30 PM, Eric Rescorla wrote:
> I don't think this should be a requirement.. It's an implementation
> On Thu, Mar 19, 2020 at 9:06 AM Stephen Farrell 
> <[email-masked]> wrote:
> >

---

From: Göran Selander <[email-masked]>
Date: Tue, 24 Mar 2020 16:36:16 +0000

Hi Chris, Richard, Ekr, Hannes,

Thanks for your WGLC reviews. Since some comments overlapped we made one PR with all proposed changes:

https://github.com/lake-wg/reqs/pull/20

Here is the diff against -02:

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-lake-reqs.txt&url2=https://lake-wg.github.io/reqs/WGLC-updates/draft-ietf-lake-reqs.txt

Comments on your individual reviews will follow shortly. 

It would be great if you let us know by this Thursday if you have comments on the updates, to allow preparations for the WG meeting.

Göran 
on behalf of the authors

On 2020-03-19, 17:47, "Lake on behalf of Christopher Wood" <[email-masked] on behalf of [email-masked]> wrote:

    Best,
    Chris
    
    ~~~
    
    Section 2.1:

    
    Section 2.2:
    
       The security of these

    
    2.3: 

    
    2.4: 

    
    2.5: 

    
    2.6:

---

From: Göran Selander <[email-masked]>
Date: Tue, 24 Mar 2020 16:37:04 +0000

Hi Chris

    
    Best,
    Chris
    
    ~~~
    
    Section 2.1:

GS: The result of the AKE is a single OSCORE context that can be used by both CoAP and client server roles. The client and server has unique identities to protect against reflection attacks etc.  The case with more than two parties legitimately sharing keys has been considered out of scope for the AKE, as is noted in Section 2.3. Is there something else missing?

    Section 2.2:
    
       The security of these

GS: Included in Section 2.3 (Confidentiality).

    2.3: 

GS: Rephrased accordingly.
    
    2.4: 

GS: This is a relevant point for the solution, but I'm not sure the details needs to be specified in the requirements document? The updated text has this added sentence: "The AKE should give recommendations for frequency of re-keying, potentially dependent on the amount of data." 

    2.5: 

GS: We assumed hybrid key exchange is out scope for now for the same reason. Noted in this section.
    
    2.6: 

GS: This clarification was added.

---

From: Göran Selander <[email-masked]>
Date: Tue, 24 Mar 2020 16:38:17 +0000

Hi Richard

From: Lake <[email-masked]> on behalf of Richard Barnes <[email-masked]>
Date: Thursday, 19 March 2020 at 20:22
To: Michael Richardson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Lake] WGLC for draft-ietf-lake-reqs-01

Hi LAKE folks,

I have reviewed this document as part of the WGLC.  I do not believe it is ready yet.

Detailed notes follow, pointing out a bunch of inaccuracies and ambiguities, but the overriding problem is that this document doesn't provide a clear framework for evaluating protocols, which is the whole point of a requirements document.

Section 2.10 in particular is still quite hand-wavy, lacking even basic quantification for at least one link layer.  It seems like what we need to do a real evaluation (in addition to a bunch of more minor things noted below) is a set of scenarios, in terms of network environment and protocol functions, that we can evaluate different protocol candidates against.  Things like, "PSK mode with X25519/Ed25519/CCM8 over LoRa" or "RPK+PKI mode with P-256/GCM NB-IoT".

GS: First note that the primary reason for benchmarks/requirements was not to have a comparison between protocols:

https://mailarchive.ietf.org/arch/msg/lake/PkqiwDV6_s5iVVSCyL56Jy0wW4M/

But if you do want to evaluate protocol candidates, then the benchmarks provided should enable you to do that. The information was a bit spread out in 2.10 and is now compiled in 2.10.4. More below.

===

General - The document could be more clearly organized.  I would expect a structure something like:

The content is largely there, but jumbled together and often insufficently specified (more details below).

GS: As the chairs urged us in the call to “keep the focus of your comments on the meat of the content” we propose we leave the structure as it is, as long as the content is largely there.

Section 1 - The mention of the Fairhair Alliance here seems unhelpful.  I thought we were agreed that the AKE we're discussing here would be 1-1, not group; the latter would call for quite different designs.  Assuming that agreement holds, the document should clearly reflect it.  This reference muddies the water.

GS: The references in this section were included to show the planned use of OSCORE, to identify the relevant technologies. Since OSCORE is designed to be efficient for securing group communication in constrained environments, e.g. building automation applications, it seemed relevant to mention an industry forum where that feature of OSCORE was acknowledged. After all - if you make a constrained implementation which supports groups, and 1-1 as a subset, you may want to use it also for 1-1. Meanwhile Fairhair Alliance merged with OCF, and last week there was a joint meeting OCF-IRTF/T2TRG presenting how (1-1) OSCORE is planned to be used in OCF. We replaced the reference to Fairhair Alliance with a reference to OCF instead.

Section 2.1, "The AKE shall specify how COSE can be reused for identification of credentials and algorithms of OSCORE and the AKE" - This requirement should be deleted.  For one thing, OSCORE doesn't have credentials.  And it's not clear that re-using COSE is the lightest-weight path.

GS: There are several reasons for reusing COSE for the AKE. OSCORE uses COSE crypto primitives, identification of algorithms for encryption, key derivation, etc.  COSE has a number of smart solutions used in constrained IoT, e.g. the COSE header parameters, CCM*, etc. Reuse of COSE implementation avoids duplicating implementations, representation of algorithms etc. for reduced footprint and maintenance. Both OSCORE and AKE uses an AEAD, key derivation, signature (in case of Group OSCORE, which is expected to be common in implementations). Having different constructs for using them creates unnecessary complexity that is bound to be a source of confusion and bugs in a combined AKE/OSCORE implementation. Imagine the TLS handshake and TLS record layer being different in this respect! Nevertheless, the text is now changed from “must” to “strongly recommend”.

Section 2.1, "the AKE must support transport over CoAP" - Does this mean that COAP framing needs to be included in the message size allocations?

GS: The AKE may support other transport (as noted below) but for the use cases where CoAP transport is required the CoAP message size needs be considered.

Section 2.1, "The AKE may use other transport than CoAP" - This section is a good start, but should be expanded to a normative list of things the AKE may depend on for transport.  These will be important design parameters for the AKE.  This would also be a good point to clarify that this is a two-party protocol and assign names to the parties (say, "client" and "server").

GS: The objective of this work is to produce a lightweight AKE for OSCORE, in which case the endpoint implements CoAP, and CoAP is expected to be the transport for the cases where OSCORE is used. This sentence is noting that other transports are not forbidden, but we don’t see the reason for detailing other transports at this stage as that is not required functionality.

Section 2.2 - You've laid out a massive number of possible scenarios here.  I count at least 17, by the time you count PSK plus all the combinations of (a) RPK vs. PKI (b) value vs. reference (c) both of the above for sender/receiver.  While this is possible (TLS does it for the most part), it might be helpful in an evaluation of candidates to understand which are the priority cases..

GS: Same remark as above about evaluation of candidates. The cases where the AKE must be performant are PSK and RPK, as stated in 2.10.4, in particular where RPK is pre-provisioned as PSK.

We are aware of some cases of mixed public key credentials where the constrained device provides a reference to its cert and gets RPK by value. We also know of one company who wants to transport RPK by value in an opportunistic setting. The constrained device seems to be Initiator in most cases. Perhaps others in the WG can provide other data points?

Section 2.3 - Do you really want to always require mutual authentication?  Are there not scenarios where it is acceptable for one party to be anonymous?

GS: In the use cases this work is focusing on at least one of the of the endpoints is a “thing” in the IoT. As far as we know no one has brought up a use case where the thing or the endpoint which the thing authenticates to is anonymous.

Section 2.3 - This section talks in terms of attacks, but doesn't say anything about actual authentication properties.  The latter would be helpful in supporting analyses of the protocol.

GS: Karthik has been active in the shaping this section for the purpose of supporting the analysis of the protocol. The different required methods are likely to have slightly different authentication properties, so may not be sufficient with one property. Those properties can come as an output of the analysis made during the design rather than being a requirement, since we anyway expect a discussion of the appropriate tradeoffs between performance and security.

Section 2.6, "the AKE is required to protect the identity of one of the peers against active attackers" - It's pretty clear from the constraints which peer is which in any practical protocol (server/passive, client/active, as in TLS 1.3).  You should just say that.

GS: Updated based on your and others’ comments.

Section 2.6, "Other identifying information that needs to be transported in plain text is cipher suites and connection identifiers" - This is the first and only mention of connection identifiers (!)  Section 2.1 talks about OSCORE sender IDs, but only as an *output* of the AKE, not something used within the AKE protocol.  I suspect this should just be dropped.

GS: The AKE needs identifiers in plain text to correlate messages. Since those identifiers are only discussed in this paragraph the term “connection identifier” is removed.

Section 2.6, "Encrypting crypto algorithms does not allow negotiation of cipher suite within 3 flights" - If you contrast this with the ESNI/ECHO work being done with TLS, it may or may not be true, depending on how you account for pre-configuration of server information.

GS: Removed based on your and others’ comments.

Section 2.7 - This section should be dropped or tightened up.  My preference would be to drop it, since the AKE's job is to negotiate keys, not carry application data.  If we're going to keep it, we need to be clear about what properties are expected, for example, by saying that the auxiliary data must be protected to the same level as AKE data in the same flight.

GS: Good formulation, we used that.

Section 2.7, "The auxiliary data must not violate the AKE security properties" - This is super vague.  Can you provide an example of what you mean?

GS: Auxiliary data can be used together with the AKE to build other security protocols, like in draft-selander-ace-ake-authz. Obviously this protocol needs to be analysed, for example that it does not introduce vulnerabilities into the underlying AKE. A stupid example is secret information carried in the AD.

Section 2.8, "Note that by supporting COSE" - The AKE is unspecified here.  It doesn't necessariliy support COSE.  This sentence should be struck.

GS: We rephrased this, but still mentions COSE since that is recommended to use.

Section 2.9 - Surprised to see this here, given that Section 2.1 says that DoS protection is provided by the transport.

GS: We agree that the first paragraph did not add much and removed that. But the second paragraph is still not covered elsewhere. Changed title to “availability”.

Section 2.10 - There's lots of information here, but not much of it actionable.  ISTM that in order to evaluate different protocols, we'll need to be able to predict how they perform in different network environments, on different platforms.  This section does not provide enough detail to support that analysis.

GS: Same remark as above about evaluation of candidates. Section 2.10.4 is now compiling information previously spread out in section 2.10 and should be actionable.

---

From: Göran Selander <[email-masked]>
Date: Tue, 24 Mar 2020 16:42:54 +0000

Hi Ekr

From: Lake <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Date: Thursday, 19 March 2020 at 22:31
To: Stephen Farrell <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Lake] WGLC for draft-ietf-lake-reqs-01

unclear.

GS: This text was formed out of the SecDispatch discussion. Section 2.10.0 and other parts of the text highlights the need for benchmarks. Section 2.10.1.1 indicates that the benchmark for LoRaWAN is a packet size of 51 bytes at link layer. The benchmarks are now compiled in 2.10.4, hope it is more clear now.

And it leaves open more questions than it answers. For
instance:

GS: 2.10.2 speaks about the duty cycle of 1%:
   “A duty cycle of 1% implies that the time to complete a
   fragmentation of the payload increases by at least 10,000%. This
   limitation determines how long time the device will have to wait for
   next use, which encourages the reduction of the message size as much
   as possible.”
For each packet, wait 100 times the transmission time for next packet. This excludes potential retransmissions due to lost messages or errors etc.

GS: One packet at a time.

GS: The specified LoRaWAN packet size is at link layer. If fragmention with Blockwise, this results in multiple CoAP messages + increase of total CoAP header overhead.

So should I be assuming 47? 45?

GS:. 2.10.4 states
  “The difference between uplink and downlink performance should not be
   engineered into the protocol since it cannot be assumed that a
   particular protocol message will be sent uplink or downlink.”
Since any party could be initiator, the lowest number is relevant. This is now stated in the benchmark compilation, 2.10.4.

Should I be assuming 5 hops? More?

GS: The benchmark is the example you cited above, i.e. 5 hops. We added some text clarifying this.

packets",

GS: This, together with the benchmarks, was requested in Secdispatch. That lead to the spreadsheets and comparison between TLS handshake and EDHOC e.g. Time-on-Air, presented in the virtual interim in March 2019 and in the BoF at IETF 105. The spreadsheets are still available:
https://github.com/EricssonResearch/EDHOC/tree/master/docs
https://github.com/EricssonResearch/EDHOC/blob/master/docs/LoRaWAN_ToA.xlsx
However, one conclusion of that previous discussion was that acceptable cost is application dependent so it is not easy to state maximum allowed number of packets. What is more relevant is the minimum number of packets, more below.

but really the only thing we get is in 2.10.4, which says:

GS: For the certificate case we do need messages that span multiple radio units, but not necessarily for PSK or RPK. And those are the most relevant cases for constrained IoT. In LoRaAlliance, for example, there is work on an RPK-based authentication scheme. We added new text in 2.10.4 about this limitation of certificate based authentication.

GS: As mentioned above, the spreadsheets are ready to make the exercise but will not in themselves produce any output of type “<X packets”.

SPECIFIC COMMENTS:
Abstract:

GS: Some verbs needs to change to past tense, if that is what you mean?

S 2.1.

GS: See response to Richard.

GS:  Added “non-negligible”:  “… it adds non-negligible extra costs … ”

S 2.2.

GS: One point with using COSE is that it specifies schemes relevant for constrained IoT, like x5u, x5t and provides an extension point for new smart schemes in this setting. Do we need both x5bag and x5chain? We do want to support x5chain for simpler processing, but I’ve heard of people using either (but not both). We omitted x5bag pending input from the WG.

GS:  See related comment below.

GS: In constrained deployments the initiator could very well know e.g. because only one is supported. We rephrased this.

”The AKE shall support negotiation of public key credential mix and that both can verify the variant that was executed.”

S 2.3.

GS: See response to Richard’s mail.

GS: Yes, as far as I understand. Karthik provided this input for formal verification purposes.

GS: This is a placeholder for the analysis needed to take into account different ways of identifying the subject.

GS: Rephrased based on proposal by Chris.

GS: This was requested by people working on formal verification. The requirement means that the AKE shall have a step verifying the endpoint being authenticated. In TLS web setting when connecting to example.com it needs to verify that the certificate is issued for this domain. In 3GPP when connecting to a visited network it needs to verify that there is a roaming agreement. A more restricted setting could be a pre-provisioned public key of the manufacturer used to verify information about which network to join. Can we formulate this better?

S 2.4.

GS: I put in this text in as placeholder for Karthik’s mails about alternatives for forward secrecy, and added text about hash-based ratcheting after Chris’s recent comment. The draft does not pretend to give any deeper insights on this topic. The function of this paragraph is merely as placeholder for input provided to the requirements discussion, so those inputs do not get lost in mail archive, and so that we can return to that when we evaluate the solution against the requirements. We can add text about session tickets here, but may just as well wait with that to the solution discussion where probably this entire discussion better belong.

GS: No one has requested that. For constrained IoT there is less need for “closing a connection”,  security associations can be maintained for long time. This probably also belongs to the solution discussion.

GS: This was discussed at IETF106 (initiated by Chris) and we seemed to be in agreement of its importance at the time so it would be good to keep a placeholder for that. But we can be less specific about what the AKE mandates. Rephrased.

S 2.5.

GS: This text was provided by Karthik. Changed to include negotiation.

GS: One reason why we may want to require more than “resisting downgrade” is that a protocol that always results in the least preferred common algorithm would comply with that requirement, and that obviously is not desirable.

GS: This is another topic we discussed in connection with the BoF at IETF 105 and decided at the time not to do. Another reason for leaving this out is that it is not always clear what 128 bits mean. Curve25519 may be characterized as < 128 bits. MACs shorter than 128 bits may be acceptable, this needs to be verified in the concrete protocol. The purpose of this work is to provide an AKE that works in very constrained settings. If too strong integrity requirement leads to a protocol that no one uses because of low performance then nothing is gained.

S 2.6.

GS: This text came out of a mail discussion about what kind of identity protection is needed for PSK. If we remove the motivation the next reviewer will ask why. We kept one sentence as placeholder for that discussion.

GS: Removed, see reponse to Richard.

S 2.8

GS: This text was suggested by Michael. Changed “when” to “if”.

GS: Michael?

GS: This text was suggested by Michael. Just noting a potential difference in what you say: Michael’s text speaks about initiator guessing twice. In your example that is not the case, right?

S 2.10.5.

Or hash ratcheting.

GS: This recommendation speaks about DH, but we added hash-based ratcheting as another method for PFS in section 2.4.

On Thu, Mar 19, 2020 at 9:06 AM Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
S.

--
Lake mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lake

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Mar 2020 19:49:59 -0400

> I don't think this is a requirement that is actionable.

I basically don't want us to include extension mechanisms that we don't 
know how we will use.

> GS: This text was suggested by Michael. Just noting a potential 
> difference in what you say: Michael’s text speaks about initiator 
> guessing twice. In your example that is not the case, right?

If the initiator guesses wrong, then the responder should say what they 
support.  Contrast IKEv1 "aggressive mode".

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Mar 2020 17:57:13 -0700

> GS: This text was formed out of the SecDispatch discussion. Section
> 2.10.0 and other parts of the text highlights the need for
> benchmarks. Section 2.10.1.1 indicates that the benchmark for LoRaWAN
> is a packet size of 51 bytes at link layer. The benchmarks are now
> compiled in 2.10.4, hope it is more clear now.

Not really, no. What I am looking for is something that clearly
states:

   (1) the cost at various sizes (packets, flights, etc.)
   (2) what is expected/known to be achievable with a given technology

This is not giving me that, which seems to be what's needed here.

> For each packet, wait 100 times the transmission time for next
> packet. This excludes potential retransmissions due to lost messages
> or errors etc.

OK, so what's the curve of handshake latency cost for protocols with
various message sizes? That's (in part) what I'm asking for.

> GS: The specified LoRaWAN packet size is at link layer. If fragmention
> with Blockwise, this results in multiple CoAP messages + increase of
> total CoAP header overhead.

Right, so I'm looking for this document to tell me that.

> GS: This, together with the benchmarks, was requested in
> Secdispatch. That lead to the spreadsheets and comparison between TLS
> handshake and EDHOC e.g. Time-on-Air, presented in the virtual interim
> in March 2019 and in the BoF at IETF 105. The spreadsheets are still
> tavailable:
>

Yeah, these spreadsheets aren't quite what I want because they are
focused on DTLS vs. EDHOC rather than on what happens with various
protocol sizes. The idea here is to get the relevant curve, so for
instance, "time to handshake completion by size of Message 1
controlling for Message 2" or where the cliffs are, or something, so
that we know what we are designing for.

> GS: For the certificate case we do need messages that span multiple
> radio units, but not necessarily for PSK or RPK. And those are the
> most relevant cases for constrained IoT. In LoRaAlliance, for example,
> there is work on an RPK-based authentication scheme. We added new text
> in 2.10.4 about this limitation of certificate based authentication.

Well, with RPK and signatures you will still be over three packets
because the server's first message contains both (1) a DH share
and (2) a signature, for a combined minimum of 96 bytes. So, as far
as I can tell, we have this problem. And it's also not clear (at least
to me) if there is incremental cost within the packet cliffs. Is
the answer "no"?

> GS: Some verbs needs to change to past tense, if that is what you mean?

Well, I would have removed this text entirely.

> GS: See response to Richard.

Yeah, I don't think "strongly recommended" is appropriate either. This
is not properly the business of the requirements doc.

> GS:  Added “non-negligible”:  “… it adds non-negligible extra costs … ”

I would say "should attempt to minimize".

> GS: One point with using COSE is that it specifies schemes relevant
> for constrained IoT, like x5u, x5t and provides an extension point for
> new smart schemes in this setting. Do we need both x5bag and x5chain?
> We do want to support x5chain for simpler processing, but I’ve heard
> of people using either (but not both). We omitted x5bag pending input
> from the WG.

So I don't think the way to phrase this is by reference to COSE but
by reference to the requirements, which seem to be:

- Certs by URL
- Certs by hash
- Certs explicitly [Incidentally, TLS experience was we specified
  what's effectively x5chain but everyone wanted x5bag because
  of cross-signatures]

> GS: In constrained deployments the initiator could very well know
> e.g. because only one is supported. We rephrased this.
>
> ”The AKE shall support negotiation of public key credential mix and
> that both can verify the variant that was executed.”

Thanks.

> GS: See response to Richard’s mail.

I am surprised to hear that,but OK.

> GS: Yes, as far as I understand. Karthik provided this input for formal
verification purposes.

OK, so I think this needs to be a lot clearer, given that you
also use "connection identifier".

> GS: This is a placeholder for the analysis needed to take into account
> different ways of identifying the subject.

Well, I don't really think that placeholders have a place in requirements
documents. In any case, it's very different to have the key pointed
at by reference and have the endpoint identified by the key, and they
have differentbinding properties.

> GS: Rephrased based on proposal by Chris.

Will take a lool.

> GS: This was requested by people working on formal verification. The
> requirement means that the AKE shall have a step verifying the
> endpoint being authenticated. In TLS web setting when connecting to
> example.com it needs to verify that the certificate is issued for this
> domain. In 3GPP when connecting to a visited network it needs to
> verify that there is a roaming agreement. A more restricted setting
> could be a pre-provisioned public key of the manufacturer used to
> verify information about which network to join. Can we formulate this
> better?

Not sure. Can you give me an example of something that is an AKE that
doesn't otherwise have this property?

> GS: I put in this text in as placeholder for Karthik’s mails about
> alternatives for forward secrecy, and added text about hash-based
> ratcheting after Chris’s recent comment. The draft does not pretend to
> give any deeper insights on this topic. The function of this paragraph
> is merely as placeholder for input provided to the requirements
> discussion, so those inputs do not get lost in mail archive, and so
> that we can return to that when we evaluate the solution against the
> requirements. We can add text about session tickets here, but may just
> as well wait with that to the solution discussion where probably this
> entire discussion better belong.

I believe that this document should be self-contained, so I'm not that
enthusiastic about placeholders.

> GS: One reason why we may want to require more than “resisting
> downgrade” is that a protocol that always results in the least
> preferred common algorithm would comply with that requirement, and
> that obviously is not desirable.

I'd be interested in understanding how you propose to define
this property. For instance consider a protocol like TLS where
one end sends their list and the other end picks, that doesn't
guarantee highest preferred algorithm. It seems like the
definition people have come to is about integrity of negotiation
not about "best preferred" https://eprint.iacr.org/2016/072.pdf.

> GS: This is another topic we discussed in connection with the BoF at
> IETF 105 and decided at the time not to do. Another reason for leaving
> this out is that it is not always clear what 128 bits mean. Curve25519
> may be characterized as < 128 bits. MACs shorter than 128 bits may be
> acceptable, this needs to be verified in the concrete protocol. The
> purpose of this work is to provide an AKE that works in very
> constrained settings. If too strong integrity requirement leads to a
> protocol that no one uses because of low performance then nothing is
> gained.

Hmm... I don't really remember that discussion, but I don't agree with
that outcome, and the purpose of a WGLC is to discuss this kind of
question. On the technical merits the 25519 thing is easy to handle by
either just saying 127 bits or just saying that we consider 25519 to
be about 128 bits. As for the MAC, the requirement I am talking about
is the strength of the protocol, not the size of the MAC, and I
think we should specify that.

> GS: This text came out of a mail discussion about what kind of
> identity protection is needed for PSK. If we remove the motivation
> the next reviewer will ask why. We kept one sentence as placeholder
> for that discussion.

OK.

> guessing twice. In your example that is not the case, right?

Right. Thanks for pointing that out.

-Ekr

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Mar 2020 21:49:37 -0400

> I basically don't want us to include extension mechanisms that we don't know
    > how we will use.

For example, the minor version number if IKEv1 and IKEv2 is meaningless.
Nobody knows when we would increment it, or what would it mean, so we don't
use it.  Thus, the code path for minor_version != 0 is never executed.

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