Minutes IETF105: lake
minutes-105-lake-01

Lightweight AKE for IoT (LAKE) IETF 105
22 July 2019, Monday 15:50-17:50, Van Horne Room

Chairs: Stephen Farrell, Yoav Nir
Minutes: Kathleen Moriarty & Christian Amsüss
Jabber scribe: Francesca Palombini

BoF description: https://trac.tools.ietf.org/bof/trac/wiki#LAKE
Mailing list: https://www.ietf.org/mailman/listinfo/lake

Jabber: lake@jabber.ietf.org
Jabber logs: https://jabber.ietf.org/logs/lake/

Agenda:

10 - administrivia and history - chairs

    Note well reviewed & bluesheets
    Outcome is to provide a recommendation to the IESG
    Requirements are not final, this is a BoF
    Most in the room are familiar with the work

20 - requirements presentation - Göran Selander
    https://datatracker.ietf.org/doc/draft-selander-lake-reqs/

    LAKE is about specifiying a lightweight AKE for OSCORE
    Not a new subject, has been discussed at legth since 2016
    Compiled requirements and had discussion in a virtual interim

    OSCORE Background - communication security protocol for COAP, think of it
    as a REST Layer protecting payload, but not the messaging layer or binding
    to UDP.  Proxies can change unprotected headers, good for IoT deployments.
    Initially designed for unicast and multicast at object level.  Transport
    not covered, hence exposure of headers to proxies.

    For p2p to get Forward secrecy, requirement of new protocol
    Showed interest in OSCORE (slide available)

    OSCORE transport requirements:

        - needs master secret to derive the encryption keys, master secret
          should have forward secrecy, randomness,
        - arbitrarily short peer identifiers (as sent in all OSCORE exchanges)
        - COSE algorithms used by OSCORE
        - need symmetric and asymetric
        - additional credential requirements being discussed on list
        - raw public keys - short identifier that refers to the public key
          (clarification at mic from EKR)
        - identifier versus public key being carried are separate requirements
          - needs to be distinguished (Ben Kaduk attempting to clarify) - both
            are requirements from Goran
        - Crypto agility - built into infrastructure with long lifetimes, so
          necessary for OSCORE and AKE algorithms
        - Lightweight most important - low in resource consumption, start to
          end quick, power consumption, amount of code to produce (from
          SecDispatch discussion)
        - bytes on wire is straightforward if you look at message sizes -
          impacts time to complete and power consumption
        - wall clock time . - few RTTs as possible, 1-rtt mutually
          authenticated -  at least 3 messages
        - power consumption depends on deployment circomstances
        - code complexity aspect based on reuse of a given OSCORE
          implementation
        - concrete measureable benchmarks needed (outcome of SecDispatch) -
          LWIG draft specifies the bechmarks - listed on slides.

    Benchmark 1: Energy consumption
    HIgh per byte energy consumption - slide with details on bechmark
    AKE few bytes as possible, message size matters

    Benchmark 2: LoRaWAN duty cycle back-off times
    High penalty for large messages, as they cause fragmentation
    AKE should fit in as few packages as possible

    High penalty for large messages, need for fragmentation

    Benchmark 3: Number of 6tisch message frames looking at 6TiSCH, similar to
    previous step-wise function; number of frames determines performance
    looking at join event when many devices connect to a central unit; long
    network connection times come from fragmentation number of frames needed
    for key exchange and make as few frames as possible is the goal factor of
    2.6 between comparison of protocols

    Summary Slide read

    Questions:

        - Bob Moskowitz : Have you considered the # of operations of device -
          is there another requirement?
        - David Black: (3rd bullet on summary slide) What does "good amount of
          randomness" mean?  Answer: entropy - not saying 128 bits, not on this
          level - any of those are fine
        - David Black:  Is the PSK a strong secret? Goran: Yes
        - Hannes Tschofenig: Requirments miss privacy aspects, prior analysis
          had this as a gap and it's an important decision (not a clarifying
          question per chairs)
        - Renee Struik:  Wasn't a clarifying question per chair Answer: people
          are deploying OSCORE without FS  and they'd like to use public key
          soon

10 - edhoc quick intro - Göran Selander
https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/

    - Skipping protocol details, how EDHOC matches the requirement, how it is a
      SIGMA implementation
    - Suitability for LAKE: Provides OSCORE identifiers
    - Supports negotiation of COSE algorithms, reuse helps keep footprint small
    - Small footprint b/c it reuses CBOR, COSE constructs
    - Constrained features
    - Security discussed at iterim  - SIGMA-I, 2 crypto panel reviews, formal
      verification
    - summary: matches requirements, performs well in benchmarks
    - comparing preshared keys and raw public keys
    - b1 # of bytes
    - in certificate case, don't fit in single frames
    - comparison w/ SIGMA-I skeleton (bottom right on evaluation slide) that
      only sends the basic objects

Questions:
    none (as the chairs insisted on clarifying questions only)

10 - ctls quick intro -  Eric Rescorla
    https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/

    - providing another point in design space
    - how to leverage ongoing work on line of protocols
    - reap benefits from the line of work but also have compactness and
      patching
    - cutting fat or compression are two general approaches to reuse TLS
    - keep protocol general, but cut off unused parts
    - Certificate is the big thing
    - pile of extra features
    - length fields - could trim
    - fix length fields in some cases are larger than necessary (24bit never
      nearly exhausted)
    - values are implicit in some cases and could be made implicit
    - downgrade problems have creeped in - can remove downgradability
    - Can nail things down more and could do lots of compression
    - how to do mechanically? Treat wire transcript ?
    - Scott Fluhrer: Would that keep crypto agility: EKR: depending on how you
      do it in detail, yes
    - keep TLS 1.3 proofs valid -- straightforward on symbolic proofs
    - no one cares about encoding anyway
    - Example given in slides of ClientHello could have 32k cipher suites - not
      necessary
    - could cross off a lot of things to get a compressed representation
    - removes functionality, but may be ok with requirements
    - sliding scale of compression from simple struct to full generality
    - Richard Barnes: isomorphism point - interposed the stack (couldn't hear
      it all)
    - first implementations available, slides show numbers. Biggest chunk:
      "Finished" messages
    - first cut - need to demonstrate, not worth doing if you can't with 1.3

Questions:
    - Hannes: TLS is not compact in earlier slide, Hannes disagrees.  TLS WG
      has worked through the year to compress it more over the years and doing
this step by step with DTLS EKR: Efforts have been on the biggest thing, but
more can be done
    - Yoav Nir:  Numbers missing on preliminary results for what they were in
      TLS 1.3 Answer: no they're not here
    - Jim Schaad: [yes] Question not captured EKR: strongly suggest you can
      shrink them
    - Missed a few of the questions [?]: For first strategy proof is the same
      fo rthe second, should be pretty easy

20 - charter and usual BoF questions - chairs
    draft charter:
    https://mailarchive.ietf.org/arch/msg/secdispatch/zug9SCdn6prNdKvwX-ys3ZIg84s

    Charter discussion:

    - Hannes Tschofenig: Focus on OSCORE alone feels restrictive. IoTs are
      deployed using TLS and DTLS. EKR's work on constraining that would be
      fine for them w/o having to worry about OSCORE. Göran's presentations
      mixed "is specified" and "is deployed", and OSCORE is not as widely
      deployed. Would like to have broader focus, not only on OSCORE.
    - Göran responding: This discussion is two parallel discussions. What's
      being done on TLS to make it more optimal is excellent. HAppy to use that
      for where TLS is used. But not providing the most optimal for the most
      constrained settings. Two separate questions: How do we solve the very
      constrained settings with current OSCORE w/o key exchange? The other is:
      How do we make TLS in itself more optimal? Two good questions, both to be
      discussed, should not interfere.
    - PHB: Concerned on list that we are only going to look at existing key
      exchange protocols, but introduce new requirements.  Don't like that they
      have to start with something that exists and it goes into a rat hole. 
      Looks like a new key exchange and not complete reuse, he would go to CTLS
      for branding.  If he wants to use DTLS he can find it in a toolkit, will
      probably get ctls for free.  Naming matters.
    - Ben Kaduk: in A bOF, not WG.  Agreement that there's a problem that needs
      solving and people willing to work on and understand scope of problem and
      what the WG will work on and don't have to work on it right here.  Think
      of higher level questions - do we want to solve it here at the IETF.  DO
      we understand scope of the problem?  Bob asked a completely different
      requirement, so did PHB.
    - [Benjaminn Damm]: Things heard but not true: got millions of meters that
      do not use TLS, probably some proprietary. If had OSCORE and EDHOC would
      have used it. (clarifying: Not using TLS b/c too heavyweight?) yes. For
      us, every bit on "wire" (air) costs money. 20 more bytes in handshake
      cost us money. more collisions in air, size really matters. Also, if
      isomorphism cTLS-TLS there could be one TLS-OSCORE (comments: no, it's
      not, we looked at it).
    - Carsten Bormann: Like Hannes' comment b/c CoAP has a security scheme
      using DTLS, want better DTLS. In tasks like this, think of unintended
      consequences.  Would like to talk about intended consequences.  Would be
      ctls have happened without this discussion (audience: NO). One intended
      consequence to keep mild pressure up for cTLS to happen. cTLS already has
      a home. EDHOC does not have a home and how do create one?  Important
      consequence
    - EKR: Doesn't think what we are discussing - don't see EDHOC written here
      (answering Carsten).  Agree partially with Hannes and Göran; would be sad
      if it only worked with OSCORE. . Designing these things is hard. The more
      input, the better. more applicability and generality the better
    - Cullen Jennings: Anytime we do a protocols, more specific between new
      protocol or generalizing another.  Perfectly happy ?  Other comment:
      shocked to see how awful job on TLS before, hope to get it much smaller
      really soon.
    - Yoav Nir: Don't decide on specialization in BoF
    - Hannes Tschofenig: ad "is there problem to be solved?" my company works
      for mbedTLS and deploys IoT in devices. DOn't have the same problems as
      other companies, can run secure IoT over those and other networks today.
      Primary reason: Can cut down, but try to look on bigger picture, whole
      lifetime of device, what at beginning (onboarding), connection,
      afterwards? Think 10 years lifetime from coin battery. Many problems are
      actually elsewhere (like large certificate). Firmware update is less
      sexy, but important but that's where the battery drains, not in key
      exchange protocol (b/c session resumption etc). That's why we don't see
      those problems. Also ad ITON: see possible improvements in design that
      avoid those issues. Happy to see, as Cullen said, Working to shrink TLS,
      happy to see it. Would have loved Göran & co to have come to TLS and help
      me out with convincing TLS to help me in shrinking.
    - Ivaylo: Have OSCORE implementation, interested in LPWAN, very
      constrained. Important to have small implementations and need to reuse
      components, that helps a lot. Therefore interested in this.
    - Malisa Vucinic: USing OSCORE in adopted WG document in 6TiSCH for 3 years
      now. Asked for AKE for OSCORE Satisfying the requirements as Göran
      presented. Good we have discussion today and opposing solutions.  Problem
      of designing an AKE for OSCORE
    - Jari Arko: Work should go ahead. Shouldn't preclude work on cTLS and
      DTLS. Generalize my comment: Sometimes in IETF focused on one thing too
      much to the detriment of the Internet, we are starting to see that impact.
      Sometimes need something else. to have end-to-end security on relays too
      with transport.
    - Kathleen Moriarty: Happy to see work go forward, similar to Jari, like
      having an object level encryption protection across relays coupled with a
      transport.  See no conflict of having both ctls and OSCORE & EDHOC
    - MCR: implemented 6TiSCH, BRSKI over DTLS. Can talk about threading
      problems etc / but are implementation issues. Like Philip said: can
      download standard library with advantage with existing system, but
      disadvanage of having to cope w/ existing system. Willing to rewrite it
      from scratch like Hannes' company did? CoAP implementers tend to process
      one request per thread in thread pool. Doesn't work well w/ security
      above and below application, but particularly you are forced to do
      threading below is forced with currentlibrary. [...] What we try to do is
      key OSCORE. Don't want to run CoAP over DTLS, want to key OSCORE and let
      CoAP run. That's where transport agility comes from, across layers[?]. 
      It's across different transport mechanisms (not layers).  CoAP/OSCORE can
      be transported across many things other than UDP, and if we do the AKE at
      the CoAP layer (rather than outside/around as DTLS does), then it is
      easier to get the properties we want.
    - Justin Richer: not picking side, followed from distance. Many ppl say
      it's easy b/c we did similar thing and if we change this and that ... but
      all I want to do is encourage WG to approach such claims with appropriate
      scepticism, b/c when altering existing systems to new use cases, they're
      being twisted in hard-to-predict ways, and details can kill you there.
      whoever claims to jsut have changed everything and it still works fine on
      our bespoke box, that may not scale well.
    - Hannes coming back to MCR: Sounds like easy to just re-implement those
      new protocols and then be done with it. But had ppl working on it 10y
      long, and Embeeded space is hard.  Have to integrate into IDEs. time
      consuming. Who writes new embedded security stack for EDHOC, maintain it,
      with all features around that for next 10 years?  Looks like extensions
      coming out of TLS is difficult.  So many contributors for TLS, it's
      difficult.
    - Richard Barnes: Clarifying: cTLS doesn't makes sense as a TLS work item.
      Questions of trade-offs between rigidity and size and where you want to
      be.  Structure depends on the ebnvironment where it is going to be used.
    - Dave Wheeler: heard "presentation seems like we take somethign and tweak
      it a little to make it completely different and do it quick without any
      RFCs". Scares me, maybe I misunderstand. Seems we need different keying
      protocol, and should address that appropriately w/ right amount of
      resources coming in.
    - Stephen Farrell: Idea here is to document and agree on requirements,
      don't make that an RFC, but the protocol will be.
    - PHB: needs to be a separate WG, not TLS.  Hope to reuse proofs, but
      acedemics are free with infite numbers of grad students.
    - Tero Kivenen: Header compressed TLS example - use1.3 frame and compress
      it sending with minimal stuff needed, and not modify TLS.
    - EKR: Academics are not free. Was enormous amount of work on TLS. It's
      difficult to get ppl to do things, and they do hard work.
    - Carsten Bormann: on cTLS. Work that will cTLS needs resources from TLS
      WG, and needs them more urgently than resources from constrained ppl.
      Will have requirements document, and they can inplement against that.
      Hard part is touching TLS and not breaking it. Have draft from 2013 from
      student that described DTLS compression. The way it's designed, there are
      finish messages that work on what was on wire, and then have to
      reconstruct. So thinking about finish msg is probably the most important
      thing to take home.
    - Richard Barnes: Two sides of the relationship - things you are not
      familiar with seem the hardest to both sides.  How does this AKE - what
      integration surface is needed?  Would be good to get general shape of
      protocol into the requirements.
    - Carsten: Also whole application layer TLS usage issue that comes in,
      which we have to address in time. On why IoT stuff is almost trivial in
      comparison: Security must work. If 3 bytes too large, that's not a
      disaster. Error in security is.
    - Riad Wahby: Impicit shared notion of all the costs.  Useful to have
      multiple models.  Usefult to specify assumption without cost of certain
      things.  If you just need size, it may be reasonable to compress TLS and
      be done, if that's not what you mean, document it.
    - Hannes: bytes on wire are easy to put together on paper. ad [?]tls: put
      together draft that was written some time ago, kind of makes sense here.
    - Ben Kaduk: BoF Questions??  Really wants to hear interest.  Excited to
      see discussion on scope and requireemnts that were not mentioned.  # of
      AKEs?  How to integrate OSCORE, TLS won't be able to do.  How tightly
      couled requireemnts with use cases?  How flexible we want to be with use
      cases? Assumptions on cost - write them down!
    - Goran: Starting with assumptions and costs, basically been doing in
      SecDispatch with benchmarks and not easy to get exactly right. Not easy
      to produce an excellent requirements document that guides to a solution.
      Ad solution space: Important that optimal solution probably isn't cTLS
      (not as lightweight as what I have shown). At some point pick between
      isomorphism of TLS or optimal solution, so ppl don't expect that it will
      be both. Already did good job in showing the isomorphism.  Don't think
      you'll get down to levels that are optimal with a widdling of TLS.
    - Ben Kaduk: have some text in draft charter about at most one?? [...].
    - Dave Thaler: ad Ben's repeated questions. To most: yes. Ad scope: All
      text on screen under "program of work" and under "goals" talks
      constrained environments, but not OSCORE and object level security. But
      requirements are about OSCORE. Is one too broad, or the other to narrow?
      Is it "solve for OSCORE and if it works for others it's great", or [?]
      Problem defined well, but maybe scope of work needs to be redefined
    - EKR: thinks it should be flipped.
    - Hannes: another facet to problem statement. Would like to see something
      about object security. OSCORE is not object level security. In @ we
      describe how to derive keys for COSE, and that's object level security.
      For that we'll need key management protocol. Someone also said OSCORE is
      protocol agnostic. It's over-advertisement when what comes in and out is
      a REST protocol. Talked about ITRON case, it's probably not restful. Most
      MQTT users ... not RESTful protocol. Just about what protocol agnostic
      means.
    - David Black: Survived TCPInc - advice: it'd be irresponsible of IESG to
      start working group without picking the starting protocol.  Saying IESG
      should make tough decisions? no. But hard decisions need to be made.
    - Yoav: If requiremnts not final, how do we decide between them.
    - Alissa Cooper: @@@ time to take decision ?
    - David: Hoping not to spend 2y on charter. Limit to amount of BoFs you can
      have.  Want it to serve as a forcing function
    - Alissa: So this process will time out and that's a better thing than
      starting a WG just to stall w/o a decision?
    - David doesn't think it's a good use of resources to start without a
      decion.
    - Carsten: did ISO standardizaion. They use requirements a lot.
      "Requirements engineering" is engineering requirements such that solution
      comes out as chosen. Work on requirements is tainted by this.  Shouldn't
      spend a lot of time honing requirements Having an idea about reqments is
      good, but should not spend much time there.
    - Yoav: By time requirments are finished, not off the table, if both meet
      it, could decide by coin toss.
    - Cullen: Bad idea.  Decision of CODEC to use would not have come to a good
      decision after 4 years and would never have chartered WebRTC had that not
      happened.  WebRTC had a more difficult decision on video codec, and would
      never have managed w/o roughly 4 years of repeated discussions in WG
      meetings. Would never have chartered if we knew we had to make decision
      before [?]
    - Goran: we're spending 4 years and many applications not using anything,
      don't have FS for OSCORE, not a good result.  Not the same solutions,
      have difficulty seeing that and don't see the issue with multiple
      solutions.
    - Phillip: push back on "picking one is necessary to speed things up".  If
      you pick a winner and then start changing it, it takes forever At one
      point starting from house and remodeling seems good, but after some time
      built house twice.  Seen in other WGs: "we must do it now" -- 5y later
      still at it, WG failed b/c chose wrong protocol to try to do it fast.
      Shortcuts aren't good.
    - EKR: 13' to go, can't realistically arive [?]. Focus on progress:
      Options: go home; schedule another meeting on starting point; [?]
    - Benjamin: There is an audience problem. CoAP isn't HTTP. Why came up w/
      CoAP when HTTP could do everything that CoAP does? My position: very
      different audiences. Embedded audience cares about very differnt things
      and they are at odds - COAP/HTTP.   They serve a different audience. When
      do we embrace that split with AKEs?
    - Dave Thaler: Will have question of "do ppl understand the problem". Ppl
      understand, but there's two problems, the narrow problem of OSCORE and
      the wide of the milestones. Would be good for everyone if they have
      well-defined problem, but it's different ones for different people.  Two
      communities in this room. When questions on next slide (Big Questions)
      asked, please phrase them so I know how to answer. Two views of what the
      problem is.
    - Yoav: We are here to solve that as the OSCORE problem.  Big questions
      being rephrased to make progress by Dave Thaler
    - Dave Thaler: suggesting questions.

usual BoF questions: https://tools.ietf.org/html/rfc5434#section-1

* Do you understand the issues?
  strong yes hum on question, no on negative question

* Is OSCORE Key exchange a ('the narrow') problem that needs being solved?
  strong on yes, none on negative question

* Is broader constrained scenario a problem that needs solving?
  strong on yes, low on no

    - MCR: explaining his no on last question on demand: my experience from
      Hannes' environments: if enough code space and other power to run TLS, it
      doesn't matter. Kind of a step function. If you can run a bit, you can
      probably do a bit more. Hannes' "you don't AKE often" is probably true.
      If running MQTT, security overhead is not what's killing your network

    - Hannes will post paper on crypto libraries - crypto algorithms are
      problem and not the TLS stack.  Here is the paper Hannes mentioned:
      Secure Firmware Updates for Constrained IoT Devices Using Open Standards:
      A Reality Check”
      https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8725488

    - ?: Do they need TLS? There should be a way to do it in OSCORE that
    doesn't require extra protocol.

* "Is IETF the right place?"
    Strong yes on IETF is the place to do the work.

* Willing to work on documents - comment, review, etc.
    - 15-17 hands for OSCORE
    - 10-11 hands for the general case
    - Few overlapping.