Re: [IPsec] Preliminary minutes for the IPsecME meeting

"Valery Smyslov" <smyslov.ietf@gmail.com> Thu, 28 March 2019 19:37 UTC

Return-Path: <smyslov.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3899112032E for <ipsec@ietfa.amsl.com>; Thu, 28 Mar 2019 12:37:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsSA3Tdon200 for <ipsec@ietfa.amsl.com>; Thu, 28 Mar 2019 12:37:00 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8768A120282 for <ipsec@ietf.org>; Thu, 28 Mar 2019 12:36:59 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id q1so24413922wrp.0 for <ipsec@ietf.org>; Thu, 28 Mar 2019 12:36:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:content-language:thread-index; bh=rOgG/xwfcTM5wRIETBWFlNIxxhcqerMrRJ1YLJBDlD0=; b=Xh+x8hUT7UPn4C8DnGJLHGXOiU1ZK5CwJlzPN3y1xJrC5EE+Bl+aZyAB57Hr6gjPxE lSqJ11ox6IVom9M8sJJt95rHJVoQE8KvyOYZQBz2FhagE2078tdOayDDuP9EVvPGBbPr 9WHdkbH2PNWky+Tl8TH6AyU7CXTIQ9RZrLDX5xL6Z81NRd6nEQcZMjEXFSJm8QLa11gZ MeexuxSKr3wkGnTR7y1rFE6AXIDQ9vRyPF5+gLmNRwxVyjBgHOqPrpzRZAkWSkx4GVb4 Nm7yKolzsMry6Ns13pSttNVfKQW1u5PetpJuStyGw21ZW86HZNo3B7ahGu9hogJKbonX UWrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=rOgG/xwfcTM5wRIETBWFlNIxxhcqerMrRJ1YLJBDlD0=; b=IgrO4b0FN0eXatBvBDquGzRJJh+unurhaC++7Zg+hO+KwyGX6L+Mnj8dL3r1WUhB0m gojxsPx0lAP65g9MT8wKP4wxn4M6Aty7bDQWPxImiNqHdjbs6vdBxs0Ng1E+k5FJrAqN 48pDKHesh1XtROW6MTL3ZPBLXX53n0OCYnffmmuSMkCZv45Vhfz2h85pxLIPp8HmHl3j A413jTYNcFzAY9w1yDxk2SpnXDiRn1QM8b71mOxdh58e63tV3QBkebjSOS7Bhl1klSF3 u4qSTJDZE1U1H7yh/u5cCOYhx4KRB82PKh+AcH033Jl6/UQy8STTNYXla6oSBkDYvQNX V57A==
X-Gm-Message-State: APjAAAUUcdWVGettv1HywH7LAcLCtpYAMN5CxWmatdjvcI543dxpTv3t aIvkVxgAVoYXuw4oAtMyuR4zvEeUqAw=
X-Google-Smtp-Source: APXvYqwesL9BlZo0JsG3gnpyD8eoGH7uave6T9e9tmWyJyeO5OIv+3+1PLvkDAwNSv+6NVUgH+bKlw==
X-Received: by 2002:adf:8bc5:: with SMTP id w5mr23636212wra.226.1553801817274; Thu, 28 Mar 2019 12:36:57 -0700 (PDT)
Received: from svannotebook ([81.0.251.129]) by smtp.gmail.com with ESMTPSA id s18sm3576wmc.41.2019.03.28.12.36.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 12:36:56 -0700 (PDT)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: mohamed.boucadair@orange.com, 'Tero Kivinen' <kivinen@iki.fi>, ipsec@ietf.org
References: <23708.62392.134470.902330@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93302EA4F0BD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA4F0BD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Thu, 28 Mar 2019 22:36:54 +0300
Message-ID: <02ba01d4e59d$9a3815a0$cea840e0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: ru
Thread-Index: AQJD+PU9r1T7ZsKwvuYC69+vJUzdJQF0DLzfpTenTyA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/PEr7h3U7sG559ohiqle1aebZyQs>
Subject: Re: [IPsec] Preliminary minutes for the IPsecME meeting
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Mar 2019 19:37:03 -0000

Hi Med,

I know that your current draft doesn't use error type notifications,
as it was in its first version. My comment was too concise and thus
not clear enough. I just wanted to support Tero's ideas
to further simplify the design (and I suggested similar ideas before).
So I meant that there are still ways to make the draft simpler,
as it was done when you switched from error to status and reduced the
number of notifications. Sorry for not being clear.

Regards,
Valery.

> Hi Tero,
> 
> Thank you for sharing the minutes.
> 
> Please see inline a comment to Valery.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : IPsec [mailto:ipsec-bounces@ietf.org] De la part de Tero Kivinen
> > Envoyé : jeudi 28 mars 2019 17:18 À : ipsec@ietf.org Objet : [IPsec]
> > Preliminary minutes for the IPsecME meeting
> >
> > Here is the preliminary minutes for the todays IPsecME meeting. Thank
> > you for Yoav for taking the notes, and Paul for jabber scribing.
> >
> > If you have any comments, corrections or additions to minutes, post
> > them as soon as possible. I will submit these to the meeting materials
> > early next week.
> > ----------------------------------------------------------------------
> > IETF 104 IPsecME WG meeting in Prague
> > Thursday, March 28, 2019
> > 10:50-12:20 Karlin 1/2
> >
> > Agenda:
> > - Agenda bashing, Logistics -- Chairs (5 min)
> > - Draft status -- Chairs (10 min)
> >   - draft-ietf-ipsecme-split-dns
> >   - draft-ietf-ipsecme-qr-ikev2
> >   - draft-ietf-ipsecme-implicit-iv
> >   - draft-ietf-ipsecme-ipv6-ipv4-codes
> > - Work items
> >   - Intermediate Exchange in the IKEv2 Protocol - Valery Smyslov (10
min)
> >     - draft-smyslov-ipsecme-ikev2-aux-02
> >   - Post-quantum Key Exchanges in IKEv2 - Valery Smyslov (10 min)
> >     - draft-tjhai-ipsecme-hybrid-qske-ikev2-03
> >   - An implementor's view on Hybrid PQKE in IKEv2 - Tobias Heider (10
min)
> >   - PQC for IKEv2 in strongSwan - Leonie Bruckert (5 min)
> >   - ESP Header Compression and Diet-ESP - Tobias Guggemos (10 min)
> >     - draft-mglt-ipsecme-diet-esp-07
> >   - Labeled IPsec - Paul Wouters (10 min)
> >     - draft-ietf-ipsecme-labeled-ipsec
> >   - IKEv1 Graveyard - Paul Wouters (5 min)
> >     - draft-pwouters-ikev1-ipsec-graveyard
> > - Other presentations
> >   - IP Traffic Flow Security - Christian Hopps (15 min)
> >     - draft-hopps-ipsecme-iptfs-00
> >
> > Agenda bashing, Logistics
> > =========================
> > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-
> > ipsecme-chair-slides-04
> >
> > (no agenda bashing)
> >
> >
> > Draft status
> > ============
> >
> > draft-ietf-ipsecme-qr-ikev2 has a nit. Waiting for resolution to
> > proceed
> > Valery: Nit is a false positive; will make it go away very soon.
> >
> >
> > Draft-ietf-ipsecme-ipv6-ipv4-codes
> > ==================================
> >
> > Tero talked about draft-ietf-ipsecme-ipv6-ipv4-codes
> > The room was polled about the alternate designs.
> > Valery: Use status notification states rather than error.
> 
> [Med] The draft does not use error types but notification status types.
> 
>  Prefers
> > 	Tero's design (over his own)
> > Tero: Not enought people commenting here. Both are acceptable. Will
> >       take to the list.
> >
> >
> > Intermediate Exchange in the IKEv2 Protocol
> > ===========================================
> > Valery Smyslov - draft-smyslov-ipsecme-ikev2-aux-02
> > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-
> > ipsecme-intermediate-exchange-in-the-ikev2-00
> >
> > Paul Wouters: Update 7296?  Because it changes the msgid of IKE_AUTH
> > Valery: Will check
> > PW: Silly to send an empty intermediate.  Need to know what to ef
> > Valery: An accompanying document will define what it goes there.
> > 	Always need a new one.
> > PW: rename to IKE_INTERMEDIATE, since this applies to IKE only
> > Valery: don't mind.
> > Tommy: Seems fine with msgid. RFC 7296 doesn't require it to be 1 for
> >        IKE_AUTH
> > Tobias Heider: ??
> > Valery: This is just a framework document
> > Tero: It's OK to say this is just a framework. The documents that
> >       actually use it will define what goes in it.
> > Tobias Guggemos: You can do PQ in IKE_INIT if you don't need IKE
> >        fragmentation.
> > Tero: Too early for hum. Are we only going to ever have one?
> > Tero: Any objection for adoption?
> >
> >     (crickets)
> >
> > Tero: So will push the button and make this a WG draft (already asked
> >       on the list)
> >
> >
> > Post-quantum Key Exchanges in IKEv2
> > ===================================
> > Valery Smyslov - draft-tjhai-ipsecme-hybrid-qske-ikev2-03
> > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-
> > ipsecme-post-quantum-key-exchanges-in-ikev2-00
> >
> > Surprisingly, a document using INTERMEDIATE IKE_INTERMEDIATE.  What
> > are the odds?
> >
> > Tero: I would hate to see this happening: 7 key exchanges sharing the
> >       same type 4. These are complete key exchange - not the same thing
as
> >       DH. Need a new registry - they'll probably have their own
parameters.
> > Valery: They do the same thing as D-H: negotiate a key.
> > Scott: Specifically we wanted to allow doing this group, then this
> >       other, then an isogeny group.  This construct allows this to be
> >       done relatively straightforward.
> > Tobias Heider: Like the idea of combining old (DH, ECDH) and new stuff
> > Martin Fadman: Why the limit 7?
> > Valery: Arbitrary
> > Martin: Maybe this argues for the hierarchical idea.
> > Valery: Scott things that in most cases different types will be used.
> >       We have three types, so let's double it
> > Tero: Why negotiate all of this in the first SA payload? Interacts
> >       badly with parameters.  Maybe negotiate them one-by-one along
> >       the way?
> > Valery: What you are proposing will complicate things. Better to
> >       negotiate in advance what is going to follow.  Maybe the
> >       responder doesn't support what you are going to require in the
> >       third round
> > Mark ???: Having them all in one place is better
> > Scott: About parameters: transforms can have attributes. Regarding the
> >       size of the SA proposal: not a problem with the encoding of
> >       IKEv2 proposals, at least for sane policies
> > Tero: will continue on the list (as we're running out of time)
> > Yoav: This is just for CCSA with PFS? We can still do CCSA without PFS
> > Valery: Yes, and for rekeying of IKE SA
> > Mark: Support adoption
> > Tobias Heider: adopt, and rename to hybrid key exchange. Because it
> >       can be used with multiple classic D-H.
> > Yoav: if we're adopting this should adopt also intermediate, and no
> >       point in adopting intermediate if we're not adopting this.
> > Daniel Migault: Adopt, then make changes
> >
> >
> > An implementor's view on Hybrid PQKE in IKEv2
> > =============================================
> > Tobias Heider
> > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-
> > ipsecme-an-implementors-view-on-hybrid-pqke-00
> >
> > Still controversy about breaking the PQ exhcnages out. Also with how
> > to accomodate McEliece (large keys)
> > Yoav: Can define a new "extended-size" payload to accomodate >64K key
> > exchanges.
> >
> >
> > PQC for IKEv2 in strongSwan
> > ===========================
> > Leonie Bruckert
> > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-
> > ipsecme-pqc-for-ikev2-in-strongswan-00
> >
> > Tobias Guggemos: We have 4 implementations. Maybe do a Hackathon?
> > Tero: You going to organize this?  Thanks!
> > Tobias: Yes, if you fly me to Montreal
> > Dave: Will take to the list
> >
> >
> > ESP Header Compression and Diet-ESP
> > ===================================
> > Tobias Guggemos - draft-mglt-ipsecme-diet-esp-07
> > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-
> > ipsecme-esp-header-compression-and-diet-esp-00
> >
> > (discussion on adoption will be done on the list)
> >
> >
> > Labeled IPsec
> > =============
> > Paul Wouters - draft-ietf-ipsecme-labeled-ipsec
> > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-
> > ipsecme-labeled-ipsec-00
> >
> > (already a WG draft. Discussion on Paul's proposed changed in
> > selecting TS types will be done on the list)
> >
> >
> > IKEv1 Graveyard
> > ===============
> > Paul Wouters - draft-pwouters-ikev1-ipsec-graveyard
> > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-
> > ipsecme-ikev1-graveyard-00
> >
> > Tero: We don't instruct people what to use. We can't tell people what
> >       to use.
> > Dan Harkins: IKEv1 is already obsoleted. What more do we need?
> > PW: We want to tell people not to use it.
> > Smyslov: Support deprecating IKEv1
> > Benedict: Cannot get rid of 3DES.  Used in telephony.
> > PW: Yes, for now, but it's time for CAST
> >
> >
> > IP Traffic Flow Security
> > ========================
> > Christian Hopps - draft-hopps-ipsecme-iptfs-00
> > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-
> > ipsecme-ip-traffic-flow-security-00
> >
> > Valery: Interesting proposal. You fragment IP packets to arbitrary
> > 	size and then re-assemble. This complicates IPsec
> > 	implementation. I'd rather sacrifice some performance
> > 	(efficiency?) by allowing combining but not fragmenting.
> > Christian: Let's discuss on the list
> > Paul Wouters: Privacy and compressing are different goals. Why do we
> > 	      need the extra things.
> > Christian: the 20,000% overhead.
> > Lou Berger: The present thing is not deployable. We're destroying the
> > 	    available bandwidth with the trimodal distribution of packets.
> >
> > -- discussion to continue on list
> > --
> > kivinen@iki.fi
> >
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec