Skip to main content

Minutes IETF108: lake
minutes-108-lake-00

Meeting Minutes Lightweight Authenticated Key Exchange (lake) WG
Date and time 2020-07-31 11:00
Title Minutes IETF108: lake
State Active
Other versions plain text
Last updated 2020-08-19

minutes-108-lake-00
# IETF108 Lightweight Authenticated Key Exchange (LAKE)

Friday July 31st, 1100-1240 UTC

Chairs: Mališa Vučinić, Stephen Farrell
Charter: https://datatracker.ietf.org/group/lake/about
Mailing list: https://www.ietf.org/mailman/listinfo/Lake
Jabber room: lake@jabber.ietf.org
Etherpad: https://codimd.ietf.org/notes-ietf-108-lake
Meetecho link: http://www.meetecho.com/ietf108/lake/

Agenda:
- Administrivia and agenda bash (chairs, 5 mins)
- Intro to EDHOC (Göran Selander, 25 mins)
- Open Issues (Göran Selander, 20 mins)
- Tamarin study of EDHOC (Karl Norrman, 20 mins)
- AOB

# Minutes

Minute takers: Francesca Palombini, Christian Amsüss

Jabber logs: https://www.ietf.org/jabber/logs/lake/2020-07-31.html

## Administrivia and agenda bash (chairs, 5 mins)

Intro and agenda bashing.

## Intro to EDHOC (Göran Selander, 25 mins)

Göran presenting the slides.

BK: On Auxiliary Data. On the slide, it showed up in the blue box. Is it
covered under encryption, mac, signature? GS: Additional data is included in
external_aad I think. Need to look it up. GS: Guarantees vary over AD. AD3 can
be encrypted and confidentiality protected, AD2 has less; could look up details.

DKG: see sl.12 TH2 should include the hash of the messages, which should
include the additional data. GS: That's orrect.

BK: At some points you can't send some data if you don't want them to be
public, because you haven't authenticated the peer yet. DKG: For AD1 and AD2
maybe, AD3 should be safe.

MS: see sl. 7 about method. Is there any requirement on initiator to understand
whether m=0/1/2/3 will happen? GS: Currently no negotiation or information
sharing on methods. This assumes that the initiator knows whether responder
uses RPK or signature. It's an option if we want, using the same kind of error
flow like in cipher suites, but is not currently included. MS: Consider adding
that. Also where initiator has several credentials, eg. in group scenarios --
there should be error flow for those cases. (Eg. find out that PSK is not good
enough and need to go with certificate). GS: Current spec only uses asymmetric
protocol, PSK based authentication is out of scope to start with. How to find
the credential is preovided in ID_CRED_R. GS: Could you give an example for the
group case? MS: If you don't support PSK, then it does not really make a
difference. Group PSK would have been an example. GS: Group excluded from the
scope.

MS: What's the enrollment goal -- start with a certificate and enroll with
another? (sl. 6) GS: one scenario: start with manifacturer built in credential,
which you use to enroll another certificate. GS: By the way, neither of the
certificates need to go over the constrained link. BK: reference to the
certificate, is it possible for the device never to dereference that reference?
GS: In principle yes.

Subir Das: ad deployment scenarios: Manufacturer 802.1ax certificate in device.
If I activate after 1y and certificate is invalid, is there a way to still
bootstrap the device? GS: revocation of credential used in the protocol is not
excluded in the requirements.

chenmeiling: Will the public key be used for signature or encryption?
GS: It may be a signature key (for signing) or a static DH key, in which case
it's used in the key scheme to derive a shared secret.

## Open Issues (Göran Selander, 20 mins)

(Link from presentation: <https://github.com/lake-wg/edhoc>)

Issue \#2
MV: most of the hardware I've seen implements SHA256. 2 or 3 seems the most
reasonable. I'd like to see us converge to one single alg to use.

MS: we saw this in 6lo and we have solved it:
https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-11 and 
https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-23#section-8.2 SF: Seems like
something to pass IESG. MS: That's the plan.

**AP: Mohit to comment in the issue with ref to the documents + everybody who
has input comment in the issue.**
    AP completed:-) efficient! \o/

**AP: Göran to start the discussion on issue\#3.**

SF: Encourage people to open issue on github but if it substantial also send
email to the mailing list.

## Tamarin study of EDHOC (Karl Norrman, 20 mins)

Karl presenting the slides.

SF: is there a plan on how to wrap this theory work, getting polished, peer
review, how long this will take? Not precise answer, just a general plan. KN:
Put on arxiv, and thankful for reviewes there. Planning to submit to conference
in August with wrap-up and polish. Not aware of anyone doing Tamarin modelling
or other modelling on this. SF: So done soon-ish or when the protocol is
finalized? KN: Trying to secure machine with more memory…(?). Also looking into
computation proofs.

Tobias Guggemos: sl 19 - not sure I understand this. (? hard to understand)
KN: Only responder can compute that(?)

[sorry I have a hard time following here]

**AP (even though not officially named that): Göran to go through it and make
issues of that**

## AOB

BK: gather town to socialize after the session at
<https://ietf.gather.town/z6N2SDxHebMdDAfo/IETF-108>.

SF: Thoughts on how to procede from here?
GS: Virtual meeting would be great. Will have some more input after the issues
are more tracked. Mid-late September? MCR: suggesting Hackathon online

SF: multiple implementation. Are people testing together? organizing an
hackathon would help them? GS: there is a number of implementations. Would have
to check if that would help.

SF: plan to remove the PSK option in the next version.
GS: should happen soon, + we need to include feedback, + waiting to get
feedback on the other verification team. End of September sounds reasonable.
SF: Ok so participants wait for -01 version to read and review.

*[GS]: Göran Selander
*[BK]: Benjamin Kaduk
*[DKG]: Daniel Kahn Gillmor
*[MS]: Mohit Sethi
*[MV]: Malisa Vucinic
*[SF]: Stephen Farrell
*[KN]: Karl Norrman
*[AP]: ACTION POINT