Subject: [IPsec] Minutes of the IPsecME in IETF 96

From: Tero Kivinen <[email-masked]>
Date: Wed, 20 Jul 2016 15:41:35 +0300

Here is the meeting minutes from the IETF 96 session. Thanks for the
Adam for taking the minutes, and Yoav for the jabber scribing.

----------------------------------------------------------------------
Getting started.  Notetaker (Adam Montville).  Jabber: Yoav Nir.

IPSECME DDOS Protection - Yoav

Should there be a WGLC or should we just progress this draft?  Dave
indicates processing makes sense.  Yoav is asked to do the shepherd
write-up, but chairs will actually shepherd. 

RFC4307bis - Tero

Yoav comment on renaming algorithms to align.  Not sure all the people
     implementing will understand.  
Paul W.: Are we moving this to WGLC? 
Dave: Do we believe the doc is ready
Daniel Migault: within the document, do we talk about AES GCM or in a table.  
Tero: We use the same form that is used in the registry.
Sheila Frankel: We don't have any MUST algorithms here.
Tero: Yes.  We do have AES CBC.  
Sheila: If you take certain algorithms away without making them MUST,
	then we're going to end up with no MUST algorithms not part of USG's
	likes. 
Paul Hoffman: No algorithms that USG currently supports.  If IETF
     choses to do this, then USG can be out of line with IETF or
     inline with IETF.  It's not incumbent upon IETF to keep national
     governments happy.  We're giving folks plenty of warning. 
Yaron Shafer: I think the "minus" causes confusion.
Tero having a hum for MUST vs. MUST- -> Seems that MUST has it, but by
     a slight margin. 
Tommy Pauly: A MUST- is still a MUST, so it's clear from an
     implementer's perspective. 
D. Migault: If we don't go to MUST-, we won't have a smooth transition

RFC7321bis - Daniel Migault

Paul W.: Here we're using AES GCM as a MAY, but this is different than
     elsewhere, so should they be the same? 
Tero: This is not yet aligned, but it will be.  
Yoav: The issue with CHACHA is that there are no implementations out
     there.  It's hard to recommend something we didn't do ourselves.   
Migault: Hope to have implementations soon.
Yoav: Hopefully in the next year.
Tommy Pauly: Also hope in the next year.  GCM are noted in text as MAY
     but not show up in the table. 
P. Hoffman: You don't define MAY+ in the document.
Yoav: In previous document we listed some algorithms from the
     registry, and we chose to ignore them as though they never
     existed, but we might feel differently. 
Daniel M + Tero: Notice that untruncated SHA1 will be MUST NOT or not
     for IPsec
Paul W.: The one odd issue is that you don't have SHA2, which is
     really tainted (they have bad truncation). 
Daniel M.: What do people think about that?
Deb: Can you just fix it?
Paul W.: Not really - they won't change the default.  If you have more
     clout, please do it. 
Tim: We've seen that everyone does it the wrong way the first time
     around, and fix it as they are told.  SHA2_256 almost never works
     out of the box. 
Tero: Propose that we put this in the text.
Compression
Daniel: Compression isn't found in too many implementations.  Is MUST
     NOT for one and three MAYs fine? 

Safe Curves - Yoav

Nothing new since February, probably done, ready for WGLC.
Chairs: We should start WGLC.
No objection from the room.

TCP Encap - Tommy Pauly

Stream Prefix Discussion
Teddy Hogeborn: Regarding prefix, this is inbound signal so
      problematic typically.  Any packet with these six bytes in them
      would have issues.  
Pauly: We haven't seen this as an issue.  A configuration issues.  You
       have to make sure this doesn't conflict with any of the other
       protocols you have running 
Tero: Normally server has one port, normally.  But, the idea here is
      that if a random connection were made, it shouldn't be an issue. 
Dan Harkins: The other port that goes through FW is DNS and captive
    portals.  If this string is in, it allows identification which
    prevents getting away captive portals. 
Teddy Hogeborn: I still think this is a good idea, but say in the
      document it shouldn't be used in a middle-box to identify. 
Paul W: Could we make this optional?
Tero: No.
Brian W.: If you want to make it less likely, we can make it longer.
Yoav: Target for this string is the server.  We want to tell them to
      have the server decide based on these six bytes.   

Cisco and Apple are working on interoperability testing.  Invitation
for others to do such testing with them. 

When should we target WGLC?
Chairs: Is it ready for WGLC?
Tommy: There's not much left to do (no major issues).  
Tero: How many have reviewed? 4-5 hands (not very many here).

Generally the others in the room believe WGLC is probably in order.

IPsecME Quantum Resistance

Dan Harkins:  Chicken/egg problem was resolved with shared group PSKs.
    People are already comfortable with shared PSKs, and use those to
    key-wrap identity. 
Tero: Yes, this could work.  But there are trade offs.  There are many
    trades we could do here. 
Brian W.: This is depressing.  Trying to get away from PSK, and now to
    resist quantum we're saying PSK?  The only thing that seems to
    work otherwise is OOB. 
Scott Fluhrer: I see PSK as a short term issue that we can replace
    later.  We're not ready for the next steps, so this is a
    reasonable short-term answer. 
Brian: That's a very fair point.  I still think we should back away
    from it for a short-term solution.  The hooking in other out of
    band methods to share PPKs is, consequently, important work. 
Dan H.: Don't want to talk about solutions before requirements,
    but...there is ASN.1 symmetric key blogs already defined.  That
    could be part of the solution, or a path to take. 
Deb: If you symmetric key via asymmetric you still have a problem
    right?  So, you'd want to pass PSK by another mechanism.
    Distribution of PSK is a problem.  So you're not walking all the
    way back to your group keys... 
Mark Orzechowski: I think there's room for both symmetric and
    asymmetric solutions, because there are different users with
    different needs.  It shouldn't be beyond our wit to do this. 
Paul W.: Regarding PPK and authentication, now you're creating an
    oracle for that. 
Tero: They already have an oracle.  It's going to be this way anyway
    if the PPK isn't strong enough. 
Clint McKay: I have DOD customers that would use this, and it would
    decrease desire for v1.  The real issue is back traffic and not
    that folks are going to be breaking authentication. 
Paul H.: We did design IKEv2 and went through all these discussions.
    The most important thing we did was say let's not worry about ID
    protection.  It became a rathole.  If we take that off the plate,
    we have a much smaller problem space.  Let's do simplest without
    redesigning IKEv2. 
Paul W.: It's probably simple enough to map to an ephemeral ID, so why
    not do that? 
Tero: Next step is to discuss this on the mailing list to further
    discuss the requirements. 
Tommy: It feels that this should be split up into two different
    things. 

Charter Discussion

Charter new work items (2 of 2 slides): 
Yaron S.: Last paragraph appears to be ceremonial text and we should
    remove it. 
Kathleen M.: I think the IESG would be happier to see that text (e.g.
    remember how long PKIX lasted).
Kenny Paterson: Post-quantum key exchange discussion is probably going
      to go a lot longer than December 2017.   
Tero: If that's the case, then we'll have to recharter.
Paul H.: I'm not feeling that we'll have any idea by December 2017.
     You can actually start up a WG without IPSECME (a la curdle).  It's
     probably a good idea to try and shut down by that date. 

Split DNS - Paul W.

Tero: In a couple of cases you can only get a couple of responses
      back, is this going to be the same way?   
Tommy: If the client says anything that it doesn't support it, then
      they can send as many domains as they want.  Then response can
      include more. 
Tero: I would rather use DNSSEC format.
Paul H.: I haven't read the draft. Is this to give a new trust anchor
      or to point at which pre-configured keys? 
Paul W.: No.  You can give the DS record, and that would be followed
      by a lookup. 
Tero: Are DNS servers expected to respond to this.
Paul W.: Yes, but you should run a DNS server that servs all of your
      internal domains. 
Tommy: Enterprise customers and Apple, when they do split DNS, this
      would be awesome to get people to switch. 

Tero: How many have read the draft?
Not many (none?)
Tero: How many people this is a problem we should solve?
Quite a few hums in favor, no hums agains.
Yes, something should be put into the charter about this.
Tero: We want more review before taking this in as a WG draft, so that
      question will be delayed. 

Implicit IV - Yoav

Tero: The new transform type is the big one here, because IIV cannot
      be used for all cipher types. The new transform attribute could
      work. But, I think the New Transform ID is the best way (i.e.
      AES-GCM_16_IIV). The question is: This hasn't been the first
      time this has been proposed...the IV is part of the crypto
      boundary, so there's this layer of people complaining about
      violating crypto boundaries.
Tommy: I agree.  I see where you're going with the transform ID.  Is
      there any reason, when both sides support IIV, is there any
      reason to do this?  Can't we, if agree that we do IIV, just
      switch to using anything with IIV.   
Tero: I think it has the same problem as the new transform type,
      because not all ciphers support. 
Tommy: Then we could support the same idea with transform attribute.
Paul W.: I would prefer the transform attribute. Also, please don't
      double the registry. 
Brian: I suggest that we address AAED.  
Tero: That's one of the reasons I like new transform ID, because it is
      more like a new cipher.   
Brian: What's the motivation for this? Small devices?  Will this
      automatically be put in browsers?  
Yoav: TLS 1.3 does all the same things.

Tero: Adopt yes or no?
Light hums in favor, no hums against.
Tero: How many have read the draft - a few (double the previous!)
Tero: This is something we should think about

Diet-ESP - D. Migault
Ran out of time during presentation.  Slides are up, and questions
should go to the list. 
-- 
[email-masked]