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.