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

[Eric Rescorla <[e-mail]>]

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.


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

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?


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

On Thu, Mar 19, 2020 at 9:06 AM Stephen Farrell <[e-mail]>
wrote:

>
> 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
> >
> >
> --
> Lake mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lake
>