Minutes for IPSECME at IETF-95
minutes-95-ipsecme-1

IPsecME @ IETF 95
April 4, 2016
1400 - 1530

Minutes taken by Adam Montville and Yaron Sheffer

Summary:

- Didn't meet in Yokohama (IETF 94)
- WGLC issued on draft-ietf-ipsecme-ddos-protection. Wrapping up changes based
on feedback before sending to IESG. May need to consider splitting puzzles out
as an experimental draft. - WGLC on draft-ietf-ipsecme-rfc4307bis and
draft-ietf-ipsecme-safecurves to be issued soon. - New work to consider. Some
interest in the WG on the following, but more feedback is needed on the list
over the ideas/drafts:
    draft-mglt-ipsecme-rfc7321bis-00
    draft-ietf-ipsecme-safecurves
    draft-pauly-ipsecme-tcp-encaps
- Need to recharter, more discussion on specifics on the list to follow.

Raw notes:

From Adam Montville:

IETF 95 - IPSECME NOTES
14:00-15:30, Quebracho A

Agenda as Posted

        5 minutes: agenda
        15 minutes: discussion of conclusion of WGLC on
        draft-ietf-ipsecme-ddos-protection 5 minutes: request for more comments
        on WGLC on draft-ietf-ipsecme-rfc4307bis 5 minutes:
        draft-ietf-ipsecme-safecurves 15 minutes: draft-fluhrer-qr-ikev2 15
        minutes: draft-pauly-ipsecme-tcp-encaps 10 minutes:
        draft-smyslov-ipsecme-ikev2-compression 10 minutes: changing the
        requirements for registry entries Rest: charter

About 25-30 folks in the room and seven folks in MeetEcho (no clue on overlap).

Chairs are starting the meeting.  Full agenda is planned, so we'll stick to it
closely.  Note Well is being displayed (the new one?)  We have two note takers
and one jabber scribe (Jim Schaad)

Status report:
https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-1.pdf

        Didn't meet in Yokohama, but a lot of work has been done over the last
        few months. Good progress overall Three "active" drafts.  DDOS has been
        getting a lot of traffic 4307bis will be issued soon - seems verified
        by authors in the room safecurves is ready soon for WGLC Likely to add
        draft-fluhrer-qr-ikev2 We need to recharter, which happens from time to
        time

Agenda bashing: None.

        Sheila Frankel: Not really agenda bashing, but...
                Do most implementations cover elliptic curve?
                Do some implementations have known ESP?
        Chairs: Why don't you send these questions to the list to get your
        answers...

        Paul Wouters: There's another draft we might consider: Update to ESP
        algorithms. Chairs: Agree, we should get some feedback on the list.

DDOS Protection (Valery Smyslov) presentation:
https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-2.pdf

        Sailing through the presentation with little to no engagement so far
        from the folks in the room.  No questions.

        Dave w.: There seems to be good progress on this...do you have enough
        feedback to address Paul's concerns?

        Paul W.: One issue is whether or not puzzles will work as we expect.  I
        am not convinced that puzzles will work.

        Yoav Nir: In the past my company has implemented puzzles similar to
        this and this worked.  What we're missing now are measurements about
        how fast ARM processors are to solve these puzzles.  There's some
        disagreement about whether puzzles are suitable for preventing attacks.
         I'm not sure I can say how many attacks were stopped.

        Tommy Pauly: To the point of getting numbers on this, we can implement
        it on both and see how it works out.  I should think that the mobile
        devices would be comparable.

        Tero Kivinen: I think the puzzles are mostly for the future.  WE
        haven't seen attacks against this yet, and if you have a mechanism
        already defined, then you can try to protect...I don't know if puzzles
        will be implemented early on, but if they're there we're ready.

        Valery S.: The hope is that puzzles will help.  We also believe that
        puzzles will help in certain circumstances, and it's better to have
        them in place.

        Jim Schaad for Kathleen M.:  This draft is standards track, so maybe
        the viability of including puzzles is something that suggests this
        should be experimental.

        Paul H.: This sounds like a good discussion for last call.

RFC4307bis presentation (Tero Kivinen):
https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-6.pdf

        Paul W.: We left it at 128-bit keys and I would like list discussion to
        determine whether we bump this to 256.  Is there any reason to stick to
        128?

        Dave W.: Start a thread.

        Paul W: Once you start switching the default, you run into invalid KE,
        so it's not supported anymore.  This is the most risky change (context:
        IKEv2 Diffie-Hellman Groups)

        Paul H: Document has a fair amount of discussion on this topic.

        Yaron Sheffer: Should this and the other draft be aligned and published
        together?

        Paul H: That can be discussed, but the other draft hasn't even been
        picked up yet.

        Daniel Migault: If you don't understand some text, it's important that
        you mention it.

Safe Curves (Yoav Nir):
https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-0.pdf

        Yoav N.: He's asking whether we want to wait or move forward for
        signatures

        Paul W.: I thought the whole point was that we would let other working
        groups take care of this?

        Paul H.: We can wait for the curdle work, which is happening later.

        It looks like no one objected to this working going to WGLC.

Quantum resistance (David McGrew):
https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-7.pdf

        Going through the deck with very little feedback so far.

        Valery S: i think this draft is important.  My idea was not to
        introduce a new register, but to ... [missed that]...this will give
        more simplicity

        David M.: When we wrote the draft, we recognized that IO registries
        aren't expensive.

        Dan Harkins: IKEv1 to get around the problem and using extensions that
        contain multiple named keys, so what you can do is connect this to two
        message exchanges...  Give out the PPK and some sort of hint key and
        this could be smaller and shorter and key-wrap a name, which would be
        an index into thousands of PPKs.  Why go through the crypto algorithms?
         To make it probabilistic, you could do something like XXXX mode and
        ensure that your wrapped data is going to be unique every time.

        David M.: Have you looked at this from quantum perspective?

        Dan H.: Probably not. (Laughter)

        David M.: One of our security goals was to preserve integrity in the
        face of quantum computing.  Let's talk more offline.

        Tero Kivinen: I think that quantum risk is really important for IPSEC
        but not as critical for IKE.  Traffic selectors...most of these are
        visible already, so it doesn't gain much to hide IKE elements.  We
        might end up with the same problem for IKEv2 that we have with IKEv1. 
        From an implementation perspective, we might be putting ourselves in a
        position where people will in effect reuse PPK.  [He offered something
        interesting here, but I missed it - sorry.]  If someone mistypes PPKs
        at either end...we need to verify these things.

        David M.: It is possible to choose computed values.  It is possible to
        configure a system to make a choice toward performance; the idea being
        that it's up to the user to make that choice.

        They're having a good discussion on this, but Paul had to cut it short.

        Valery S.: Quantum security key...  PPK key as a current draft protects
        us today, and you can use algorithms that resist quantum today.

        Paul is encouraging that we do this later.

TCP Encapsulation (Tommy Pauly):
https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-3.pdf

        Yoav N.: If you don't want an arms race with firewalls, ...  I don't
        get why you would want the TLS.

        Tommy: I have some slides on this later, and we can take the arms race
        so far but not further.  Maybe we're going to do something that would
        make it look how it should be.

        Paul W.: If you go to Starbucks around the corner, you can't do
        anything but 443.  The arms race is here.  WE might as well explicitly
        state that we support customized ports.

        Tommy: We should take extraordinary measures to mask...

        Brandon Williams: Any idea of goals vs. non-goals for proxy/transparent
        proxies?

        Tommy: Draft briefly mentions proxies.  I'd like to have a small as
        explanation of that in this draft.  If it changes IKE, then it should
        be in this draft, otherwise a second draft.

        Brandon W.: Might be worth second discussion: When TLS is being used
        flag it as {missed}HTTP, so the proxy won't terminate the session.

        Tero K.: 3GPP talks about a couple of formats.  Should we try to align
        with them?

        Tommy: Can you send that to the list?

        Tero K.: Yes.

        Valery S.: This is difficult to make cleanly.  To deal with FWs and
        proxies will be ugly.  A document to describe how to get around these
        things seems to be the right approach

        Tommy: Practically, we want to in this draft ensure people don't fall
        into pitfalls

        Paul W. is asking whether running a call for adoption?  Paul H. is
        suggesting that there is some discussion that needs to be happen. 
        We'll have the discussion about this document and what pieces of it we
        should adopt or not.

        Daniel Migault: When are we going to have this discussion?

        Paul H.: As soon as [something] happens, we'll have the discussion. 
        Essentially, we want to scope the draft before we adopt it.

IKEv2 Compression (Valery S.):
https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-4.pdf

        Paul W.: For the SA if it's large size, compression is good, but how
        does this fit with IoT which won't be very good?  IoT tend not to use
        certificates, so the things this does well are the things that IoT
        doesn't do.

        Valery S.: I don't think it's completely useless for IoT

        Tero K.: I agree [with Paul].  I don't think IoT devices benefit from
        this.

        Tommy: It seems that everything outside IKE we should fragment if we
        absolutely need to send it.  Is this really just about trying to reduce
        energy?

        Valery S.: Why send larger messages if you can send smaller ones?

        Dave W.: It would be good to explore some of this on the list.

        Chairs had to cut it short for the next presentation and we have only
        15 minutes left.

IPsecME IANA Issues (Tero K.):
https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-5.pdf

        Daniel Migault: Would it be valuable to have a BCP?

        Tero K.: It depends on case by case.

        Daniel M.: So the message is definitely "come to the IETF before doing
        anything"

        Paul W.: The biggest thing from telco world is that they can't wait for
        the slowness that is IETF.  Can we convince them that we'd be faster?

        Paul H.: We can handle this response without going through draft
        process, but rely on e-mail.

        Paul W.: But, I don't think we should leave that process in place.  I
        would just want to read an RFC.  I would like it to be mandatory to go
        through our group.

        Tero K.: As an IANA expert I can make sure that all happens.

        John Matteson: [Missed this one.]

        Paul W.: Maybe just them submitting an I-D would help?

        Tero K.: This is not impossible to handle in e-mail only.

        Paul H.: If you (Paul W.) don't like what Tero just said, do a draft
        that describes what you'd prefer.

Charter Discussion (chairs):
https://www.ietf.org/proceedings/95/slides/slides-95-ipsecme-1.pdf

        Paul reminds that WGs adopt ideas not documents.  It seems that quantum
        resistance and TCP encapsulation are well-received ideas, but the
        documents are not necessarily fully well-received.

        Tommy: If there are any problems with specific contents in TCP
        encapsulation, it can be changed.

        Third topic is the ESP doc might also have interest.  Paul H would like
        to have last call for 4307bis and also do ESP.

        Paul W.: There have been some people with interest, but this was with
        an older draft.

        Ok, then let's rev that draft and have discussion.

        Daniel M.: When we recharter and can we update when the topic isn't
        part of the original charter?  One suggestion was to make the charter
        more open than previously arranged.

        Paul H., I'm hesitant to leave charters too open, and I prefer to make
        them strong and specific.  Chairs have more work.

        Paul W.: Isn't this the IPsec "ME" working group?

        Paul H.: The AD would like the group to come together and not do
        everything but what is agreed upon that must be done.

        We still have plenty going on, but we have another set of things
        starting.  It seems like there's enough interest in the work that is
        being done.  But, please don't take this as a call to not finish what
        won't be done.  Don't worry about sliding everything into the charter
        now -- it's better to accept a later I-D and update the charter.

From Yaron Sheffer:

PH: 4307bis: will or will not publish a new minor version, but will go to WGLC
soon.

Sheila Frankel: do most implementations currently have EC in them?
Implementations of null-ESP? Will send a question to the list.

Paul W.: we might want to discuss the draft on ESP algorithms.

Puzzles

Valery: remaining issues are clarifications requested by Paul W.
Paul: still unconvinced about puzzles in general, specifically for low-power
clients. Yoav: testing on some clients. He had the feature in a product version
but cannot say how much it helped. Tommy: some algorithms are actually better
on ARM, so mobile devices may be more comparable than we think. Tero: puzzles
are mostly for future use. We haven't seen attacks yet where puzzles would be
useful. No other protocol has a similar feature. Kathleen: it would be better
to put this doc on the Experimental track until we have harder data. PH:
something we can decide at the end of LC, or maybe reopen the discussion of
splitting the doc.

RFC4307bis

Paul W.: would like list discussion whether we should move from 128-bit keys to
256-bit. Paul W: the changes to DH groups might actually kill some clients,
this is risky. But still agrees with the changes. PH: not clear now if 4307bis
is ready for WGLC, maybe needs to be tied to the new IPsec algorithms draft.
Daniel: please also send us textual/editorial comments.

Safe Curves

PW: prefers to use OIDs instead of making digital signature decisions in this
WG. PH: we will do WGLC on this draft soon.

Quantum Resistance

Valery: let's not use a new algorithm registry.
Dan H: the hint could be an index wrapped in a key, where this is an index into
large table of PPKs. Use AAD (?) Dave McGrew: not sure how this would provide
identity protection in this setting. Tero: we need QR for IPsec but not really
for IKE. The attacker in reality does know my identity from other information.
The problem with the proposal is that if anything goes wrong, the recipient
doesn't know who the client is. Or we might end up with huge tables of PPKs.
Proposes to get rid of this mechanism and live with with the active attacker
seeing identity. DM: you can have precomputed values to avoid the linear scan.
Tero: this is actually a DOS attack waiting to happen. Should also allow
one-time pad use for PPK.

TCP Encapsulation

Complexity and differing opinion about where we want to be in the arms race
with firewalls and captive portals. Brandon Williams: what about proxies?
Tommy: this belongs to a second draft, on how to use this encapsulation in
different use cases. Tero: the 3GPP doc does specify the format, but with a
different length for the length field. Will send the ref to the list. [Sent]
Valery: TLS in this drafts looks like a hack, cheating. Better to have it as a
separate draft. Tommy: people will be doing it in TLS, we need to stop them
from doing stupid stuff. PH: still not ready for adoption. We can have the
adoption discussion as soon as the new version comes out, addressing Valery's
comments.

IKEv2 Compression
Tero: compression more expensive than encryption, will not be usable for IOT.
Valery: compares sending 1 bit of info on the network to running 700
instructions, so this does make sense for IOT. Tommy: is it mostly about saving
energy? DW: we need to further explore the motivation on the list.

IANA Considerations

Daniel: maybe we should publish a BCP to preempt some of that? Tero is
skeptical. Daniel: the message is for consumers to come to the IETF early. PW:
complaints from telcos at ICANN. Can we commit to an SLA? PH: they don't need
to go through a process. Just send us email. PW: we should mandate for them to
go through the WG. Tero: some trivial stuff can go only through the Expert. PW:
maybe make them submit an I-D? PH: suggest that Paul W write something up to
open this discussion.

PH: the group will probably meet in Berlin, and might even adopt new work into
the charter in between.