Minutes interim-2020-lake-03: Tue 18:00
minutes-interim-2020-lake-03-202003311800-00
| Meeting Minutes | Lightweight Authenticated Key Exchange (lake) WG | |
|---|---|---|
| Date and time | 2020-03-31 17:00 | |
| 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