Minutes IETF100: ipsecme
minutes-100-ipsecme-00

100 IPsecME WG meeting in Singapore
Monday, November 13, 2017
09:30-11:00 (+8) Orchard

- Agenda bashing, Logistics -- Chairs (5 min)
---------------------------------------------
David Waltmire: Some updates on drafts, mainly going to go over recharter

- Draft status -- Chairs (5 min)
--------------------------------
EDDSA draft recently rev-ed, IETF last call has been requested by EKR.
Concluded WGLC on Split DNS and Implicit IV
Quantum Resistant IKEv2 getting close to WGLC, some recent changes that need to
be reviewed.

- Work / Other items (30 min)
-----------------------------
* Split DNS - draft-ietf-ipsecme-split-dns
Paul: We just submitted -03 to address Valery's comments which were mainly
typographical, had a discussion last time so everything should be resolved.
David: We'll confirm on the list that we're all good then send forward

* Implicit IV - draft-mglt-ipsecme-implicit-iv
Daniel: Addressed a few recent comments. Using Implicit IV is not compatible
with all IKEv2 extensions. The current text is to not use implicit IV for IKE
traffic Paul: It would be nice to make it work with IKEv2, since it is trying
to help the IoT devices. Just because we think there is more ESP than IKE, some
IoT devices may just do short exchanges. I'd like to see this figured out.
Tero: We have more work coming for compressed IoT approaches for IKEv2 and ESP,
which may be simpler than adding it into this Implicit IV document. We can get
this out now, and finish up later. Valery: The current document doesn't explain
how to use it with IKEv2 at all. It uses Extended Sequence Number for ESP, and
doesn't explain how to use for IKEv2. So in its current form, can't be used for
IKE.

* Postquantum preshared keys - draft-fluhrer-qr-ikev2
Valery: Summary of background/PPK solution. Previous version had a problem in
which a missing PPK was a silent failure. Proposed solution is to let initiator
send optional NO_PPK_AUTH, which is an AUTH payload without PPK assumed. Upon
receiving, either fallback to old auth, or abort exchange. Expanded security
considerations to contain mitigations for DoS attacks and downgrade attacks.
Added operations considerations about how to distribute PPK keys.

Document likely should be moved from Informational to Standards Track.

Paul: Agreed that should be standards. Libreswan currently does fluher draft,
but will update to current draft. Want to do interop. Q: Does the NO_PPK_AUTH
create some sort of oracle that helps an attacker crack the crypto based on two
signed values.

Mark McFadden: Support standards track. In operational considerations, you
mention possible way to distribute PPK. It seems like the mechanism is
something that should be in a separate document to explain. Is it the intention
to have a distribution document?

Valery: I don't know—it was written to help operaters think of how to adopt
PPKs. Not sure it should be in a different document. Note that this is a
short-term solution.

Scott: If the Quantum computer can break everything, it can already get the
full IKE_SA_INIT values already by recovering DH. THey'll already be able to
see everything in the standard AUTH payload (NO_PPK_AUTH). So having both
doesn't expose anything new. Is that clear?

David: We should hum on moving to standards track.
Tero: Think it should be standards, just started as info.
Paul: Informational is counter-productive, since we want people to adopt it
asap.

Hum: Strong in favor of standards, silent against.

Tero: Next question is if we should update the base IKEv2 document. Signatures
already does. This should make everyone aware of it.

Paul: I think so too, because we really want people to do it.

Tommy: I'm OK with this updating the base document, but the concern is if we
will in the future have another document that doesn't use PPK that is the full
QR solution.

Mark Orzechowski: Would like to see the same status given to asymmetric
solutions to QR.

Hum on updating:
    Some in favor, stronger against updating the base IKEv2 document

- Rechartering / New items (45 min)
-----------------------------------

Current charter expiring in December, so we need to recharter. Many discussions
on the list about new work to do.

A few items still in charter in progress. Current first two paragraphs are
general, and could be kept, but can refresh.

Hu Jun: Should we still be mentioning IKEv1 here?

Tero: I was thinking that. We will not do work on IKEv1. But if there is, it
should be here.

Lorenzo: Just deprecate/historic IKEv1

Tommy: Could mention that not only we work on mainly IKEv2, but IKEv2 + ESP.

Paul: Technically, there should be ipsecops and ipsecme, but there's likely not
enough people here.

EKR: I'm happy to leave it as one, the ops side is small enough.

===
Tero: There's an existing QR work item we still need to finish. Keep.
Remove implicit IV, split DNS, etc, since they're done.

New stuff:

Group DOI, based on IKEv1 historically, should probably be adopted for IKEv2.
Brian Weis: A few implementations already of this. In the spirit of making
IKEv1 historic, we need this in IKEv2. Tero: Is this clear enough? Hu Jun: It
looks like the use case is just multicast from the description, but does this
include VPN as well? Yoav Nir: Supposed to replace GDOI, which is multicast and
unicast. We should do this because this is the best place for it left.

Hum:
    Do we understand this work? Strong favor, no against
    Should we do the work here? Strong favor, no against
Tero: We should take this in the charter
EKR: Hands for working on this?
4-5 willing to review. All are non-authors.

Post-Quantum IKEv2 (using new algorithms, not just PPK). Also how to handle
large payloads before auth. Quynh: This is going to be really good work. But
there may be dozens of submissions (37 or more?). Do we want to test them all?
Pay attention to NIST significant ones. Tero: Some problems we need to work on
in the IKE protocol anyway, regardless of the end crypto algorithm. Valery: Can
see as two step process: first make IKEv2 ready for big payloads in INIT. Then
adopt new algorithms. Rick Salz: Depending on how we do it, we can avoid large
payloads. We should wait for NIST, and do this in the next recharter. Not ready
yet. EKR: No hats. What Rick says make sense. The one thing to work on maybe is
much much larger keys, but we may not need it. Then, with hats, we should not
be selecting algorithms here. Debi: This is key exchange, not signatures, so
you can't use hash-based. This is important to start working on and thinking
about. It's algorithm independent, and we need creativity in how to handle.
Tero: I don't think we can separate out the big INIT payloads from the
algorithms. Mark: I support this as a charter item. Some of the concerns could
be addressed by re-wording that the solution is algorithm agnostic.

Hum:
    Can we decide whether or not to take this? Mainly yes.
    Do we work on this in the charter? Strong favor, barely any against.

How many review? Over 6
Help write? 4

Diet-ESP (also include Diet-IKE), generally working for IoT type networks.
Hum:
    Do we understand this work: Strong favor, barely against
    Charter as WG item? Strong favor, one against
Review? 5
Write? 4

Signature algorithm negotiation: We negotiate hash algorithms, but not keys.
The thought is, like PSKs, you know which key you'll use for the IDs. Valery:
The key may be the same in some cases across algorithms, and could be the case
with future schemes. Paul: While you're thinking of the pre-configured
Server-Client case, we may be doing opportunistic, and so there is work indeed
to do here. Hum:
    Do we understand this work: Solid favor, no against
    Charter as WG item? Strong favor, weak against

Responder MOBIKE: The question is if you can use redirect.
Valery: Redirect has a penalty of creating a new IKE SA. MOBIKE provides a
lighter-weight solution General support for updating parts of MOBIKE, extending
this to be clarifications, not just responder document. Hum:
    Do we understand enough to work on new MOBIKE stuff? Strong favor, no
    against. Do we want to take some MOBIKE update in the charter? Strong
    favor, medium against. 60/40

Probably go to the list. Need to work out charter text for a MOBIKE update
maybe in addition to this.

Other items that are new:
    Address failure errors were requested to IANA. Tero wants it to go through
    IPsec first. Coming from 3GPP side. Labeled IPsec: feature in IKEv1, we
    want a better solution for IKEv2. We need to take discussion of this work
    item to the list. Mitigating privacy conerns in restricted deployments.
    Consider adding operational guiadance - PPK distribution, etc. Maybe BCPs.