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

[Christopher Wood <[e-mail]>]

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