Hi Med, Yoav, all, On Wed, Jul 29, 2020 at 05:38:17AM +0000, mohamed.boucad...@orange.com wrote: > Hi Yoav, Ben, all, > > == > Ben (AD): (missed first point Belongs in ADD?) Slide with attribute format, > for DoH, need to provide URI template
FWIW, the first point was not quite "belongs in ADD" but more "ADD is doing a lot of similar-ish stuff; let's stay informed of what's going on, in both directions". > Valery: Presentation also requested in ADD, but didn't have room in agenda. > Re: URI, will be covered in DoH clarifications (?) > == > > Valery was referring to > https://tools.ietf.org/html/draft-btw-add-rfc8484-clarification-02#section-6.1 > where we define a well-known uri that will be used to retrieve the uri > templates directly from the discovered Encrypted server. We that approach, we > don't need to supply the URI template in the IKE attribute. Ah, thanks; I hadn't encountered that one yet. -Ben > Cheers, > Med > > De : IPsec [mailto:ipsec-boun...@ietf.org] De la part de Yoav Nir > Envoyé : mardi 28 juillet 2020 22:22 > À : Tero Kivinen <kivi...@iki.fi> > Cc : ipsec@ietf.org > Objet : Re: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting > > Hi. > > I uploaded a PDF version to the meeting materials. Also added a list of > action items for the chairs. Comments are welcome on that part as well. > > https://www.ietf.org/proceedings/108/minutes/minutes-108-ipsecme-00 > > Yoav > > > On 28 Jul 2020, at 16:15, Tero Kivinen > <kivi...@iki.fi<mailto:kivi...@iki..fi>> wrote: > > Here is preliminary minues from the IETF 108 IPsecME WG meeting. I > copied some discussion about the proposed changes to ESP from Jabber > to here, as I think it was important to record those even when we did > not have time to have comments during the meeting. > > If you have any comments, please send them to me as soon as possible. > ---------------------------------------------------------------------- > # IPsecME IETF 108 > > Time: Tuesday, 28-Jul-2020, at 11:00-12:40 UTC > > ## Agenda: > * 11:00-11:05 - Note Well, technical difficulties and agenda bashing > * 11:05-11:10 - Document status (chairs) > * 11:10-11:25 - draft-smyslov-ipsecme-rfc8229bis (Valery/Tommy) > * 11:25-11:35 - draft-btw-add-ipsecme-ike-00 (Valery) > * 11:35-11:45 - draft-smyslov-ipsecme-ikev2-auth-announce (Valery) > * 11:45-12:00 - Proposed improvements to ESP (Michael Rossberg) > * 12:00-12:15 - IPTFS (Christian Hopps) > * 12:15-12:30 - YANG model for IPTFS (Christian Hopps) > * 12:30-12:40 - AOB + Open Mic > > ### Note Well, technical difficulties and agenda bashing > *Chairs* (5min) > > No Edits > > ### Document status > *chairs* (5min) > > *-implicit-Iv published as RFC8750 > *-qr-ikev2 published as RFC8784 > > *-ipv6-ipv4-codes publication requested > > ### draft-smyslov-ipsecme-rfc8229bis (TCP encap of IKE/IPsec) > *Valery/Tommy* (15min) > > Slides link: > https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-rfc8229bis-00 > > Paul Wouters: What are the kernel implications? And does this allow for > smaller IPsec/ESP Packets? > Valery: Text is a bit short, TCP stream packets will have same class > Paul: What Interop testing has been done? > Valery: Tested with Apple, Cisco, libreswan > > Piannissimo Hum for who has read the draft > > Paul: Good idea to adopt, found issues that would be good to incorporate in > draft > > Yoav: Will take to list if we need an update to 8229 and if this is the right > starting point. > > ### draft-btw-add-ipsecme-ike-00 (IKEv2 config for Encrypted DNS) > *Valery* (10min) > > Slides link: > https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-ikev2-configuration-for-encrypted-dns-00 > > Paul: What to do outside of VPN tunnel seems out of scope? (regarding Scope > bit) > > Valery: Still an interesting subject > > Ben (AD): (missed first point Belongs in ADD?) Slide with attribute format, > for DoH, need to provide URI template > > Valery: Presentation also requested in ADD, but didn't have room in agenda. > Re: URI, will be covered in DoH clarifications (?) > > Ben: When DoQ arrives may need additional work > > Tero: Add configuration attributes, less internal strucutre, more higher > level structure > > Yoav (participant): Missing motivation from draft Moving towards encrypted > world, don't want to force people to keep insecure DNS just for legacy IKEv2 > server > > Valery: That is one of the motivations; users won't see this, but it is > useful. > > Tirumaleswar Reddy: URL can be discovered another way > > Benedict Wong: My understanding is that in some cases we need a hostname to > do validation of the DoT server > > Tirumaleswar: This only supports PKI-based verification, so we can verify > based on sent certificate. > > Yoav: Calling for adoption? > > Valery: ADD Primary target for adoption, ipsecme is just informational, if > there is interest it could persist in this WG, but not yet. > > Tirumaleswar: Couple more revisions necessary, extension to IKE, want to make > sure both working groups are aware of work > > Ben (AD): If ipsecme was concerned by the work, or on the other hand thinks > it makes sense, it's good information for ADD to have > > ### draft-smyslov-ipsecme-ikev2-auth-announce > *Valery* (10min) > > Slides link: > https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-announcing-supported-authentication-methods-in-ikev2-00 > > Paul: Good idea, unclear where complexity might be, in the past migration > between methods (null -> something else) needed a ppk hack - sending two auth > payloads > > Tero (participant): Could have one part negotiate the algorithm, and the > second part to negotiate the algorithm ids for CAs in the certreq > > Yoav: will take a call for adoption to the list > > ### Proposed improvements to ESP > *Michael Rossberg* (15min) > > Slides link: > https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-proposed-improvements-to-esp-01 > > Yoav (?): Discussion happening on list and in jabber. Informational would be > wrong, changes packet on wire, so experimental or standards track if anything > > Summary of questions and comments from the jabber: > > * Yoav: Some firewalls would be very upset about this packet format, because > it looks like every packet is retransmission. > * Paul: so flip sender/window id with sequence number > * Chopps: andeven put the higher order after lower order so stays exactly the > same as before > * Scott Fluhrer: In addition, each sending id/window id has its own replay > window, does that mean that the receiver needs to track 4 billion antireplay > windows? > * Scott: Also, it wouldn't be secure with CBC > * Paul: It drops all non-AEAD, which we should do anyways > * Scott: You also lose the multitarget protection with GCM by not including > the 32 bits of key-derived nonce > * chopps: The sender id is really a mcast thing, so it reduces to 64k > * Scott: Does the receiver need to track a antireplay window for each > multicast sender? > * Yaov: Yes > * Scott: I can't see how that can work on a decryptor that can't dynamically > allocate memory > * Bob Moskowitz: Would need a change to robust header compression so that > smaller seq# for constrained links? > * Valery: This proposal lacks enough generality to replace ESP - it considers > very small set of ciphers and use cases > * Paul: and we might as well throw in a discussion of implicit IV if we are > updating ESP to v4 > * Yoav: @Valery: doesn't it use all the ciphers that people care about now? > Consider that TLS 1.3 has about two ciphers (plus another 1 for IOT). > * Valery: In addition, many things it aims for can be achieved using ESP. > Even replay protection for multicast (with some limitations). > * Steffen Klassert: Get rid of the trailer would be nice from implementation > point of view > * Valery: @yoav, No, it doesn't work with CBC at all. Moreover, if IV is > somehow structured, it won't work too > * Yoav: TLS 1.3 doesn't support CBC either. > * Valery: I understand, but what if tomorrow a new cipher mode appear that is > superior to GCM and will require some special form of IV? The problem is that > this design requires IV to be in a particular form. If cipher requires other > form, it'll fail > > Tero: Not in charter, this is a big change. See if it is a good idea first > before taking to much time discussing and writing > > ### IPTFS -- > [draft-ietf-ipsecme-iptfs-01](https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01) > *Christian Hopps* (15min) > > Slides link: > https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-ip-traffic-flow-security-00 > > Yoav: Hasn't gotten much review, WGLC is one way, but don't know if it is the > best way. Requesting transport area early may be a good way too. > > Tero: Might be hard to get another protocol number. > > Lou: Getting a protocol number shouldn't be a big deal; many can be > deprecated. > > Ben: Please fill out the official early-allocation form request. > > Agreed on sending this out for transport area early review. > > ### YANG model for IPTFS -- > [draft-fedyk-ipsecme-yang-iptfs-00](https://tools.ietf.org/html/draft-fedyk-ipsecme-yang-iptfs-00) > *Christian Hopps* (15min) > > Slides link: > https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-yang-model-for-ip-traffic-flow-security-00 > > Tero: SDN YANG models generally work in two mode, either IKE-less, where it > configures IPsec SAs, or in IKE mode where it does not touch IPsec SAs, as > IKE configures them, so they wanted to keep the configuration clear which > parts they are configuring. > > Christian: Also operational state, even if not configured via YANG > > Tero: If we could consolidate on a single YANG model, that would be ideal > (such as I2NFS) > > Yoav: Per chat, would benefit from a YANG Dr. review > > Lou: Would benefit from another review, per datatracker, latest draft needs > another review. > > ### AOB + Open Mic > *all* (10min) > > Paul: Labeled IPsec still in review. Graveyard draft still in limbo > > Tero: Take to list; a few of these can go to WGLC, but should check with AD > first. > > Tero: I think we need to have interm meeting about the ESP. We cut the > discussion out from here, as it would have taken the rest of the time, but we > should have separate interm just for it. > -- > kivi...@iki.fi<mailto:kivi...@iki.fi> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org<mailto:IPsec@ietf.org> > https://www.ietf.org/mailman/listinfo/ipsec > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
