Skip to main content

Minutes interim-2020-lake-03: Tue 18:00
minutes-interim-2020-lake-03-202003311800-00

Meeting Minutes Lightweight Authenticated Key Exchange (lake) WG
Title Minutes interim-2020-lake-03: Tue 18:00
State Active
Other versions plain text
Last updated 2020-04-01

minutes-interim-2020-lake-03-202003311800-00
# Virtual IETF107 Lightweight Authenticated Key Exchange (LAKE)

Tuesday, March 31st, 1700-1900 UTC

Chairs: Mališa Vučinić, Stephen Farrell
Meeting link:
https://ietf.webex.com/ietf/j.php?MTID=md80160663fc09f915fd0f7e73463447b
Charter: https://datatracker.ietf.org/group/lake/about Mailing list:
https://www.ietf.org/mailman/listinfo/Lake Etherpad:
https://etherpad.tools.ietf.org/p/interim-2020-lake-03

Agenda:

0. administrivia (chairs, 5 mins)
1. Three WGLC issues (chairs, 10 mins)
2. requirements wglc processing (Göran Selander, NN mins)
3. (if 1 terminates/looks-good) solution discussion
        3.1 edhoc (John Mattsson, 10 mins)
        3.2 ctls (Eric Rescorla, 10 mins)
4. AOB

Note taker: Michael Richardson, Mališa Vučinić

Present:
1. Stephen Farrell (SF)
2. Mališa Vučinić, Inria
3. Francesca Palombini, Ericsson
4. Jim Schaad
5. Ivaylo Petrov, Acklio
6. Michael Richardson (MR)
7. Jesus Sanchez-Gomez, University of Murcia
8. Laurent Toutain
9. Alessandro Bruni
10. Russ Housley, Vigil Security LLC
11. Salaheddine ZERKANE
12. Melinda Shore, Fastly
13. Sean Turner, sn3rd
14. Valery Smyslov, ELVIS-PLUS
15. Dominique Barthel, Orange
16. Rikard Höglund (RISE)
17. Marco Tiloca - RISE
18. Chris Wood
19. Ben Kaduk, Akamai (BK)
20. Carsten Bormann, TZI
21. Mohit Sethi, Ericsson
22. John Mattsson, Ericsson (JM)
23. Klaus Hartke, Ericsson
24. Satoru Kanno, Lepidum
25. Renzo Navas, IMT Atlantique
26. Eduardo Inglés, University of Murcia
27. Christian Amsüss
28. Dan Garcia (Odin Solutions)
29. Richard Barnes (Cisco) (RB)
30. Peter Blomqvist
31. Theis Grønbech Petersen
32. Ira McDonald, High North Inc
33. Timothy Claeys, Inria
34. Carsten Schuermann
35. Dan Garcia
36. Eduardo Ingles
37. Karl Norrman
38. Yumi Sakemi, lepidum
39. Hannes Tschofenig (HT)
40. Eric Rescorla (EKR)
41. Karthikeyan Bhargavan (KB)
42. Jonathan Hammell, Canadian Centre for Cyber Security

ACTION items:
    - chairs: Send Ben's proposed text to the list
        "Ben's proposal for a way forward"
       Strip down the requirements document a lot, to have a qualitative sense
       of "these are the combinations of crypto primitives that we consider
       important *right now*" (e.g., PSK and RPK) Have an acknowledgment that
       extensibility is inevitable, but disclaim that we are focusing on
       getting it right for these narrow cases right now, and if someone wants
       to do a broader case in the future, then more analysis will need to be
       done at that time.  But for now, we focus on getting RPK and PSK into 3
       flights, 51-byte messages, and do that well. If we end up with protocol
       X that does RPK well and someone has it deployed but wants to expand
       their deployment to also use certificates, they can extend protocol X to
       do that and have a fairly homogeneous deployment, vs. having to have a
       mix of protocol X and TLS.  It may well be that TLS would do fine for
       their extended use case, but not the original use case, and having a
       homogeneous deployment is valuable.

    - EKR: to propose text on connection identifier issue
    - Karthik: to propose rephrasing on mutual authentication issue
    - EKR and Karthik: to propose text on integrity strength

Minutes:

0. administrivia (chairs, 5 mins)
    -   Calls for note takers, Michael is doing etherpad.
    - started at 17:04 UTC
    - note well
    - we will start without using queue protocol, but we may have to adopt it.
    - GS: proposal to add "Next steps" agenda item towards the end of the
    meeting - no objections
1. Three WGLC issues (chairs, 10 mins)
      - Discussion about whether the requirements should use COSE algorithms
          -
          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
          - SF: current text very proscriptive on using COSE; that will make it
          difficult on having consensus as it says that we cannot use cTLS -
          GS: current text recommends COSE; OSCORE needs COSE algorithms; we
          cannot go without mentioning COSE; natural thing would be to use
          COSE; cannot go without the AKE delivering COSE algorithms to OSCORE
          - RB: algorithms they don't need to be the same algorihtms that are
          used for negotiation - EKR: current text strongly recommends COSE
          used by the AKE; remove text entirely - JM: kind of natural to use
          COSE; agreed that it may not be a requirement; state code complexity
          and code size as requirements and state that it can for example be
          achieved by using COSE - EKR: agrees - SF: we don't want to be too
          prescriptive but we want to mention COSE, is everyone happy with
          that? - EKR: can live with that
         - no objections
    - Discussion on two AKEs
         - SF: the output from the IETF would likely be two AKEs: cTLS from TLS
         WG and EDHOC from LAKE; in the text we talk about "the AKE"; recognize
         that two AKEs might meet the requirements would help us not get stuck;
         - GS: good way forward; both cTLS and ultra-compact AKE that fits with
         OSCORE - EKR we do not think it is healthy for the IETF to standard a
         pile of AKE - CB: 2 is not a big pile. - RB: -- it seems that the
         chairs are in charge of calling consensus, and they seem to be doing
         this in advance - SF: but it does not seem that the EDHOC people are
         not going away because cTLS exists - JM: at Ericsson, we are not
         arguing against cTLS, we think we would use it, but we don't think it
         will solve all problems.  We would like to see both. - RB: is there a
         need for another protocol other than cTLS?  Or can TLS be made compact
         enough to meet the requirements? - JM it is possible to do a protocol
         in three messages, for 51-byte LoRAWAN and 5-hop 6TiSCH; don't think
         cTLS will reach that small messages; - RB: the reason for asking
         precision in the requirements document is to come to a decision that
         you seem to have already come to; not clear that's the case; cTLS
         getting within a small fraction of where EDHOC is; - BK: I think that
         the question that Stephen is trying to ask you, would there be a case
         where cTLS is small enough that there is no longer a case for EDHOC,
         is it possible for you to change that opinion based upon data from
         future work? - JM: current EDHOC as small at they need to be; seems
         obvious that adding another encoding or crypto implementations would
         add additional code size and complexity - EKR: the objective is not to
         be as small as possible but small within the performance clifs;
         understand performance curve against which we are designing for; if it
         seems that the goals are something that I can not reach with cTLS ,
         then I will go down. - GS: there are stict limits how large the
         messages can be; been there for a long time; been discussing for over
         a year now; look at the raw public key cases, e.g. for Lora; AKE which
         fits in 51-byte LoRaWAN at link-layer and 5-hop 6tisch; - EKR: not
         possible for any signature-based protocol; requirements for
         signature-based protocol; curve of cost for every incremental byte and
         every incremental message; we will have to go over the cliffs unless
         we say we are designing only PSK-based protocol - GS: many scenarios
         to support, including certificate-based scenarios that would not fit
         in the frame sizes; LoRA alliance trying to design RPK-based
         replacement of the PSK scheme; important to get RPKs within the frame
         sizes - EKR: original design of EDHOC was signature-based which would
         not fit; - GS: since -01 there's mentioning of mixed modes; address
         benchmarks with RPK; doens't say it has to be signature-based;
         requirements are clear on this point: what is the optimal number of
         messages; existence proof of protocol which complies with this; how
         long to wait for another candidate to appear? - HT: been changing the
         proposal over the years - GS: requirements coming from other people -
         RB: if EDHOC is going to be only solution by this working group,
         requreiemtns are secondary - GS: proposes to move to the requirement
         slides - SF: we have not resolved the underlying dispute - EKR: we
         have N crypto scenarios; a set of packet sizes; curve of cost against
         message sizes; for each of the scenarios what is the target we are
         aiming to hit? - JM: static DH might not be the target, it's PSK and
         RPK; - BK: there are "8" scenarios, maybe 2-3 have concrete
         limitations, but there are maybe "5" other places where we don't
         exactly what we want. - RB: there's been a lot of change in EDHOC over
         time; - EKR: if we care only about PSKs and RPKs, this is a lot fo
         simpler and we should write that down - BK: do you think what is
         currently in the requirements document is intending to be this list -
         EKR: not sure - JM: if we prioritize something, it should be PSK +
         ECDH or RPK + ECDH - EKR: wondering if the answer is to radically
         descope the contents; - SF: EDHOC proponents believe that we have
         provided existence proof . (with the caveat that cTLS could be
         anything, but then EDHOC could also) - EKR/RB do not believe that they
         have seen this existence proof. - SF: if there was an existence proof
         of a scenario that is realistic that cannot be met with cTLS, then
         that might give the WG a way forward. do we agree with that? - EKR
         agrees - HT: at the beginning everything is presented as lightweight,
         and then more features are added - SF: back to: show me the scenario
         where cTLS cannot do what is needed. been repeating this discussion; -
         EKR: restate that it is unhealthy for IETF to standardize a large pile
         of AKEs - MR: Define "large". - EKR: We already have too many. - MR:
         We have IKE, HIP, TLS and SSH - EKR: it would make sense to design
         this if there was a special set of use cases; not a generic case; reqs
         document is for generic use cases; narrow the scope. - SF: sympathy
         for the argument but cannot say it has IETF consensus; EDHOC
         proponents believe they have provided the existence proof; cTLS
         proponents do not believe they have seen that existence proof. - GS/JM
         agrees - EKR/RB: would need to have a clear statement what the "thing"
         is. - SF: you were asking for a little "more" - BK: if the only use
         case we cared about is the symmetric PSK case, and we had no other
         thing uses, then we would have an existence proof that cTLS is not a
         good fit? - EKR: actual phrasing is correct. - BK: but, once you add
         other things, then options causes the bloat, and this seems to become
         general purpose, and it looks more like cTLS - EKR: The thing that BK
         said that was compeling, was the very limited application made bring
         the rest of TLS a problem.
...
         - BK: seems like we have two different functionalities: core area,
         primary target and extends a little bit from there; and TLS a
         full-featured web scenarios; can overlap at the distribution; overlap
         is problematic; - BK: if we have a solid core of work that we want to
         focus on, that has the constrained nature in terms of being pure PSKs
         or RPKs; it feels natural to work on that; if it happens to evolve
         into something more extensible, we should not be concerned with that;
         - BK: agree with EKR/RB that we should not go into producing a general
         purpose AKE; OK to start from a core of work that may be extensible in
         future; - EKR: what does it mean? does it mean stripping down
         signature and certificate modes of requirements? - BK: consider what
         are the current and future expected deployment scenarios; if there are
         only 2-3 scenario that have predicted major deployment , then maybe we
         don't have to spend time on the other 15 uses? - SF: not possible to
         design a protocol that can't be extended into the areas that would
         cause concerns to TLS proponents - BK: EKR point is that the current
         requirements document is very generic and doesn't give a sense of what
         is the focus vs what we are throwing in there because we can - SF:
         that's the nature of IETF process; - SF: maybe there is a missing
         requirement that focus is on PSK/RPK modes or on a generic setting -
         EKR: looking for a work scoped down; specification is of a fully
         general AKE - GS: we have settings where there is no good solution
         today; - EKR: SF/BK suggest to create target scope for EDHOC to work
         on that would not conflict with TLS - SF agrees - SF: there are some
         niches where we cannot compress a generic protocol in a satisfactory
         manner - EKR: disagrees; if all you care is a small set of use cases,
         it's not worth the effort; - "Ben's proposal for a way forward" Strip
         down the requirements document a lot, to have a qualitative sense of
         "these are the combinations of crypto primitives that we consider
         important *right now*" (e.g., PSK and RPK) Have an acknowledgment that
         extensibility is inevitable, but disclaim that we are focusing on
         getting it right for these narrow cases right now, and if someone
         wants to do a broader case in the future, then more analysis will need
         to be done at that time.  But for now, we focus on getting RPK and PSK
         into 3 flights, 51-byte messages, and do that well. If we end up with
         protocol X that does RPK well and someone has it deployed but wants to
         expand their deployment to also use certificates, they can extend
         protocol X to do that and have a fairly homogeneous deployment, vs.
         having to have a mix of protocol X and TLS.  It may well be that TLS
         would do fine for their extended use case, but not the original use
         case, and having a homogeneous deployment is valuable.

         - EKR: this is in the zone of what I was thinking
         - ACTION: send this text to the list, ask if it makes sense, circle
         back and (maybe) have another call.

Proceeding with requirement slides at: 18:20 UTC
2. requirements wglc processing (Göran Selander, NN mins)
    - "Status" slide
    - "AKE for OSCORE" slide
    - "Credentials" slide
    - "Mutual authentication 1/4" slide
           - session identifier put in by KB
          - purpose is formal verification; connection identifier removed from
          the draft - ACTION: EKR to propose rephrasing
    - "Mutual authentication 2/4" slide
          - discussion about misbindings
          - we do want to support case hash of public key or the public key
          itself - EKR: if you treat public keys as identities then you get
          identity misbinding problems; include the identities of endpoints
          inside the transcript; - KB: whenever we talk about authentication,
          we have to talk about identities; open here because there are many
          ways of representing the same identity; there is a gap on what we are
          authenticating and what we wanted to authenticate - GS: do we need to
          change the requirement? - EKR: if we do the protocol design with any
          kind of RPK, it'd be important to stipulate what are the guarantees
          that we are attempting to provide - JM: agrees
    - "Mutual authentication 3/4" slide
          - new formulation on replay protection
          - EKR: agrees
    - "Mutual authentication 4/4" slide
           - property that the signature matches the public key
           - KB: two questions; one is about the authorization; the other one:
           both parties should agree on identities of both parties - ACTION:
           Karthik to propose rephrasing
    - "Confidentiality" slide
        - EKR: we are specifying resumption
        - GS: determine now or leave to design phase?
         - EKR: fine with proposed text
    - "Crypto agility and negotiation integrity 1/3" slide:
          - comment from Christopher Wood
         - Ekr agrees that it should be out of scope
        - previously missing statement that protocol shall allow negotiation of
        elliptic curves
    - "Crypto agility and negotiation integrity 2/3" slide:
          - proposed that we should have the most preferred algos
          - section contains text on integrity and downgrade attack, proposal
          to remove first bullet - EKR: agrees
    - "Crypto agility and negotiation integrity 3/3" slide:
           - Should we quantify "strong"?
          - KB: bits of security is controversial; you might be able to get
          away with shorter MACs; - ACTION: EKR and Karthik to propose text
    - "Identity protection" slide
          - spelling out what is SIGMA-I and SIGMA-R in this respect
          - 2nd paragraph stating that some information need to be transported
          in plain text - EKR and KB agree
    - "Auxiliary Data" slide
          - removed access token from the text
         - concerns on the use of CSR
         - Richard proposed formulation for protection of aux data which was
         adopted
        - no comments
    - "Extensibility 1/2" slide
          - text from MR; EKR commented;
         - discuss whether text is actionable
         - EKR: agree with the philosophy at large;
         - HT: nobody would disagree with that text
         - GS: keep text
         - EKR: agrees
    - "Extensibility 2/2" slide
         - EKR: misread the text
    - "Denial of Service" slide
       - RB commented that 1st paragraph was overlapping
       - rename section to "Availability"
       - GS: send comments if do not agree with the new title
    - "Lightweight" slide
           - clarifying benchmarks
           - EKR: Do not want to argue about this at this point
    - "Benchmarks" slide
          - done in prep for SECDISPATCH interim March 2019
          - benchmarks are kind of properties requested: time-on-air, backoff
          time
         - spreadsheets are intended to be used for specific protocols
         - describe how to fill in message sizes and calculate time-on-air
         - provides the kind of data that EKR requested
         - EKR agrees to take another look at that
    - "Next steps" slide

- SF: Resolve actions in two weeks

3. (if 1 terminates/looks-good) solution discussion
        2.1 edhoc (John Mattsson, 10 mins)
             - "changes since -01" slide
                 - implement all the suggestion from the WG
                 - fullfill the requirements, optimize the protocol even more,
                 clarifications based on implementation and formal verification
                 feedback - added mixed mode - design changed to MAC-then-sign,
                 instead of sign-then-MAC - identifier encoding optimized
                - added optional integrity-protected subject name to protect
                against misbinding attacks - several clarifications and lot of
                test vectors; implemented the whole spec
           - "Method types" slide
               - new method types ; 1 and 2 are the new mixed mode
              - optimize the requirement that one party should authenticate
              with certificate and the other with RPK
            - "Mixed Asymmetric Methods" slide
               - EKR: what if the initiator takes some action based on aux data
               - JM: aux data is signed
            - "Message sizes" slide
                 - can save some more bytes
                 - PSK and RPK modes fit in LoRAWAN
                 - 1 byte shy of fitting in 6tisch

        2.2 ctls (Eric Rescorla, 10 mins)
             - several implementations in progress
             - adopted by TLS WG
             - will submit WG version as soon as TLS charter is approved
             - HT: working on C-based implementation

4. AOB
    -   none