From nobody Thu Oct 10 13:12:02 2019 Return-Path: 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 AC211120089 for ; Thu, 10 Oct 2019 13:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 D7Us61vOQMzp for ; Thu, 10 Oct 2019 13:11:58 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA001200EF for ; Thu, 10 Oct 2019 13:11:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 87C916211F for ; Thu, 10 Oct 2019 16:11:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MRMc3NsG3NFB for ; Thu, 10 Oct 2019 16:11:48 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 0DA0C6211C for ; Thu, 10 Oct 2019 16:11:48 -0400 (EDT) To: IPsec@ietf.org From: Robert Moskowitz Message-ID: <288a46b0-fa99-b070-362b-d0f0edbcab4b@htt-consult.com> Date: Thu, 10 Oct 2019 16:11:44 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [IPsec] IPSECKEY Resource Record Parameter for EdDSA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 20:12:00 -0000 Is there an update for EDDSA (RFC 8420) for the ipseckey RR? https://www.iana.org/assignments/ipseckey-rr-parameters/ipseckey-rr-parameters.xhtml IANA is not showing it, so perhaps it is in a draft somewhere? Thanks From nobody Thu Oct 10 13:33:35 2019 Return-Path: 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 0F0901200FF for ; Thu, 10 Oct 2019 13:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 Iey7Xl30Zwew for ; Thu, 10 Oct 2019 13:33:31 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379E91200EF for ; Thu, 10 Oct 2019 13:33:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46q2pw5j0Wz1q6; Thu, 10 Oct 2019 22:33:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1570739608; bh=a1Of91jXK/fP9kYHj0dFshUfdvU143Jc8P1HXdm/Xto=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=JxeKug+4ltZMyMh95OMMQhaHOIedhIxhIcRWBcadxpmqVJQ157Fh7lm8DgURt2S2W OhBZfSH/cfFNHME4EivMFRL4OB6TjS75Khc56dxD04G+32UIS/v9usdHjOB4KvnnO3 fyhkQriqlEKkRA0tztlmcRLjKXPjlIvxJEWYkJJY= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id A-IFR3pr1pqH; Thu, 10 Oct 2019 22:33:27 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 10 Oct 2019 22:33:27 +0200 (CEST) Received: from [10.168.10.175] (199-7-157-60.eng.wind.ca [199.7.157.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 0D71F6084D40; Thu, 10 Oct 2019 16:33:26 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16G102) In-Reply-To: <288a46b0-fa99-b070-362b-d0f0edbcab4b@htt-consult.com> Date: Thu, 10 Oct 2019 16:33:24 -0400 Cc: IPsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <288a46b0-fa99-b070-362b-d0f0edbcab4b@htt-consult.com> To: Robert Moskowitz Archived-At: Subject: Re: [IPsec] IPSECKEY Resource Record Parameter for EdDSA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 20:33:33 -0000 Not yet, Also my idea was the skip ECDSA (8-11) and only do one for DigitalSignatures= (14) style pubkey (RFC 7427) Paul Sent from my iPhone > On Oct 10, 2019, at 16:11, Robert Moskowitz wrot= e: >=20 > Is there an update for EDDSA (RFC 8420) for the ipseckey RR? >=20 > https://www.iana.org/assignments/ipseckey-rr-parameters/ipseckey-rr-parame= ters.xhtml=20 >=20 > IANA is not showing it, so perhaps it is in a draft somewhere? >=20 > Thanks >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Oct 10 13:53:52 2019 Return-Path: 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 131331200F6 for ; Thu, 10 Oct 2019 13:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Jnfibt9QZZvV for ; Thu, 10 Oct 2019 13:53:48 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF8C9120170 for ; Thu, 10 Oct 2019 13:53:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id A2BA862115; Thu, 10 Oct 2019 16:53:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id N3oU6+F9liZ2; Thu, 10 Oct 2019 16:53:17 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id C695F62120; Thu, 10 Oct 2019 16:52:59 -0400 (EDT) To: Paul Wouters Cc: IPsec@ietf.org References: <288a46b0-fa99-b070-362b-d0f0edbcab4b@htt-consult.com> From: Robert Moskowitz Message-ID: <1fd511e8-c5bf-141e-821f-da38ae3fe4cf@htt-consult.com> Date: Thu, 10 Oct 2019 16:52:58 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [IPsec] IPSECKEY Resource Record Parameter for EdDSA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 20:53:50 -0000 ok At some point I am going to need one, as 8005 references IPSECKEY for its RR and I am using EdDSA for the tm-rid work. Since we have a PK length field, that can separate Ed25519 from Ed448. Right now we are framing our hackathon effort so will just use something.  Like 4. On 10/10/19 4:33 PM, Paul Wouters wrote: > Not yet, > > Also my idea was the skip ECDSA (8-11) and only do one for DigitalSignatures (14) style pubkey (RFC 7427) > > Paul > > Sent from my iPhone > >> On Oct 10, 2019, at 16:11, Robert Moskowitz wrote: >> >> Is there an update for EDDSA (RFC 8420) for the ipseckey RR? >> >> https://www.iana.org/assignments/ipseckey-rr-parameters/ipseckey-rr-parameters.xhtml >> >> IANA is not showing it, so perhaps it is in a draft somewhere? >> >> Thanks >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Oct 11 00:02:12 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEBA120137; Fri, 11 Oct 2019 00:02:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen , ipsecme-chairs@ietf.org, kivinen@iki.fi, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <157077732068.29461.12498226831215806070.idtracker@ietfa.amsl.com> Date: Fri, 11 Oct 2019 00:02:00 -0700 Archived-At: Subject: [IPsec] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-ips?= =?utf-8?q?ecme-implicit-iv-07=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 07:02:10 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-implicit-iv-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this document. I am trusting the security AD to check whether it is safe not to have a 'random' IV. I have one trivial-to-fix DISCUSS and a couple of COMMENTs. It is also unclear at first sight whether the 'nonce' built from the sequence number is actually the IIV. Regards, -éric == DISCUSS == -- Section 1 -- D.1) Please use the RFC 8174 template ;) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- == COMMENTS == -- Section 5 -- C.1) "inside the SA Payload" probably worth being a little more descriptive here (for instance, "SA payload in the IKE exchange" ?). Also suggest to use "IKE Initiator Behavior" for the section title. -- Section 8 -- C.2) please use the usual text for IANA considerations (notably asking IANA to register as this is not this document that registers the codes). == NITS == In several places, s/8 byte nonce/8-byte nonce/ From nobody Fri Oct 11 02:15:38 2019 Return-Path: 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 E2595120020; Fri, 11 Oct 2019 02:15:35 -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_HELO_NONE=0.001, SPF_PASS=-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 NYY-YHM6dxU7; Fri, 11 Oct 2019 02:15:34 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 9DC90120043; Fri, 11 Oct 2019 02:15:30 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id h4so11042475wrv.7; Fri, 11 Oct 2019 02:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gkjDS43A2/jjh0mAGsOg7zQT15xJoruAVoROdllzm/4=; b=Xi2epFkWviY2CNtTuqE9rRukQM0gKKXsK1+AqaYXW5pkS7Z+N9P9NFt0wlNOG8DkbN r1Z+a1IzjPdsQvuBYGDWGPYFtNOx1Q2e5XiDYgSUozDWJo/kD78n/3ihItaEskuRickv Njmt7stEKNk2pUVy1kWDbfkDBtsBdv0b5WfkzI+UcYKhDH/c70enBjx4AHC6nprkFIdz bxruZXFHJuo8/tKQlQa8BFZb262HPvxGDz99Uhc4Wyg1Zx+VgfxoKBWgE3MOz+TCYetu T5PI6IQFATca31nSsuz7pG03UA8VM8qd+UrWK2TSpDmS7mrfOIkKXpo8u98GJzisKoY+ XWHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gkjDS43A2/jjh0mAGsOg7zQT15xJoruAVoROdllzm/4=; b=h5f8nrLCHWOhSrxfKrgt4hX5XiDNePuIRvU4YUXzNkod5NwfZQzKpCTPPlDjtWKs1/ yzWJUKDgNgbwYnfolrm3K6Y1/T5G9lSrzEHF+RNAqffGUNS3AN4E3tFdWayr6WDSFBVu LGBo3KOz9X9xAI89fXw4zRgFp5kz5CN9joy6Hf22S0v9qqxiCQVM4Z8rzS5KiwwaBr0l eW/nuL9YdzUzRxFJwhH0YL8rSRkw1jUVGGtOL9qvNxf4Jlm7nkJ9lvtnvhU6QnN5nEKW f10YgkhQx6mvxM5ZlpwkJU04EXZFvhI4dlcqxCyDP9xvzhwUL2pwQygHAqjwv1c7fPew dr0Q== X-Gm-Message-State: APjAAAUmxRWfi2tfhbHc1JeB9mE5KVq50mVX9D66rUVWWahLlMTQnuhf smbdShYgNCG1dj4VYDwjteA= X-Google-Smtp-Source: APXvYqwMFfeigOfE82trHvwCm4DeyJ8wxk3rE4MfHcUOynkuZWoNBALCz7xr3yZGUNRn1DQg6GGTnA== X-Received: by 2002:adf:e545:: with SMTP id z5mr11853580wrm.333.1570785328992; Fri, 11 Oct 2019 02:15:28 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id y13sm11258788wrg.8.2019.10.11.02.15.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Oct 2019 02:15:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Yoav Nir In-Reply-To: <157077732068.29461.12498226831215806070.idtracker@ietfa.amsl.com> Date: Fri, 11 Oct 2019 12:15:26 +0300 Cc: The IESG , draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen , ipsecme-chairs@ietf.org, ipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <581E79DB-B1B7-4177-B747-7B12CA4AA64A@gmail.com> References: <157077732068.29461.12498226831215806070.idtracker@ietfa.amsl.com> To: =?utf-8?Q?=C3=89ric_Vyncke?= X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [IPsec] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-ips?= =?utf-8?q?ecme-implicit-iv-07=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 09:15:36 -0000 Hi, =C3=89ric. Please see inline. > On 11 Oct 2019, at 10:02, =C3=89ric Vyncke via Datatracker = wrote: >=20 > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-ipsecme-implicit-iv-07: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thank you for the work put into this document. I am trusting the = security AD to > check whether it is safe not to have a 'random' IV. I=E2=80=99m sure they will, but as an explanation, some algorithms = require a random IV. Examples are AES in CBC mode. Other algorithms do = not require a random IV, but do require a unique IV. The documents = describing such algorithms recommend using either a simple counter or an = LFSR to generate the IV. Examples are AES in counter mode and ChaCha20. = Our draft specifies IIV only for the latter kind of algorithms. > I have one trivial-to-fix > DISCUSS and a couple of COMMENTs. >=20 > It is also unclear at first sight whether the 'nonce' built from the = sequence > number is actually the IIV. Although they use the same fields, the literature tends to call the = random kind an "Initialization Vector" and the must-not-repeat kind a = =E2=80=9CNonce=E2=80=9D. In IPsec the field is called IV, so there is = some confusion in the terms. >=20 > Regards, >=20 > -=C3=A9ric >=20 > =3D=3D DISCUSS =3D=3D >=20 > -- Section 1 -- > D.1) Please use the RFC 8174 template ;) Right, our bad. This is probably because this document has been making = the rounds for over 3 years. Will fix. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > =3D=3D COMMENTS =3D=3D > -- Section 5 -- > C.1) "inside the SA Payload" probably worth being a little more = descriptive > here (for instance, "SA payload in the IKE exchange" ?). Also suggest = to use > "IKE Initiator Behavior" for the section title. OK > -- Section 8 -- > C.2) please use the usual text for IANA considerations (notably asking = IANA to > register as this is not this document that registers the codes). Yes, since we received early assignment I think we should go with the = =E2=80=9CIANA has assigned the following values=E2=80=A6=E2=80=9D text, = and leave a reminder that the reference should be updated. >=20 > =3D=3D NITS =3D=3D >=20 > In several places, s/8 byte nonce/8-byte nonce/ Will fix. From nobody Fri Oct 11 02:26:52 2019 Return-Path: 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 EACC1120044 for ; Fri, 11 Oct 2019 02:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 MOt2c0JcCVxq for ; Fri, 11 Oct 2019 02:26:48 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8F5120043 for ; Fri, 11 Oct 2019 02:26:48 -0700 (PDT) Received: from dooku.sandelman.ca (ipv6.dooku.sandelman.ca [IPv6:2607:f0b0:f:6::1]) by relay.sandelman.ca (Postfix) with ESMTPS id 5F6971F47F; Fri, 11 Oct 2019 09:26:46 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 6803A19D1; Fri, 11 Oct 2019 11:26:48 +0200 (CEST) From: Michael Richardson To: Robert Moskowitz cc: IPsec@ietf.org In-reply-to: <288a46b0-fa99-b070-362b-d0f0edbcab4b@htt-consult.com> References: <288a46b0-fa99-b070-362b-d0f0edbcab4b@htt-consult.com> Comments: In-reply-to Robert Moskowitz message dated "Thu, 10 Oct 2019 16:11:44 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Fri, 11 Oct 2019 11:26:48 +0200 Message-ID: <19298.1570786008@dooku.sandelman.ca> Archived-At: Subject: Re: [IPsec] IPSECKEY Resource Record Parameter for EdDSA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 09:26:50 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Robert Moskowitz wrote: > Is there an update for EDDSA (RFC 8420) for the ipseckey RR? > https://www.iana.org/assignments/ipseckey-rr-parameters/ipseckey-rr-p= arameters.xhtml > IANA is not showing it, so perhaps it is in a draft somewhere? I haven't done this. It's marked IETF Review, so a document is needed (but necessarily standards track). What's your use case today? Surely not tm-rid? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2gStcACgkQlUzhVv38 QpCyQgf9Hyg9xutLuumhGjtRtDN5sIFn5WzV9JmnM9cmCwU42xx/2EqDS5eIY9/n w6RN1mqgS199W52M+tJ9zeeMY2rRw2TlNCVUu1Rdn/J0PkG1oDgKfQkJT4fQUb1s zfjzjfOKsV+O7ooNT+3zrYzK1GLpqzfCz8QRIQ8Of/qAeZyFvsmOXEgnxLnGTKtJ BSTxbqHVqfsLeE16+uxp31k5CXVAmvmxzpvZQ4L9WzcDp9goDfGgDmE8I3MX+nvO KMs1qi36Yo8gWEbwtsXrEU1jEQrosbKfF1UGAuQZmxnS/XPBJCL+SGiby1rjr1hE 8TM7f+zMDpy8eyFuCOEe0usz2cemlQ== =VT5j -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 11 02:44:43 2019 Return-Path: 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 2C9C4120046 for ; Fri, 11 Oct 2019 02:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 C1oKqLVz0hzW for ; Fri, 11 Oct 2019 02:44:40 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC954120044 for ; Fri, 11 Oct 2019 02:44:40 -0700 (PDT) Received: from dooku.sandelman.ca (ipv6.dooku.sandelman.ca [IPv6:2607:f0b0:f:6::1]) by relay.sandelman.ca (Postfix) with ESMTPS id 68D401F456; Fri, 11 Oct 2019 09:44:33 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id C0C6619D1; Fri, 11 Oct 2019 11:44:04 +0200 (CEST) From: Michael Richardson To: Robert Moskowitz cc: Paul Wouters , IPsec@ietf.org In-reply-to: <1fd511e8-c5bf-141e-821f-da38ae3fe4cf@htt-consult.com> References: <288a46b0-fa99-b070-362b-d0f0edbcab4b@htt-consult.com> <1fd511e8-c5bf-141e-821f-da38ae3fe4cf@htt-consult.com> Comments: In-reply-to Robert Moskowitz message dated "Thu, 10 Oct 2019 16:52:58 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Fri, 11 Oct 2019 11:44:04 +0200 Message-ID: <20375.1570787044@dooku.sandelman.ca> Archived-At: Subject: Re: [IPsec] IPSECKEY Resource Record Parameter for EdDSA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 09:44:42 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Robert Moskowitz wrote: > At some point I am going to need one, as 8005 references IPSECKEY for > its RR and I am using EdDSA for the tm-rid work. I was surprised at the 8005 reference to IPSECKEY, since it seemed wrong th= at a IPSECKEY RR would point at some machine that was going to answer with HIP and not IKEv2... but now I see that you have your own RR, but share the algorithm numbers with IPSECKEY. It seems that your tm-rid work can just amend this IANA registry. If you had a WG, you could ask for an early allocation. I don't think that the IPSEC WG chairs could ask for an early allocation for you at this point, alas.=20 =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2gTuQACgkQlUzhVv38 QpA+7QgAl1m5nqylzNnE3+r75lCKdQfkJ7WO805E2rp7LEjpcsFY2sFayAMvkDkb kOptAUZwJyDdqvqNW1Qzte4EOznlAfEjdQciyYoFzRPKbt/PtmaNvcNWZqDuAcHe lMGjHtvoZylifvHNdSphdbhdD0uOdBNDL9G/yfSbclPR5PQEnOPGExwoFHAOk1Bs uDmNq4lxVJJojopst+mbFm1HCXzX+USGT0Q6x43g1evrfMDGItldYSQXN5mwYP98 ilyuQm0/AFFdm7G0QziQaLbeCRSLMEQ2iqZoFaBDzucmntjdZM6P/kkiLUWbJEyu 0DKqfT8cSSx7s0OoW3i3ubkUjznwdw== =nBgV -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 11 03:49:07 2019 Return-Path: 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 6D53A120033; Fri, 11 Oct 2019 03:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=cOs1KOzu; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=bkfv/9YZ 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 aTQInSighMaX; Fri, 11 Oct 2019 03:48:57 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E72912002F; Fri, 11 Oct 2019 03:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5076; q=dns/txt; s=iport; t=1570790936; x=1572000536; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LKWb1kaYJfcOP8gm/ot9/Rspwodg4I0u2iq0s0FIzkw=; b=cOs1KOzuovKbXUrP3RpyuiS6brupLIJvPYrcxcI1nqsw92wedC4H+Ub4 d6r15wRQ3A95ILUMxRbX7ih32RNLSfaMMeU4sJF3OoM8Hsv74qTDweIxq bdShVd7NP2w/U5dLRUjMcZpT0kzSc3bMPwbq5UTAnW3CLIxojUOfCv8R5 U=; IronPort-PHdr: =?us-ascii?q?9a23=3AS/E6qRVL7LXCfx82hAKKaoweIl3V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA92J8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank3AtVEX1xo13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAACsXaBd/4YNJK1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7gUspJwVsViAECyqEI4NHA4pHglyJaY4TgUK?= =?us-ascii?q?BEANUCQEBAQwBASMKAgEBhEACF4JHIzgTAgMJAQEEAQEBAgEFBG2FLQyFSwE?= =?us-ascii?q?BAQECARIREQwBATcBDwIBBgIOCgICJgICAh8RFQULAgQOBSKDAAGCRgMOIAE?= =?us-ascii?q?CDJV/kGICgTiIYXWBMoJ9AQEFgUhBgQOBfg0LghcDBoEMKIwOGIFAP4ERJx+?= =?us-ascii?q?CTD6CGkcCAQIBgSoBEgEfF4J3MoIsjQmCLzeFW4kKjjJBCoIihwiKCQSEBBu?= =?us-ascii?q?COodOjziDQpMNgg6PBgIEAgQFAg4BAQWBaSJFIlgRAgZwFRpLAYJBUBAUgU8?= =?us-ascii?q?4bwEIgkOFFIU/dAGBKI0IgkUBAQ?= X-IronPort-AV: E=Sophos;i="5.67,283,1566864000"; d="scan'208";a="645905042" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Oct 2019 10:48:36 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x9BAmadf005964 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 11 Oct 2019 10:48:36 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 11 Oct 2019 05:48:35 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 11 Oct 2019 06:48:34 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 11 Oct 2019 06:48:33 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DWzzTxYg/CJ7dRQ3B/GPWe/THkTP7xc9o2MuQh5UladYwE8DInUCDn/tC6hdsg+wu/k2+dCScKW+xn4a36RIrQKy7GjBU+zcfAGXLKIBuCVH2Ld9s9LJSK5n9ty33Sm8yvGKDZWiTJL5optjSePb14rfDIeXF0BOPHOj6KT4mC8fkQudxL3d4SSScdYt9ozWNQTVXPrZa/B0lMXt7p9m90Y7SLPNKPeZiIzmJ401+1Z+Y14sjjFZnS0gtHb7tTmQaq/CsRWBrNCiZVMacT7uxs0cxA/VaVW0ppy/OOtUm1+ctMHYdVVNl1/uC/wSTEFJ3pn2nHI1icJnIWP0+e5C0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LKWb1kaYJfcOP8gm/ot9/Rspwodg4I0u2iq0s0FIzkw=; b=BuS4hOQUGJo6WuiTW/4qyz9GbbF/icZL9g88FuHve92m4wm0ahJltQZHxe32dAvSp+EgD9HwmR3xs7rsvoTDrHyiRrq0/TUuyVA84Vl8EuQ6pRKjBDsf2qV4c9rv8ohlfjH05AfV6okeTEA0FkhfvG+iCi4BAOnOOVTS+lssitm6whzUK1uMlO+Hgrcvsc2Xr9U9eZ/h+uZivJ0qHYsBgrXs1TbcSo2khQcrAWHN0QqKxwwO41rCZy92x+hlcNjxBCD6BHcqGL+/tzLL9/LlORlI0ef5OBqQOvlg7SzqWgcQttRfATN0p9V182CIbLqAt1u/gs4sP32fx/oFLHmJkw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LKWb1kaYJfcOP8gm/ot9/Rspwodg4I0u2iq0s0FIzkw=; b=bkfv/9YZq3Ineo9rE8s2YLG3Yl9CzCaQGDx6mUOkbfUYojeO9uHGqkxPaMdqZxQjOQqyYXnbmvZacJuFxwbllqR5giTh0dZu/ztwbx8sqSwHRiyxyoM5pvQ6Jsz0HhvceWx8ESTY8ny2LLLit6ILW9SzqepiQWauJIYmfnZ8DVU= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB4447.namprd11.prod.outlook.com (52.135.39.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.21; Fri, 11 Oct 2019 10:48:32 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::e4f8:d335:c018:c62a]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::e4f8:d335:c018:c62a%7]) with mapi id 15.20.2347.021; Fri, 11 Oct 2019 10:48:32 +0000 From: "Eric Vyncke (evyncke)" To: Yoav Nir CC: "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" , "draft-ietf-ipsecme-implicit-iv@ietf.org" , The IESG , "Tero Kivinen" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWlwc2VjbWUt?= =?utf-8?Q?implicit-iv-07:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHVgBStfGX+/79h/kG2kqpLlVxiQKdVZDYA Date: Fri, 11 Oct 2019 10:48:32 +0000 Message-ID: <61A55932-5AA3-498E-89CC-676D4422B552@cisco.com> References: <157077732068.29461.12498226831215806070.idtracker@ietfa.amsl.com> <581E79DB-B1B7-4177-B747-7B12CA4AA64A@gmail.com> In-Reply-To: <581E79DB-B1B7-4177-B747-7B12CA4AA64A@gmail.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:51fd:38b5:44f1:7108] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba77b585-b9fa-411d-e1cd-08d74e388f87 x-ms-traffictypediagnostic: MN2PR11MB4447: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0187F3EA14 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(396003)(376002)(366004)(346002)(189003)(199004)(476003)(229853002)(486006)(256004)(99286004)(446003)(2616005)(6506007)(305945005)(14444005)(2906002)(71190400001)(11346002)(71200400001)(6116002)(53546011)(6916009)(46003)(102836004)(186003)(5660300002)(8936002)(76176011)(86362001)(81166006)(81156014)(224303003)(33656002)(58126008)(14454004)(66446008)(66946007)(316002)(54906003)(91956017)(76116006)(66476007)(66556008)(64756008)(6246003)(478600001)(966005)(36756003)(7736002)(4326008)(6512007)(6306002)(6486002)(6436002)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4447; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WFHHT+2Vt5ur/mN7n7TcuKqIfJoRFBSquyjGyak7QrzXncVl2uNZFwjSuPe8+wlGCpv09jMJ4ndoHQpVgqU4czEk8eitptmvsdi0ayO4UADi1CN0M793sBSnPRYkNVASICU6KATV1ddfrtc0MxSlqWtz2IfUDP51l/r7PV+ERcwRIYkiQBxuxgIaaufFSVAxnnroDlTepDvps9ra1nOEh21wz3AwC4u9azK5CiYfzZW20PRWz/Am4bB5hmSO69bju8evflg4Nc/YTdbhAvOiGBk85jtMfe4w1Vt5hm9Tf+VxgykzAg6F8noYxvZbV9yfzBD9e4Iby4iDEVS+HR05tHIVNs/lGIVPT8K9Plr1DhGAyyeI/HLxQvWpyDpNrCzln42fiRSWNWa4eHuIkJGovFt4YeEdDu8KLXt6eQRBPkQktuoqJGXQb0CqddDc+E8S/TYfHJFef+LhFOUO3vPUNA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <5D27B4C6468F0B429FAB88C97BB1C493@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ba77b585-b9fa-411d-e1cd-08d74e388f87 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2019 10:48:32.7667 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: su8WGbgVHF8M31QEhOM/CC2jOtnLnviHdVTwJAjV2HLtUX9zV21YXLVaJ32lPHfKIuVixth84NG35C+rIr31Ag== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4447 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [IPsec] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-ips?= =?utf-8?q?ecme-implicit-iv-07=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 10:49:00 -0000 WW9hdiwNCg0KVGhhbmsgeW91IGZvciB5b3VyIHF1aWNrIHJlcGx5LCB0aGUgZXhwbGFuYXRpb25z IGFuZCB0aGUgYWN0aW9ucy4gT2J2aW91c2x5LCBJIHdpbGwgY2xlYXIgbXkgRElTQ1VTUyB1cG9u IGEgbmV3IHJldmlzaW9uIG9mIHRoZSBkb2N1bWVudC4NCg0KQWJvdXQgdGhlIG5vbmNlIC8gSUlW LCBtYXkgSSBzdWdnZXN0IHRvIGFkZCB0aGUgZXhwbGFuYXRpb24gYmVsb3cgdG8gdGhlIHRlcm1p bm9sb2d5IHNlY3Rpb24/DQoNClJlZ2FyZHMNCg0KLcOpcmljDQoNClBTOiB0aGFuayB5b3UgZm9y IHVzaW5nIGEgw4kgaW4gbXkgZmlyc3QgbmFtZSA7LSkNCg0K77u/T24gMTEvMTAvMjAxOSwgMTE6 MTcsICJpZXNnIG9uIGJlaGFsZiBvZiBZb2F2IE5pciIgPGllc2ctYm91bmNlc0BpZXRmLm9yZyBv biBiZWhhbGYgb2YgeW5pci5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQoNCiAgICBIaSwgw4lyaWMu ICBQbGVhc2Ugc2VlIGlubGluZS4NCiAgICANCiAgICA+IE9uIDExIE9jdCAyMDE5LCBhdCAxMDow Miwgw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6 DQogICAgPiANCiAgICA+IMOJcmljIFZ5bmNrZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJh bGxvdCBwb3NpdGlvbiBmb3INCiAgICA+IGRyYWZ0LWlldGYtaXBzZWNtZS1pbXBsaWNpdC1pdi0w NzogRGlzY3Vzcw0KICAgID4gDQogICAgPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRo ZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCiAgICA+IGVtYWlsIGFkZHJl c3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0 aGlzDQogICAgPiBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCiAgICA+IA0KICAg ID4gDQogICAgPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0 ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQogICAgPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KICAgID4gDQogICAgPiAN CiAgICA+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBj YW4gYmUgZm91bmQgaGVyZToNCiAgICA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtaXBzZWNtZS1pbXBsaWNpdC1pdi8NCiAgICA+IA0KICAgID4gDQogICAgPiAN CiAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+IERJU0NVU1M6DQogICAgPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQogICAgPiANCiAgICA+IFRoYW5rIHlvdSBmb3IgdGhlIHdvcmsgcHV0IGludG8gdGhpcyBkb2N1 bWVudC4gSSBhbSB0cnVzdGluZyB0aGUgc2VjdXJpdHkgQUQgdG8NCiAgICA+IGNoZWNrIHdoZXRo ZXIgaXQgaXMgc2FmZSBub3QgdG8gaGF2ZSBhICdyYW5kb20nIElWLg0KICAgIA0KICAgIEnigJlt IHN1cmUgdGhleSB3aWxsLCBidXQgYXMgYW4gZXhwbGFuYXRpb24sIHNvbWUgYWxnb3JpdGhtcyBy ZXF1aXJlIGEgcmFuZG9tIElWLiBFeGFtcGxlcyBhcmUgQUVTIGluIENCQyBtb2RlLiBPdGhlciBh bGdvcml0aG1zIGRvIG5vdCByZXF1aXJlIGEgcmFuZG9tIElWLCBidXQgZG8gcmVxdWlyZSBhIHVu aXF1ZSBJVi4gVGhlIGRvY3VtZW50cyBkZXNjcmliaW5nIHN1Y2ggYWxnb3JpdGhtcyByZWNvbW1l bmQgdXNpbmcgZWl0aGVyIGEgc2ltcGxlIGNvdW50ZXIgb3IgYW4gTEZTUiB0byBnZW5lcmF0ZSB0 aGUgSVYuIEV4YW1wbGVzIGFyZSBBRVMgaW4gY291bnRlciBtb2RlIGFuZCBDaGFDaGEyMC4gIE91 ciBkcmFmdCBzcGVjaWZpZXMgSUlWIG9ubHkgZm9yIHRoZSBsYXR0ZXIga2luZCBvZiBhbGdvcml0 aG1zLg0KICAgIA0KICAgID4gSSBoYXZlIG9uZSB0cml2aWFsLXRvLWZpeA0KICAgID4gRElTQ1VT UyBhbmQgYSBjb3VwbGUgb2YgQ09NTUVOVHMuDQogICAgPiANCiAgICA+IEl0IGlzIGFsc28gdW5j bGVhciBhdCBmaXJzdCBzaWdodCB3aGV0aGVyIHRoZSAnbm9uY2UnIGJ1aWx0IGZyb20gdGhlIHNl cXVlbmNlDQogICAgPiBudW1iZXIgaXMgYWN0dWFsbHkgdGhlIElJVi4NCiAgICANCiAgICBBbHRo b3VnaCB0aGV5IHVzZSB0aGUgc2FtZSBmaWVsZHMsIHRoZSBsaXRlcmF0dXJlIHRlbmRzIHRvIGNh bGwgdGhlIHJhbmRvbSBraW5kIGFuICJJbml0aWFsaXphdGlvbiBWZWN0b3IiIGFuZCB0aGUgbXVz dC1ub3QtcmVwZWF0IGtpbmQgYSDigJxOb25jZeKAnS4gIEluIElQc2VjIHRoZSBmaWVsZCBpcyBj YWxsZWQgSVYsIHNvIHRoZXJlIGlzIHNvbWUgY29uZnVzaW9uIGluIHRoZSB0ZXJtcy4NCiAgICAN CiAgICA+IA0KICAgID4gUmVnYXJkcywNCiAgICA+IA0KICAgID4gLcOpcmljDQogICAgPiANCiAg ICA+ID09IERJU0NVU1MgPT0NCiAgICA+IA0KICAgID4gLS0gU2VjdGlvbiAxIC0tDQogICAgPiBE LjEpIFBsZWFzZSB1c2UgdGhlIFJGQyA4MTc0IHRlbXBsYXRlIDspDQogICAgDQogICAgUmlnaHQs IG91ciBiYWQuICBUaGlzIGlzIHByb2JhYmx5IGJlY2F1c2UgdGhpcyBkb2N1bWVudCBoYXMgYmVl biBtYWtpbmcgdGhlIHJvdW5kcyBmb3Igb3ZlciAzIHllYXJzLiBXaWxsIGZpeC4NCiAgICANCiAg ICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+IENPTU1FTlQ6DQogICAgPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog ICAgPiANCiAgICA+ID09IENPTU1FTlRTID09DQogICAgPiAtLSBTZWN0aW9uIDUgLS0NCiAgICA+ IEMuMSkgImluc2lkZSB0aGUgU0EgUGF5bG9hZCIgcHJvYmFibHkgd29ydGggYmVpbmcgYSBsaXR0 bGUgbW9yZSBkZXNjcmlwdGl2ZQ0KICAgID4gaGVyZSAoZm9yIGluc3RhbmNlLCAiU0EgcGF5bG9h ZCBpbiB0aGUgSUtFIGV4Y2hhbmdlIiA/KS4gIEFsc28gc3VnZ2VzdCB0byB1c2UNCiAgICA+ICJJ S0UgSW5pdGlhdG9yIEJlaGF2aW9yIiBmb3IgdGhlIHNlY3Rpb24gdGl0bGUuDQogICAgDQogICAg T0sNCiAgICANCiAgICA+IC0tIFNlY3Rpb24gOCAtLQ0KICAgID4gQy4yKSBwbGVhc2UgdXNlIHRo ZSB1c3VhbCB0ZXh0IGZvciBJQU5BIGNvbnNpZGVyYXRpb25zIChub3RhYmx5IGFza2luZyBJQU5B IHRvDQogICAgPiByZWdpc3RlciBhcyB0aGlzIGlzIG5vdCB0aGlzIGRvY3VtZW50IHRoYXQgcmVn aXN0ZXJzIHRoZSBjb2RlcykuDQogICAgDQogICAgWWVzLCBzaW5jZSB3ZSByZWNlaXZlZCBlYXJs eSBhc3NpZ25tZW50IEkgdGhpbmsgd2Ugc2hvdWxkIGdvIHdpdGggdGhlIOKAnElBTkEgaGFzIGFz c2lnbmVkIHRoZSBmb2xsb3dpbmcgdmFsdWVz4oCm4oCdIHRleHQsIGFuZCBsZWF2ZSBhIHJlbWlu ZGVyIHRoYXQgdGhlIHJlZmVyZW5jZSBzaG91bGQgYmUgdXBkYXRlZC4NCiAgICANCiAgICA+IA0K ICAgID4gPT0gTklUUyA9PQ0KICAgID4gDQogICAgPiBJbiBzZXZlcmFsIHBsYWNlcywgcy84IGJ5 dGUgbm9uY2UvOC1ieXRlIG5vbmNlLw0KICAgIA0KICAgIFdpbGwgZml4Lg0KICAgIA0KICAgIA0K DQo= From nobody Fri Oct 11 06:28:48 2019 Return-Path: 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 9495612008F for ; Fri, 11 Oct 2019 06:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 hQqnkklIIaf7 for ; Fri, 11 Oct 2019 06:28:44 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46127120073 for ; Fri, 11 Oct 2019 06:28:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id A2C9B6211F; Fri, 11 Oct 2019 09:28:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZfXrYBAb49Rr; Fri, 11 Oct 2019 09:28:38 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 53A946211E; Fri, 11 Oct 2019 09:28:38 -0400 (EDT) To: Michael Richardson Cc: IPsec@ietf.org References: <288a46b0-fa99-b070-362b-d0f0edbcab4b@htt-consult.com> <19298.1570786008@dooku.sandelman.ca> From: Robert Moskowitz Message-ID: <4e823970-3907-a854-d41d-a97e19379e01@htt-consult.com> Date: Fri, 11 Oct 2019 09:28:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <19298.1570786008@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [IPsec] IPSECKEY Resource Record Parameter for EdDSA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 13:28:47 -0000 On 10/11/19 5:26 AM, Michael Richardson wrote: > Robert Moskowitz wrote: > > Is there an update for EDDSA (RFC 8420) for the ipseckey RR? > > > https://www.iana.org/assignments/ipseckey-rr-parameters/ipseckey-rr-parameters.xhtml > > > IANA is not showing it, so perhaps it is in a draft somewhere? > > I haven't done this. > It's marked IETF Review, so a document is needed (but necessarily standards > track). > What's your use case today? Surely not tm-rid? Yes it is tm-rid.  Look for a revision to https://datatracker.ietf.org/doc/draft-moskowitz-hip-hhit-registries/ Any observer should have access to the HI on observing the HIT in the RemoteID Basic Message.  This is needed to validate the signature in the Authentication Message. Only an authorized observer can query the USS for more information (as Stu alluded to) about the UAV.  In the ASTM docs we cannot release yet (grumble) they propose both SAML and JSON for the query for these details by an authorized observer. Thus only the HI/HIT will be returned in the DNS query.  RVS is normally restricted information. Bob From nobody Fri Oct 11 06:35:16 2019 Return-Path: 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 5E16E120090 for ; Fri, 11 Oct 2019 06:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 xXDBheB-G9hm for ; Fri, 11 Oct 2019 06:35:14 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4678E120073 for ; Fri, 11 Oct 2019 06:35:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 250A36211F; Fri, 11 Oct 2019 09:35:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cXDeBLimlbZC; Fri, 11 Oct 2019 09:35:07 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id DF56D6211E; Fri, 11 Oct 2019 09:35:06 -0400 (EDT) To: Michael Richardson Cc: Paul Wouters , IPsec@ietf.org References: <288a46b0-fa99-b070-362b-d0f0edbcab4b@htt-consult.com> <1fd511e8-c5bf-141e-821f-da38ae3fe4cf@htt-consult.com> <20375.1570787044@dooku.sandelman.ca> From: Robert Moskowitz Message-ID: Date: Fri, 11 Oct 2019 09:35:03 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <20375.1570787044@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [IPsec] IPSECKEY Resource Record Parameter for EdDSA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 13:35:16 -0000 On 10/11/19 5:44 AM, Michael Richardson wrote: > Robert Moskowitz wrote: > > At some point I am going to need one, as 8005 references IPSECKEY for > > its RR and I am using EdDSA for the tm-rid work. > > I was surprised at the 8005 reference to IPSECKEY, since it seemed wrong that > a IPSECKEY RR would point at some machine that was going to answer with HIP > and not IKEv2... but now I see that you have your own RR, but share the > algorithm numbers with IPSECKEY. there was an attitude to not maintain 2 separate number spaces.  Now I have to live with that (how would I handle the ECDH Identities for HIP-DEX which I do not belive IKE has anything similar?) > It seems that your tm-rid work can just amend this IANA registry. > If you had a WG, you could ask for an early allocation. I don't think that > the IPSEC WG chairs could ask for an early allocation for you at this point, > alas. The way I see it, rfc 8420 'requires' this allocation.  I suspect whatever works for 8420 will work for draft-moskowitz-hip-new-crypto. So I am being 'nice' and asking the owners of the IPSECKEY namespace to fix what I see as a shared problem.  I really don't want to go down a path of having a tm-rid wg doing the allocation. Bob From nobody Fri Oct 11 06:59:41 2019 Return-Path: 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 E522E12004D for ; Fri, 11 Oct 2019 06:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 vK24S_GZIh_W for ; Fri, 11 Oct 2019 06:59:37 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADDFA12003F for ; Fri, 11 Oct 2019 06:59:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.67,284,1566856800"; d="scan'208";a="322423050" X-MGA-submission: =?us-ascii?q?MDHr0VVaYkKi6cSf6sXi7oyKdpRsAdSqTZ3u4T?= =?us-ascii?q?7DWrHKV7JLOC5roDv7BmFnFREFaKasbt6zSngTNJtYOCvMQLKANvOoFs?= =?us-ascii?q?qZSJml4CHp/CP7kPsz2SnAUxee+MGbG1r9hs5Z5gj7S0YQcNZ2ma7nF4?= =?us-ascii?q?iJccbfTZ33CYOmZ4/qSctqOQ=3D=3D?= Received: from zcs-store1.inria.fr ([128.93.142.28]) by mail3-relais-sop.national.inria.fr with ESMTP; 11 Oct 2019 15:59:32 +0200 Date: Fri, 11 Oct 2019 15:59:32 +0200 (CEST) From: Tristan Ninet To: Tero Kivinen , Valery Smyslov Cc: Paul Wouters , "ipsec@ietf.org WG" , Olivier Zendra , romaric maillard Message-ID: <1531560408.4631274.1570802372648.JavaMail.zimbra@inria.fr> In-Reply-To: <23948.33900.216096.521743@fireball.acr.fi> References: <94576796.2706392.1569086539715.JavaMail.zimbra@inria.fr> <23948.33900.216096.521743@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [131.254.17.142] X-Mailer: Zimbra 8.7.11_GA_3800 (ZimbraWebClient - FF69 (Linux)/8.7.11_GA_3800) Thread-Topic: A Novel Denial-of-Service Attack Against IKEv2 - HAL-Inria Thread-Index: iRgoD5XXQCGEsFbx6MFDY8l9oUI2cw== Archived-At: Subject: Re: [IPsec] FYI: A Novel Denial-of-Service Attack Against IKEv2 - HAL-Inria X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 13:59:40 -0000 Hi, I do not have the time to answer right now, but I will do so later. Best regards, Tristan Ninet ----- Mail original ----- > De: "Tero Kivinen" > =C0: "Tristan Ninet" > Cc: "Paul Wouters" , "ipsec@ietf.org WG" = , "Olivier Zendra" , > "romaric maillard" > Envoy=E9: Jeudi 26 Septembre 2019 11:27:08 > Objet: Re: [IPsec] FYI: A Novel Denial-of-Service Attack Against IKEv2 - = HAL-Inria > Tristan Ninet writes: >> Dear Mr. Wouters, >>=20 >> Thank you for your interest in our work. >>=20 >> > I've read through the paper, and I believe is very much misrepresents = what it >> > deems is a DoS attack against the IKEv2 protocol. >> > >> > The DoS attack described seems to think it can change the IP address a= nd cause >> > Initiator to be authenticated by a different peer than intended (ignor= ing all of >> > IDi / IDr payloads it is relaying). Then the different peer is happy, = but the >> > last IKE_AUTH reply to the initiator would signify a failure. Then whe= n the >> > initiator sends an Informational message with a Delete payload and >> > AUTHENTICATION_FAILED notify, the attacker drops the message. Now the = different >> > peer has "lost resources" since its IKE SA (and possibly IPsec SA) is = up. A >> > proper implementation would send a Liveness probe if its IPsec SA coun= ters >> > remain zero. It would also put an idle limit on an childless SA that r= esulted >> > from a TS_UNAVAILABLE (as opposed to a by design childless IKE SA) >>=20 >> Let us denote Initiator by A, Responder by B, Victim by C, IKE_SA_INIT r= equest >> by m1, IKE_SA_INIT response by m2, IKE_AUTH request by m3, and IKE_AUTH = response >> by m4. >>=20 >> I understand you are saying that authentication of A to C would fail bec= ause of >> IDi and IDr payloads. >=20 > Normally authentication from A to C will fail because of different > authentication information. I.e., if they are using pre-shared keys > the pre-shared key for A to B is different than A to C (unless B and C > are part of same infrastructure, i.e., load-sharing or high > availaibility pairs). If A is using certificates then usually it has > two different CA infrastructures one for B and one for C, so C will > not accept certificate meant for B and will fail authentication. >=20 > You can get this work if B and C are sharing configuration i.e., they > are two different gateways in the same adminstrative domain. >=20 >> However, we put as a requirement to the attack that C trusts A, i.e. C h= as some >> configuration entry with the ID of A. In this case, authentication will = succeed. >=20 > You also put restriction that A shares exactly same authentication > information for B and C both. This is not normal for cases where B and > C are independent. >=20 >> You then say that a proper implementation would send a Liveness probe if= its >> IPsec SA sequence numbers remain zero. >>=20 >> The RFC does say that Liveness checks are needed. In this regard, strong= swan and >> libreswan do not follow the RFC since in both implementations, Dead Peer >> Detection (DPD) is disabled by default. >=20 > RFC says: >=20 >=09=09=09=09=09=09=09=09If no > cryptographically protected messages have been received on an IKE SA > or any of its Child SAs recently, the system needs to perform a > liveness check in order to prevent sending messages to a dead peer. >=20 > Usually DPD will be have timeout of 10-30 seconds, i.e., after initial > silence, i.e., if there is nothing happening in the IKEv2 SA after > final IKE_AUTH in few tens of seconds C will send DPD message to A and > will not get reply to that, and C will delete the IKE SA after few > minutes. >=20 >> However, DPD does not deter the attack. A classic flooding DoS attack ca= n only >> set up half-open SAs. An IKEv2 implementation should remove half-open SA= s after >> some short time. In strongswan by default half-open SAs are removed afte= r 30s. >> Therefore a high-rate of m1 messages is needed to achieve memory exhaust= ion >> using classic flooding against IKEv2. >>=20 >> However, the Deviation attack sets up full IKE SAs (if not Child SAs as = well) in >> C. We measured that a full connection (one IKE SA + one Child SA) is 23k= B in >> strongswan, whereas a half-open SA is 1kB. This divides by 23 the minimu= m >> throughput of m1 messages to deviate in order to exhaust the memory of C= . >=20 > Note, that sending classic flooding attack packets requires no effort > from the attacker. Settting up full IKEv2 SA do require > Diffie-Hellmans, Certificate verifications etc, thus rate you can set > them up is much more limited than classic case. The maximum number of > IKEv2 SAs that can be set up each second is usually in order of > hundreds or thousands, thus even if it uses 23kB for two minutes > (until DPD kicks them out) that is only few gigabytes of memory. > Older phones would run out of memory at that point, but newer ones > have more memory than that... >=20 > Also as you are relying for A to set initiate the connection you can > only set up one connection per few minutes, as A will not immediately > retry connection to B/C when it receives IKE_AUTH message failing > authentication. The RFC does not provide instructions for this case, > but authentication failure in IKE_AUTH means there is something wrong > that most likely will not be automatically fixed, the clients usually > wait for some time before retrying. I.e., if you are waiting for > adminstrator of either end to go and fix the authentication > information in configuration there is no point retrying every second. > You can try every 30 seconds without any issues, and still almost > immediately detect when other end fixes their configuration. >=20 >> In strongswan, when DPD is enabled, by default, connections with a dead = peer >> (such as in the Deviation Attack) are removed after dpdtimeout + total >> retransmission timeout =3D 30s + 165s =3D 195s. It does not make sense t= o go much >> lower, and some implementations might want to set this timeout higher so= that >> bandwidth is not overwhelmed. This longer stay of undesirable connection= s in C's >> memory divides by 6 the minimum throughput of m1 messages to deviate in = order to >> exhaust the memory of C. >=20 > So if A tries every 30 seconds and C keeps it in memory for 200 > seconds that still means we only have 6-7 of them active at one time. > Not really proper attack. >=20 >> In total the Deviation Attack thus divides the required throughput by 14= 0. In >> consequence the DA is much harder to detect using intrusion detection sy= stems >> than classic DoS attacks, in particular when DPD timeout is high. >=20 > You seem to be assuming that A will retry immediately when it gets > authentication failure? Even if it did that usually the setup time > needed for one IKEv2 SA is in order of second or so, so getting more > than one connection per second from the same host A is difficult (2 * > RTT + Diffie-Hellman calculations + certificate calculations). Even > with new connectiona attempt every second you only have few hundred > extra IKEv2 SAs. >=20 >> In strongswan, when DPD is disabled, connections with a dead peer are re= moved at >> the time of rekeying, i.e. by default 3h. A DoS with a throughput 8000 t= imes >> lower than classic DoS techniques is then possible. >=20 > Disabling DPD is bad idea, and if you do that, then you are asking > for it... >=20 >> On the other hand, the requirements for the attack are quite strong. Fir= stly, >> the attacker needs to have some control over the connection between A an= d B. >> Secondly, all Initiator parties authenticate themselves using signature = mode and >> are trusted by Victim. Thirdly, the attacker needs to find enough m1 mes= sages to >> deviate. In addition, each m1 message must come from a different IKEv2 p= eer. >> Otherwise connections will simply replace current connections with the s= ame >> peer. In fact I did not see this behavior in the RFC, but strongswan beh= aves >> this way by default. >=20 > Normally each new connection has INITIAL_CONTACT notification which > tells the responder that this replaces all previous connections with > same authenticated peers. I assumed you had assumed that > INITIAL_CONTACT notifications would have been disabled on A to get > this attack working at all, as I assume you forced A to do multiple > connections right after each other. >=20 > On the other hand here you do assume that we simply take normal m1 > messages going to B and redirect them to C also, which means that the > load of C can at most be same than B, thus you do not really do Denial > of Service attack, you just cause some extra load to C. I mean if B > and C are required to be part of same authentication infrastructure, > you can assume that they have about same amount of resources, thus > C has no problem of handling the same load B is having. >=20 >> The contribution of the paper is to point out that when the above requir= ements >> are satisfied, then an attacker may perform a DoS attack with a signific= antly >> lower throughput than expected from classic flooding techniques. >=20 > I would say the throughput is much lower than normal operational case > on the Monday morning problem. I.e., when gateways are assumed to be > able to handle 100-1000 times of normal load every now and then and > still process operations without major delays. This throughput seems > to be lower than that. >=20 >> You also say that a proper implementation would put an idle limit on an >> childless SA that resulted from a TS_UNAVAILABLE (as opposed to a by des= ign >> childless IKE SA). I think you mean TS_UNACCEPTABLE. I cannot find this = behavior >> anywhere in the RFC. But even if it is true, the point I made above stay= s valid. >=20 > Most implementations uses something like 30 second timer for that. If > the initiator has some other Child SAs to be set up they will do it > immediately after the IKE_AUTH finishes, thus you just need to wait > for few tens of seconds for them. If they do not have any other Child > SAs to create there is no point of keep extra IKE SA up. >=20 > RFC do not provide all possible implementation detail, quite a lot of > corner cases are left for implementors to solve. RFC8019 does have > some discussion about these issues, even though it mostly concentrates > on the half open SA problem, as that is hardest to protect against. >=20 >> > It makes more wrong assumptions like "(TS negotiation will fail in mos= t cases)" >> > which I guess they think would fail because the different peer's have = different >> > IPsec SA configurations, but really if they are that different, they w= ill also >> > have different IDi/IDr payloads because a peer's configuration with ma= ny other >> > peers for specific subnets would be configured with local/remote IDs a= s to not >> > tie these to hardcoded IP addresses. Without explicit ID, the ID used = is >> > normally the ID_IPvx, and if that is used, using an IP address X with = ID_IPv4 Y >> > will also cause an IKE failure of the victim peer because for IP addre= ss X it >> > would then expect ID_IPv4 X. >>=20 >> You say that our assumption that TS negotiation will fail in most cases = is >> wrong. Even if this assumption is wrong it only makes the attack stronge= r, as an >> even heavier connection is installed in C. >>=20 >> You say that authentication using ID_IPvx will fail because A would be u= sing >> different IP addresses in its IDi and in the source address of the m3 pa= cket. >> However, in the attack the deviation only changes the destination addres= s, not >> the source address. Thus no such failure would occur. >=20 > ID_IPvx and outer IP does not have anything common. It is completely > possible and valid for node to send ID_IPv4 identity of 10.0.0.1 from > completely different IP-address. From the RFC7296 section 3.5: >=20 >=09 =09 =09=09 =09 =09 When using the > ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 > does not require this address to match the address in the IP header > of IKEv2 packets, or anything in the TSi/TSr payloads. >=20 > Also the most common road warrior setup would be any<->any traffic > selectors, and leave the narrowing for the responder, so C will > happily narrow that range down to something that is useful for him. >=20 >> However, as I said above, the attack does assume that each m1 message co= mes >> from a different IKEv2 peer. It is obvious that if the attack works with= Ndemo >> Initiators and the "uniqueids=3Dnever" option set in Victim, then it wor= ks in the >> same setup but with N Initiators and without the "uniqueids=3Dnever" opt= ion in >> Victim. >=20 > If you assume that each m1 comes for differnet legitimite IKEv2 peer, > you only provide work factor of 2, which is very very low... > Especially when you compare that to Monday morning problem where work > factor might suddenly be raised by 100 or 1000 times the normal load. >=20 > If you can cause C to provide any kind of visibile change of behavior > with work factor of 2 then C is completely misconfigured and > underresourced and will fail in normal use every now and then anyways. >=20 >=20 >> > It goes on to say the attack is not possible with PSKs, which I don't >> > understand.. They also then mumbled about asymmetric authentication, w= hich I >> > don't understand, but regardless is basically only employed with EAPTL= S and >> > Remote Access VPNs, so it does not apply to this attack. >>=20 >> When we said that the attack is not possible with PSKs, we assumed that = the PSK >> between A and B is different than the PSK between A and C. In this case, >> authentication of A to C will fail and the attack does not work because = no SA in >> installed in C. >=20 > Note, that it is also does not work for certificates, as CA trust > anchors configured for B and C are different, thus C will not accept > A's certificate as it is not signed by proper CA for C, it is signed > with trust anchor used for B. Only time where B and C uses same > certificate authorities is when they are part of same authentication > domain. >=20 > In IPsec we do not have similar common trusted CA list than we have in > web. Each adminstrative domain will configure the CAs they trust > separately, and quite often those CAs are separate CAs only for IPsec > use for that specific gateway. > -- > kivinen@iki.fi From nobody Sun Oct 13 00:10:42 2019 Return-Path: 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 C4E7A1200D6; Sun, 13 Oct 2019 00:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 272HoaOcLwHu; Sun, 13 Oct 2019 00:10:38 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id F08F9120025; Sun, 13 Oct 2019 00:10:37 -0700 (PDT) Received: from stubbs.int.chopps.org (unknown [172.222.100.236]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 2256F6061F; Sun, 13 Oct 2019 03:10:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Christian Hopps In-Reply-To: <90A18DDA-F20B-4B0C-8FB6-EF5969F7B121@nohats.ca> Date: Sun, 13 Oct 2019 03:10:36 -0400 Cc: Christian Hopps , ipsecme-chairs@ietf.org, Paul Wouters , mcr@sandelman.ca Content-Transfer-Encoding: quoted-printable Message-Id: <2DD52B3F-B503-42FC-B8BF-26DBEAEE04A7@chopps.org> References: <90A18DDA-F20B-4B0C-8FB6-EF5969F7B121@nohats.ca> To: "ipsec@ietf.org WG" X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [IPsec] Possible new charter text to cover iptfs. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2019 07:10:40 -0000 Hi ipsecme and charis, It seems like we've had a good amount of soak time on this. :) What are the next steps? Thanks, Chris. > On Aug 7, 2019, at 7:04 PM, Paul Wouters wrote: >=20 > Seems broad enough - works for me >=20 > Sent from mobile device >=20 >> On Aug 7, 2019, at 06:38, Christian Hopps wrote: >>=20 >> Hi ipsecme and chairs, >>=20 >> As discussed @IETF105 we need to update the charter in order to adopt = the IPTFS draft, how does this look for addition to the charter? >>=20 >> " >> The demand for Traffic Flow Confidentiality has been increasing in = the user >> community; however, the current method defined in RFC4303 (i.e., add = null >> padding to each ESP payload) is very inefficient in it's use of = network >> resources. The working group will develop an alternative TFC solution = that >> provides for efficient use of network resources. >> " >>=20 >> Thanks, >> Chris. >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 From nobody Mon Oct 14 06:21:51 2019 Return-Path: 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 8F455120137; Mon, 14 Oct 2019 06:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=EU8CE7wr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TaJdYVJX 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 Azeioic8aXlv; Mon, 14 Oct 2019 06:21:47 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62BD12010F; Mon, 14 Oct 2019 06:21:44 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1329D21E3E; Mon, 14 Oct 2019 09:21:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 14 Oct 2019 09:21:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=Q Hz1313S5KKed3VBGJ9Ze6hu+gQDSqPZ1LVqh2uJsy8=; b=EU8CE7wrGAWsWbWMb CuUs6tFmd428JnEGMd6i963y5mCYaalooS/F6flBK37hZHOoLtN8ZhSmI2FyOP/X jInf+AGj1uvs7mWwkI6SdzIXihez8jxXxxZUVkAVWvZULyb0hlmL2QX6EzXC3Py2 2Swq6UMcLEi/hiKCCOvieX4E6TlRGUCTqAYrduGx4PLz3xf6qampdg/F10qAPhCG LPtNTtTakRrYK9ie2jJLMIad1HaQQIZRa4T2n5idfD48/eKUdr/nGpnzK1sQ3kUs V3JGn//uWbh4GervS2G2kewcvfI/4gDQdKK1TaqwrGKs6kvABuKpvrvmq0FXrcOF djXVA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=QHz1313S5KKed3VBGJ9Ze6hu+gQDSqPZ1LVqh2uJs y8=; b=TaJdYVJXFMc+VsLw+w1HPR+8fEneW+W8gC4JRcroI+G6MmAdPEJ+vHidS VbCBV/Ioz/Wb/wwzS/0WmO2E+8VpM63taSoLaaM1rqntubvUD7GrpBF9kaX6NFDH AyTcpYgKeMblv9aCrKumhXt54UNukm7A8u9oUAS7guIEleOYbcGEaQIck0b5BTGe 9JTYJDQDw5tjkozCpcHicmyzhJ3e3hSVBomevJscaCsJCaJx61C9d1MMDsHKoOqi KloxCXgKIDPcVM4BAq+LMuPNtianCoXXts6nFIf9nezhAHYNlGL6ikypvXtspOe0 Wxny2tRRmJ7rfl4YpXw6vpwZbDplQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrjedugdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtvdenucfhrhhomheptehlihhsshgrucevohhophgvrhcuoegrlhhishhsrgestgho ohhpvghrfidrihhnqeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeejvddrud eifedrvddrvdefjeenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtohho phgvrhifrdhinhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [10.24.168.111] (unknown [72.163.2.237]) by mail.messagingengine.com (Postfix) with ESMTPA id A233880062; Mon, 14 Oct 2019 09:21:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <156960911643.12419.11856828548296442014@ietfa.amsl.com> Date: Mon, 14 Oct 2019 09:21:38 -0400 Cc: gen-art@ietf.org, ipsec@ietf.org, ietf@ietf.org, draft-ietf-ipsecme-implicit-iv.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1567984F-5014-48A6-8D96-2619342BBB9E@cooperw.in> References: <156960911643.12419.11856828548296442014@ietfa.amsl.com> To: Joel Halpern X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [IPsec] [Gen-art] Genart last call review of draft-ietf-ipsecme-implicit-iv-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 13:21:50 -0000 Joel, thanks for your review. I entered a No Objection ballot. Alissa > On Sep 27, 2019, at 2:31 PM, Joel Halpern via Datatracker = wrote: >=20 > Reviewer: Joel Halpern > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-ipsecme-implicit-iv-07 > Reviewer: Joel Halpern > Review Date: 2019-09-27 > IETF LC End Date: 2019-10-07 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: THis document is ready for publication as a Proposed Standard >=20 > Major issues: N/A >=20 > Minor issues: N/A >=20 > Nits/editorial comments: N/A >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Mon Oct 14 16:15:09 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5151208E0; Mon, 14 Oct 2019 16:15:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen , ipsecme-chairs@ietf.org, kivinen@iki.fi, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <157109490777.24664.9512388993983573410.idtracker@ietfa.amsl.com> Date: Mon, 14 Oct 2019 16:15:07 -0700 Archived-At: Subject: [IPsec] Benjamin Kaduk's Discuss on draft-ietf-ipsecme-implicit-iv-07: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 23:15:08 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-ipsecme-implicit-iv-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Please address the issue raised by the secdir reviewer where AES-CTR is covered in the text but no codepoint allocated. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 2 nit: s/In some context/In some contexts/ This document limits its scope to the algorithms mentioned above. Other algorithms with similar properties may later be defined to use this extension. I'd suggest rewording this part; the "extension" here is just the per-algorithm codepoint for the IIV variant of the encryption transform, so what would be reused is probably better described as a "mechanism" or similar than an "extension". Section 4. With the algorithms listed in Section 2, the 8 byte nonce MUST NOT repeat. The binding between a ESP packet and its nonce is provided I suggest s/MUST NOT repeat/MUST NOT repeat for a given key/. nit: s/a ESP/an ESP/ Section 4 This document solely defines the IV generation of the algorithms defined in [RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [RFC7634] for ChaCha20-Poly1305. Any other aspect (including using the Key Length attribute) of applying those ciphers with the new Transform Types defined in this document MUST be taken from the documents defining the use of the algorithms in ESP. I suggest s/defines/modifies/; the whole paragraph is slightly confusing to read and could perhaps be reworded to something like "This document solely modifies the IV generation for the algorithms defined in [RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [RFC7634] for ChaCha20-Poly1305. All other aspects and parameters of those algorithms are unchanged, and are used as defined in their respective specifications." Section 7 nit: the title should be "Security Considerations" plural. I suggest to reiterate the RFC 4303 requirement for SAs to be closed or rekeyed before sequence numbers grow too large to fit in 32 bits (for "legacy" Sequence Number) or 64 bits for ESN. This prevents sequence number overlaps for the mundane point-to-point case. This document defines three new encryption transforms that use implicit IV. Unlike most encryption transforms defined to date, which can be used for both ESP and IKEv2, these transforms are defined for ESP only and cannot be used in IKEv2. The reason is that IKEv2 messages don't contain unique per-message value, that can be used for IV generation. The Message-ID field in IKEv2 header is nit: s/unique/a unique/ nit: s/value,/value/ From nobody Tue Oct 15 05:11:44 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 420D012008A; Tue, 15 Oct 2019 05:11:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen , ipsecme-chairs@ietf.org, kivinen@iki.fi, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <157114150226.18104.2305500883432225536.idtracker@ietfa.amsl.com> Date: Tue, 15 Oct 2019 05:11:42 -0700 Archived-At: Subject: [IPsec] Roman Danyliw's No Objection on draft-ietf-ipsecme-implicit-iv-07: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 12:11:42 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-ipsecme-implicit-iv-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** I support the DISCUSS position held by Ben Kaduk. (Derived from Magnus Nystrom’s SECDIR review) The abstract, Section 2, Section 4 and Section 7 make references to AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 (four algorithms). However, Section 4 also states “This document solely defines the IV generation of the algorithms defined in [RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [RFC7634] for ChaCha20-Poly1305” (i.e., AES-CTR is missing). Likewise, no new code point is assigned for AES-CTR in Section 8. If AES-CTR is not in scope, then please don’t mention it in the draft. If it was missed from Section 4 and 8, please add it. ** Section 7. I’m having difficulty reconciling these two sentences: (1) Nonce generation for these algorithms has not been explicitly defined.” (2) This document provides an explicit and normative way to generate IVs. Isn’t this text saying the Nonce = Sequence number = IV? ** Section 7. Editorial. s/the IV is not allowed being repeated for one particular key./the IV is not allowed to be repeated for a particular key./ ** Section 7. Editorial. s/The Message-ID field in IKEv2 header is somewhat counterpart of SN field in ESP header, but recent …/The Message-ID field in IKEv2 header is similar to the SN field in ESP header. However recent …/ From nobody Tue Oct 15 05:48:56 2019 Return-Path: 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 B12E31200B8; Tue, 15 Oct 2019 05:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 ovb-8BxIYJTM; Tue, 15 Oct 2019 05:48:39 -0700 (PDT) Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) (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 A3F0F120091; Tue, 15 Oct 2019 05:48:39 -0700 (PDT) Received: by mail-ua1-f45.google.com with SMTP id l13so6017642uap.8; Tue, 15 Oct 2019 05:48:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ST/DQXbeadRbTTMGodMCzl7I5bGWGbNehmvIvgw074Y=; b=O7L4GK7P+DQBEJpH2HVF2Aw8vgUP950m+t64tRtB+Kvkin8733FbvE6myQyqMZBdnu MmT6vWktZ/ddJeDQ213vvEN1QEXTB5ISSM0/yNkCAUOjPHdtahoXn5lJYxiJnOounXVN iType6873JcO03lHGQLG845kwfNUGoTVV5QllAxc5XL/Gaxqya7UFu/dR2nnpUBFg0+L EH1zwjhQgJNs3HKXyI52lb15MXajqKuItF1ASWXOtlqrcgtyh8KVG44F4BczwtpsaZNV VaSD9RG/P7yf81vrx8GGnEhzKBSjczbZGChEsdfIfU055VWXMGdAnVmHscy7oyd5/DT0 mDeg== X-Gm-Message-State: APjAAAUGaDmUs6kO+piMUiRPAoR6DBgP0gkDiDHGzEiYwGfX9d+0uKXf 9Rcm80N+crTvsWJaIEpOiJx0NuM8q3gwDWBBifrAzHEu X-Google-Smtp-Source: APXvYqxDCCZZEn+A52COnGi+59PVjEhnTfsN1xzi+NBmM7hD+3ObyYAqTDCkNILmGrBjouRL/16AUrOu58vepBbOEB4= X-Received: by 2002:ab0:55c8:: with SMTP id w8mr6718193uaa.66.1571143718542; Tue, 15 Oct 2019 05:48:38 -0700 (PDT) MIME-Version: 1.0 References: <156960911643.12419.11856828548296442014@ietfa.amsl.com> <1567984F-5014-48A6-8D96-2619342BBB9E@cooperw.in> In-Reply-To: <1567984F-5014-48A6-8D96-2619342BBB9E@cooperw.in> From: Daniel Migault Date: Tue, 15 Oct 2019 08:48:27 -0400 Message-ID: To: Alissa Cooper Cc: Joel Halpern , IPsecME WG , "gen-art >> General area reviewing team" , ietf@ietf.org, draft-ietf-ipsecme-implicit-iv.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000003c22b40594f267e7" Archived-At: Subject: Re: [IPsec] [Gen-art] Genart last call review of draft-ietf-ipsecme-implicit-iv-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 12:48:43 -0000 --0000000000003c22b40594f267e7 Content-Type: text/plain; charset="UTF-8" Thanks for the review Alissa. Yours, Daniel On Mon, Oct 14, 2019 at 9:22 AM Alissa Cooper wrote: > Joel, thanks for your review. I entered a No Objection ballot. > > Alissa > > > > On Sep 27, 2019, at 2:31 PM, Joel Halpern via Datatracker < > noreply@ietf.org> wrote: > > > > Reviewer: Joel Halpern > > Review result: Ready > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > > > > For more information, please see the FAQ at > > > > . > > > > Document: draft-ietf-ipsecme-implicit-iv-07 > > Reviewer: Joel Halpern > > Review Date: 2019-09-27 > > IETF LC End Date: 2019-10-07 > > IESG Telechat date: Not scheduled for a telechat > > > > Summary: THis document is ready for publication as a Proposed Standard > > > > Major issues: N/A > > > > Minor issues: N/A > > > > Nits/editorial comments: N/A > > > > > > _______________________________________________ > > Gen-art mailing list > > Gen-art@ietf.org > > https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0000000000003c22b40594f267e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for=C2=A0the=C2=A0review Alissa.=C2=A0
Yours,= =C2=A0
Daniel

On Mon, Oct 14, 2019 at 9:22 AM Alissa Cooper <alissa@cooperw.in> wrote:
Joel, thanks for your re= view. I entered a No Objection ballot.

Alissa


> On Sep 27, 2019, at 2:31 PM, Joel Halpern via Datatracker <noreply@ietf.org> wro= te:
>
> Reviewer: Joel Halpern
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.=C2=A0 Please treat these comments just=
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq<= /a>>.
>
> Document: draft-ietf-ipsecme-implicit-iv-07
> Reviewer: Joel Halpern
> Review Date: 2019-09-27
> IETF LC End Date: 2019-10-07
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: THis document is ready for publication as a Proposed Standard=
>
> Major issues: N/A
>
> Minor issues: N/A
>
> Nits/editorial comments: N/A
>
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org=
> https://www.ietf.org/mailman/listinfo/gen-art<= br>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--0000000000003c22b40594f267e7-- From nobody Tue Oct 15 10:51:58 2019 Return-Path: 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 44B8B12010F; Tue, 15 Oct 2019 10:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 6vw6s4EkogeK; Tue, 15 Oct 2019 10:51:47 -0700 (PDT) Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com [209.85.221.180]) (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 E6480120020; Tue, 15 Oct 2019 10:51:46 -0700 (PDT) Received: by mail-vk1-f180.google.com with SMTP id d126so4547447vkb.1; Tue, 15 Oct 2019 10:51:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ESw5QHGIqdDOjHDhdbfWI0MSciB36pLF3OJjchjHirg=; b=Gwq/x75qtn0BmEJFq/VHgiADtHEYgk117BfDzNw4JmvsPwBCrJqKaDs1S6td8d0UR5 Qa0Qkr68HGdM99o9FP7mB8djQm96hPIHQ5smTU7TkE2aYl5IPDifAdSIw18MwOq70nCp XiXYHqQ+Y43kLBfWK3BZnRWb1+6Te7ouE2uAlqqX9i8/+0VJ7Z2NMWhm4Q6cFTSM9UlI swwh2NFSN+bLyT4vii97UhYON1Qt6wwmAk8nrqsj92P66L9uSqxuj1L00fptmhtoiwGN UWavKsn1u0pGyfQldD9jzITXjWFWQ5xSAGBc/w1huy/yB9DUDI7PAmwFBJf1++yOj6CW LKuA== X-Gm-Message-State: APjAAAW0zwgDmlwtrckKTCMUMCiO1bypnP9MvhHeV5MtoOGp1dNPMquS CzH079J8kNlyrydJ3RA2i0OENelDHIoNY23NhBo= X-Google-Smtp-Source: APXvYqy9EaRp7FFXuYlody+rXfGFNeK79+X7oC+aLoIH0FqyY1dKpvpOwDtnw4iuZOO5S3X1ntl236Bn/Xs1mjzeXx4= X-Received: by 2002:ac5:cdfa:: with SMTP id v26mr19666732vkn.30.1571161905175; Tue, 15 Oct 2019 10:51:45 -0700 (PDT) MIME-Version: 1.0 References: <157077732068.29461.12498226831215806070.idtracker@ietfa.amsl.com> <581E79DB-B1B7-4177-B747-7B12CA4AA64A@gmail.com> In-Reply-To: <581E79DB-B1B7-4177-B747-7B12CA4AA64A@gmail.com> From: Daniel Migault Date: Tue, 15 Oct 2019 13:51:34 -0400 Message-ID: To: Yoav Nir Cc: =?UTF-8?B?w4lyaWMgVnluY2tl?= , IPsecME WG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org, The IESG , Tero Kivinen Content-Type: multipart/alternative; boundary="0000000000003e218e0594f6a339" Archived-At: Subject: Re: [IPsec] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-ips?= =?utf-8?q?ecme-implicit-iv-07=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 17:51:49 -0000 --0000000000003e218e0594f6a339 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi =C3=89ric, Thanks for the review. Please find my response inline as well as the updated text: https://github.com/mglt/draft-mglt-ipsecme-implicit-iv/blob/master/draft-ie= tf-ipsecme-implicit-iv.txt We will probably publish the new version by tomorrow. Yours, Daniel On Fri, Oct 11, 2019 at 5:16 AM Yoav Nir wrote: > Hi, =C3=89ric. Please see inline. > > > On 11 Oct 2019, at 10:02, =C3=89ric Vyncke via Datatracker > wrote: > > > > =C3=89ric Vyncke has entered the following ballot position for > > draft-ietf-ipsecme-implicit-iv-07: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Thank you for the work put into this document. I am trusting the > security AD to > > check whether it is safe not to have a 'random' IV. > > I=E2=80=99m sure they will, but as an explanation, some algorithms requir= e a > random IV. Examples are AES in CBC mode. Other algorithms do not require = a > random IV, but do require a unique IV. The documents describing such > algorithms recommend using either a simple counter or an LFSR to generate > the IV. Examples are AES in counter mode and ChaCha20. Our draft specifi= es > IIV only for the latter kind of algorithms. > > > I have one trivial-to-fix > > DISCUSS and a couple of COMMENTs. > > > > It is also unclear at first sight whether the 'nonce' built from the > sequence > > number is actually the IIV. > > Although they use the same fields, the literature tends to call the rando= m > kind an "Initialization Vector" and the must-not-repeat kind a =E2=80=9CN= once=E2=80=9D. In > IPsec the field is called IV, so there is some confusion in the terms. > The current version tries to clarify that by being more consistent with the IPsec terminology - at least I hope so. This is correct that what IPsec calls nonce is also called IV in the literature. > > > > > Regards, > > > > -=C3=A9ric > > > > =3D=3D DISCUSS =3D=3D > > > > -- Section 1 -- > > D.1) Please use the RFC 8174 template ;) > > Right, our bad. This is probably because this document has been making > the rounds for over 3 years. Will fix. > > Fixed > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > =3D=3D COMMENTS =3D=3D > > -- Section 5 -- > > C.1) "inside the SA Payload" probably worth being a little more > descriptive > > here (for instance, "SA payload in the IKE exchange" ?). Also suggest > to use > > "IKE Initiator Behavior" for the section title. > > OK > Fixed > > > -- Section 8 -- > > C.2) please use the usual text for IANA considerations (notably asking > IANA to > > register as this is not this document that registers the codes). > > Yes, since we received early assignment I think we should go with the > =E2=80=9CIANA has assigned the following values=E2=80=A6=E2=80=9D text, a= nd leave a reminder that > the reference should be updated. > > Fixed > > > > =3D=3D NITS =3D=3D > > > > In several places, s/8 byte nonce/8-byte nonce/ > > Will fix. > > Fixed > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0000000000003e218e0594f6a339 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0 =C3=89ric,=C2=A0

Th= anks for the review.=C2=A0

Please find my response= inline as well as the updated=C2=A0text:
<= div>
We will probably publish the new version by tomorrow.=C2= =A0

Yours,=C2=A0
Daniel

On Fri, Oct 11, 2019 at = 5:16 AM Yoav Nir <ynir.ietf@gmail.com> wrote:
Hi, =C3=89ric.=C2=A0 Please see inline.

> On 11 Oct 2019, at 10:02, =C3=89ric Vyncke via Datatracker <noreply@ietf.org> wro= te:
>
> =C3=89ric Vyncke has entered the following ballot position for
> draft-ietf-ipsecme-implicit-iv-07: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/do= c/draft-ietf-ipsecme-implicit-iv/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Thank you for the work put into this document. I am trusting the secur= ity AD to
> check whether it is safe not to have a 'random' IV.

I=E2=80=99m sure they will, but as an explanation, some algorithms require = a random IV. Examples are AES in CBC mode. Other algorithms do not require = a random IV, but do require a unique IV. The documents describing such algo= rithms recommend using either a simple counter or an LFSR to generate the I= V. Examples are AES in counter mode and ChaCha20.=C2=A0 Our draft specifies= IIV only for the latter kind of algorithms.

> I have one trivial-to-fix
> DISCUSS and a couple of COMMENTs.
>
> It is also unclear at first sight whether the 'nonce' built fr= om the sequence
> number is actually the IIV.

Although they use the same fields, the literature tends to call the random = kind an "Initialization Vector" and the must-not-repeat kind a = =E2=80=9CNonce=E2=80=9D.=C2=A0 In IPsec the field is called IV, so there is= some confusion in the terms.

The curre= nt version tries to clarify that by being more consistent with the IPsec te= rminology - at least I hope so. This is correct that what IPsec calls nonce= is also called IV in the literature.=C2=A0 =C2=A0 =C2=A0

>
> Regards,
>
> -=C3=A9ric
>
> =3D=3D DISCUSS =3D=3D
>
> -- Section 1 --
> D.1) Please use the RFC 8174 template ;)

Right, our bad.=C2=A0 This is probably because this document has been makin= g the rounds for over 3 years. Will fix.

Fixed=C2=A0
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> =3D=3D COMMENTS =3D=3D
> -- Section 5 --
> C.1) "inside the SA Payload" probably worth being a little m= ore descriptive
> here (for instance, "SA payload in the IKE exchange" ?).=C2= =A0 Also suggest to use
> "IKE Initiator Behavior" for the section title.

OK
Fixed=C2=A0

> -- Section 8 --
> C.2) please use the usual text for IANA considerations (notably asking= IANA to
> register as this is not this document that registers the codes).

Yes, since we received early assignment I think we should go with the =E2= =80=9CIANA has assigned the following values=E2=80=A6=E2=80=9D text, and le= ave a reminder that the reference should be updated.

Fixed=C2=A0
>
> =3D=3D NITS =3D=3D
>
> In several places, s/8 byte nonce/8-byte nonce/

Will fix.

Fixed=C2=A0
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--0000000000003e218e0594f6a339-- From nobody Tue Oct 15 10:53:30 2019 Return-Path: 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 540941208E4; Tue, 15 Oct 2019 10:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 PN93PKNPH0uu; Tue, 15 Oct 2019 10:52:18 -0700 (PDT) Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) (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 46624120886; Tue, 15 Oct 2019 10:52:17 -0700 (PDT) Received: by mail-vs1-f42.google.com with SMTP id b1so13749278vsr.10; Tue, 15 Oct 2019 10:52:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=GEXykJHc0Ug2DuiLdRIPW3fR4fd+uGsnQjWf2xG66Yw=; b=P9QOiScJC3rBpyg9366m+CG0EBYEyp2BRKKRCJcMlMgX50AWTni2GsJwmXMIadJhmj zdNhw3SYzQPp+X8OQV3taj8PAz9726Lw6tBy71lRr16jVBTQXKBJpsFRdyMBbJ/N1RZ4 l/EAJ8zyucU+4WYc8gRvY0RNp0HaNyelsYoYV5Y+/sUmcGJ6pMdcH1IoeuGGqAA9wrW8 DGrGIQDciBL8Z1R5DJ/vQY3/Z90/DXlqFETv4xjfqpR/S6ipsO0HnPuhh6DmIaM/sylS V5dD0rI1u4owcoEatlAIQ5bfhil6hC7pWPMbQrSBBTQiPw9bXk0HxfZqUvJOLCA+RJOy dkpg== X-Gm-Message-State: APjAAAW6uX8nTiM4A8AlV/uheBdfMpnuyLMnnNVvk2WrM8p890OdktnH 9MCW6bDvMiTNC2sKc4PyoE8q10LyH8viBOtZ5Wo= X-Google-Smtp-Source: APXvYqxBbtgXeYaMpgHUkaORM3k9QXx7Zjz+7XU2xiPkLLnu/jOJa8Cfcc35SnI+hCwUItYIeTUW6MfYByMWuz/DouM= X-Received: by 2002:a67:685:: with SMTP id 127mr1183759vsg.169.1571161936259; Tue, 15 Oct 2019 10:52:16 -0700 (PDT) MIME-Version: 1.0 References: <20191014233510.GJ61805@kduck.mit.edu> In-Reply-To: From: Daniel Migault Date: Tue, 15 Oct 2019 13:52:05 -0400 Message-ID: To: "mglt.ietf@gmail.com" , secdir@ietf.org, Benjamin Kaduk , "Roman D. Danyliw" , IPsecME WG , The IESG Content-Type: multipart/alternative; boundary="00000000000018706d0594f6a5f3" Archived-At: Subject: Re: [IPsec] FW: [secdir] Secdir review of draft-ietf-ipsecme-implicit-iv-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 17:52:26 -0000 --00000000000018706d0594f6a5f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Magnus, Thank you for the review. Please find my response inline as well as the updated text: https://github.com/mglt/draft-mglt-ipsecme-implicit-iv/blob/master/draft-ie= tf-ipsecme-implicit-iv.txt We will probably publish the new version by tomorrow. Yours, Daniel On Tue, Oct 15, 2019 at 8:53 AM Daniel Migault wrote: > > > -----Original Message----- > From: secdir On Behalf Of Benjamin Kaduk > Sent: Monday, October 14, 2019 7:35 PM > To: Magnus Nystr=C3=B6m > Cc: secdir@ietf.org > Subject: Re: [secdir] Secdir review of draft-ietf-ipsecme-implicit-iv-07 > > Hi Magnus, > > Thanks for this review -- I filed a Discuss point about the inconsistency > between the text and the codepoints for whether AES-CTR is covered. > > -Ben > > On Sun, Oct 13, 2019 at 10:46:30PM -0700, Magnus Nystr=C3=B6m wrote: > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the IESG= . > > These comments were written primarily for the benefit of the security > > area directors. Document editors and WG chairs should treat these > > comments just like any other last call comments. > > > > This document defines a mechanism to save on bandwidth in ESP > > connections when certain ciphers have been negotiated by using > > implicit IVs. The savings are limited to 8 bytes for the current versio= n > of this document. > > > > > > > > - Section 2 mentions AES-CCM, AES-CTR, AES-GCM and ChaCha. For all o= f > > these ciphers, an 8-byte nonce is used. The mechanism to make the IV > > implicit is by coupling it to the sequence number. Yet, Section 4 > gives two > > examples of sequence numbers, one of 4 bytes and one of 8 bytes. > This is > > confusing, presumably only the extended sequence number is usable? > I think that is correct. AES-GCM, AES-CCM and Chach20-poly1305 defined for IPsec are taking a nonce as an input value and this nonce takes the ESP.IV field as input to be computed. In our case ESP.IV is 8 byte long. The document defines how ESP.IV value can be generated form the sequence number. As the sequence number can be extended or not we define two ways to generate the ESP.IV value. In both cases, the result is always a 8 byte value. We will update section 2 to make a clear distinction between IV and nonce. Some more explanations: IPsec/ESP: ESP RF4303 defines the IV field whose length is negotiated with the algorithm. AES-CCM: SP800-38c defines AES-CCM and RFC4309 defines the use of AES-CCM in IPsec. In both specifications, the 'none' is described as an input parameter. RFC4309 defines this nonce as a function of a salt and the ESP.IV field. RFC4309 defines ESP.IV field as 8 byte long. The current document defines how to generates the IV from the sequence numbers. The document defines two ways to generate the IV depending if extended sequence number is used or not and teh resulting IV is always 8 byte long. AES-GCM: SP800-38D defines AES-GCM and RFC4106 defines the use of AES-GCM in IPSec. In both specification GCM needs an input designated as IV. To distinguish that IV (GMC.IV) and the field defined by ESP, the IV used by GCM is designated in RFC4106 as nonce. That is GCM.IV =3D 'nonce' and ESP.IV =3D I= V. This brings us in the previous case of CCM where the nonce is an input parameter for GCM. Similarly to CCM the nonce is a function of a salt and ESP.IV which is 8 byte long. Chacha20-Poly1305: RFC7539 defines chacha20poly1305 and RFC7634 defines the use of Chacha20poly in IPsec/ESP. In both specifications the nonce is described as an input parameter. The nonce is described as a function of the ESP.IV and a salt with ESP.IV of 8 byte long. This brings us in the previous case of CCM where the nonce is an input parameter for GCM. Similarly to CCM the nonce is a function of a salt and ESP.IV which is 8 byte long. > > - Also, while the Abstract says the memo offers a mechanism to save = on > > the explicit IV also for AES-CTR, and Section 2 includes AES-CTR in > its > > description, Section 4 explicitly states that only AES-CCM, AES-GCM > and > > ChaCha are subject of the optimization in this memo. This is also > > confusing. Why including AES-CTR in the memo at all if it isn't > covered? At > > the very least it seems the Abstract should be updated. > The reason we did not assigned a code point for AES-CTR was that none was really asking for that code point. In addition and we did not want to assign a code point for an algorithm that is not recommended by RFC8221. (MAY be implemented status). AES-CTR is not AEAD and we would not like to encourage its use. On the other hand, the same mechanism applies. We will remove CTR from the document and that the same mechanism can be applied is caught by the following sentence: "" This document limits its scope to the algorithms mentioned above. Other algorithms with similar properties may later be defined to use similar mechanism. """ That said, re-reading the document, we provide some explanation on CBC, so the current version explains why we are excluding CTR. This could be also removed. > - It would be very helpful and useful to include an example of a > > handshake with an IIV and the resulting IV in an Appendix; this coul= d > > assist implementors to get things right. > > > I am unclear what would be represented in the exchange. The IKEv2 exchange does not really differ from a the regular negotiation of a specific encryption algorithm. The impact is mostly affecting how the encryption, decryption is performed. I believe that the clarification with IV/Nonce will address this concern. However, if there is anything specific you would like to see in the appendix, please feel free to let us know. > > > > (Editorial: English grammar needs some updates/reviews) > > > > Thanks, > > -- Magnus > > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > --00000000000018706d0594f6a5f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Magnus,=C2=A0

Thank you f= or the review.=C2=A0

Please find my res= ponse inline as well as the updated=C2=A0text:

Yours,=C2=A0
Daniel
=

= On Tue, Oct 15, 2019 at 8:53 AM Daniel Migault <daniel.migault@ericsson.com>= ; wrote:


-----Original Message-----
From: secdir <secdir-bounces@ietf.org> On Behalf Of Benjamin Kaduk
Sent: Monday, October 14, 2019 7:35 PM
To: Magnus Nystr=C3=B6m <magnusn@gmail.com>
Cc: secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-ipsecme-implicit-iv-07
Hi Magnus,

Thanks for this review -- I filed a Discuss point about the inconsistency b= etween the text and the codepoints for whether AES-CTR is covered.

-Ben

On Sun, Oct 13, 2019 at 10:46:30PM -0700, Magnus Nystr=C3=B6m wrote:
>=C2=A0 I have reviewed this document as part of the security directorat= e's
> ongoing effort to review all IETF documents being processed by the IES= G.
> These comments were written primarily for the benefit of the security =
> area directors.=C2=A0 Document editors and WG chairs should treat thes= e
> comments just like any other last call comments.
>
> This document defines a mechanism to save on bandwidth in ESP
> connections when certain ciphers have been negotiated by using
> implicit IVs. The savings are limited to 8 bytes for the current versi= on of this document.
>
>
>
>=C2=A0 =C2=A0 - Section 2 mentions AES-CCM, AES-CTR, AES-GCM and ChaCha= . For all of
>=C2=A0 =C2=A0 these ciphers, an 8-byte nonce is used. The mechanism to = make the IV
>=C2=A0 =C2=A0 implicit is by coupling it to the sequence number. Yet, S= ection 4 gives two
>=C2=A0 =C2=A0 examples of sequence numbers, one=C2=A0 of 4 bytes and on= e of 8 bytes. This is
>=C2=A0 =C2=A0 confusing, presumably only the extended sequence number i= s usable?



IPsec/= ESP:
ESP RF4303 defines the IV field whose length is negotiated with th= e algorithm.=C2=A0

AES-CCM:
SP800-38c defines AES-CCM and RFC4309= defines the use of AES-CCM in IPsec. In both specifications, the 'none= ' is described as an input parameter. RFC4309 defines this nonce as a f= unction of a salt and the ESP.IV field. RFC4309 defines ESP.IV field as 8 b= yte long. =C2=A0
The current document defines how to generates the IV fr= om the sequence numbers. The document defines two ways to generate the IV d= epending if extended sequence number is used or not and teh resulting IV is= always 8 byte long.

AES-GCM:
SP800-38D defines AES-GCM and RFC4= 106 defines the use of AES-GCM in IPSec. In both specification GCM needs an= input designated as IV. To distinguish that IV (GMC.IV) and the field defi= ned by ESP, the IV used by GCM is designated in RFC4106 as nonce. That is G= CM.IV =3D 'nonce' and ESP.IV =3D IV. This brings us =C2=A0in the pr= evious case of CCM where the nonce is an input parameter for GCM. Similarly= to CCM the nonce is a function of a salt and ESP.IV which is 8 byte long. =

Chacha20-Poly1305:
RFC7539 defines chacha20poly1305 and RFC7634 = defines the use of Chacha20poly in IPsec/ESP. In both specifications the no= nce is described as an input parameter. The nonce is described as a functio= n of the ESP.IV and a salt with ESP.IV of 8 byte long. This brings us =C2= =A0in the previous case of CCM where the nonce is an input parameter for GC= M. Similarly to CCM the nonce is a function of a salt and ESP.IV which is 8= byte long.=C2=A0

>=C2=A0 =C2=A0 - Also, while the Abstract says the memo offers a mechani= sm to save on
>=C2=A0 =C2=A0 the explicit IV also for AES-CTR, and Section 2 includes = AES-CTR in its
>=C2=A0 =C2=A0 description, Section 4 explicitly states that only AES-CC= M, AES-GCM and
>=C2=A0 =C2=A0 ChaCha are subject of the optimization in this memo. This= is also
>=C2=A0 =C2=A0 confusing. Why including AES-CTR in the memo at all if it= isn't covered? At
>=C2=A0 =C2=A0 the very least it seems the Abstract should be updated.


Other algorithms with sim= ilar properties may later be defined to use
similar mechanism.
"""
<= br>
That said, re-reading the document, we = provide some explanation on CBC, so the current version explains why we are= excluding CTR. This could be also removed.=C2=A0

>=C2=A0 =C2=A0 - It would be very helpful and useful to include an examp= le of a
>=C2=A0 =C2=A0 handshake with an IIV and the resulting IV in an Appendix= ; this could
>=C2=A0 =C2=A0 assist implementors to get things right.
>
I am unclear what would be represented in the ex= change. The IKEv2 exchange does not really differ from a the regular negoti= ation of a specific encryption algorithm. The impact is mostly affecting ho= w the encryption, decryption is performed. I believe that the clarification= with IV/Nonce will address this concern. However, if there is anything spe= cific you would like to see in the appendix, please feel free to let us kno= w.=C2=A0
=C2=A0=C2=A0=C2=A0
>
> (Editorial: English grammar needs some updates/reviews)
>
> Thanks,
> -- Magnus

> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/= wiki/SecDirReview

_______________________________________________
secdir mailing list
secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/= SecDirReview
--00000000000018706d0594f6a5f3-- From nobody Tue Oct 15 10:54:00 2019 Return-Path: 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 DBAE1120869; Tue, 15 Oct 2019 10:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 sVtGykLVwvJK; Tue, 15 Oct 2019 10:52:31 -0700 (PDT) Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (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 6433E12088F; Tue, 15 Oct 2019 10:52:31 -0700 (PDT) Received: by mail-vs1-f46.google.com with SMTP id p13so13775828vso.0; Tue, 15 Oct 2019 10:52:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mMktOrIiVqugv+otNEmmeaFNHBbqYf058yRO5JBr7tM=; b=dZgKlVIqHmLC/Yfgi8FxWmHIjLTq1iCOu0i6pvvsx/4PhvoCYSZE/yNHpqLnSEwN26 vkSxBVV8A3xxsq0pU3jBZl893odtjfHGxXIxLHasBxg+weocOE3HAQ9wyWWyoohXnwAa 8T3svN2ZpzmsyAM2Y9k8Kw/ScUJ1BVYeeszBq7WNUVtu8RVZyWZtl2rSVPJ960dFrVv5 4hHAYjBswXKMyYXy4W9pBWF9uuMN8l1q4MWCp2ieTPI/yUHbutXJmHYkkbZuEe5LPQwL LaOeBK1oeVeAjeCdzJQsIOFU7cMB6h5tDCcNV8SHbD1zJW9WvV8WEpwqbvXI/hE7dw5j 0RkQ== X-Gm-Message-State: APjAAAUdXA3TpSfxIOvSGaqYpiv0WsX9qVNh6HlnU48C7xlUZ8cYO09s Awim4vyN3U1cAYarpQ/pkpVcRGm6z16RMbzHNgg= X-Google-Smtp-Source: APXvYqxrmyGO3jZ5dcWxpS+tALx9c+FyIhFm16AkmgOw1oQNspRzo/BsiZFizA6mxR4h5F43jWFcA2j2Fe8Y3/cLRoU= X-Received: by 2002:a67:c307:: with SMTP id r7mr19077400vsj.97.1571161950433; Tue, 15 Oct 2019 10:52:30 -0700 (PDT) MIME-Version: 1.0 References: <157109490777.24664.9512388993983573410.idtracker@ietfa.amsl.com> In-Reply-To: <157109490777.24664.9512388993983573410.idtracker@ietfa.amsl.com> From: Daniel Migault Date: Tue, 15 Oct 2019 13:52:19 -0400 Message-ID: To: Benjamin Kaduk Cc: The IESG , IPsecME WG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen Content-Type: multipart/alternative; boundary="000000000000f0b7dc0594f6a505" Archived-At: Subject: Re: [IPsec] Benjamin Kaduk's Discuss on draft-ietf-ipsecme-implicit-iv-07: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 17:52:41 -0000 --000000000000f0b7dc0594f6a505 Content-Type: text/plain; charset="UTF-8" Hi Benjamin, Thank you for the review. Please find my response inline as well as the updated text: https://github.com/mglt/draft-mglt-ipsecme-implicit-iv/blob/master/draft-ietf-ipsecme-implicit-iv.txt We will probably publish the new version by tomorrow. Yours, Daniel On Mon, Oct 14, 2019 at 7:15 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-ipsecme-implicit-iv-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Please address the issue raised by the secdir reviewer where AES-CTR is > covered in the text but no codepoint allocated. > > > The current version does not cover AES-CTR. However, we provide some explanation on CBC, so the current version explains why we are excluding CTR. This could be also removed, if you prefer, I do not have strong preferences. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 2 > > nit: s/In some context/In some contexts/ > Done > > This document limits its scope to the algorithms mentioned above. > Other algorithms with similar properties may later be defined to use > this extension. > > I'd suggest rewording this part; the "extension" here is just the > per-algorithm codepoint for the IIV variant of the encryption transform, > so what would be reused is probably better described as a "mechanism" or > similar than an "extension". > The following text has been replaced: This document limits its scope to the algorithms mentioned above. Other algorithms with similar properties may later be defined to use similar mechanism. > > Section 4. > > With the algorithms listed in Section 2, the 8 byte nonce MUST NOT > repeat. The binding between a ESP packet and its nonce is provided > > I suggest s/MUST NOT repeat/MUST NOT repeat for a given key/. > nit: s/a ESP/an ESP/ > This has been changed accordingly. > > Section 4 > > This document solely defines the IV generation of the algorithms > defined in [RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [RFC7634] > for ChaCha20-Poly1305. Any other aspect (including using the Key > Length attribute) of applying those ciphers with the new Transform > Types defined in this document MUST be taken from the documents > defining the use of the algorithms in ESP. > > I suggest s/defines/modifies/; the whole paragraph is slightly confusing > to read and could perhaps be reworded to something like "This document > solely modifies the IV generation for the algorithms defined in > [RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [RFC7634] for > ChaCha20-Poly1305. All other aspects and parameters of those algorithms > are unchanged, and are used as defined in their respective > specifications." > > The proposed wording has been considered. > Section 7 > > nit: the title should be "Security Considerations" plural. > > I suggest to reiterate the RFC 4303 requirement for SAs to be closed or > rekeyed before sequence numbers grow too large to fit in 32 bits (for > "legacy" Sequence Number) or 64 bits for ESN. This prevents sequence > number overlaps for the mundane point-to-point case. > > The following text has been added: The sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet for an SA that uses a non extended Sequence Number (respectively the 2^64nd packet for an SA that uses an Extended Sequence Number). This prevents sequence number overlaps for the mundane point-to-point case. > This document defines three new encryption transforms that use > implicit IV. Unlike most encryption transforms defined to date, > which can be used for both ESP and IKEv2, these transforms are > defined for ESP only and cannot be used in IKEv2. The reason is that > IKEv2 messages don't contain unique per-message value, that can be > used for IV generation. The Message-ID field in IKEv2 header is > > nit: s/unique/a unique/ > nit: s/value,/value/ > > Changed accordingly. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --000000000000f0b7dc0594f6a505 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Benjamin,=C2=A0

Tha= nk you for the review. Please find my response inline as well as the update= d=C2=A0text:
Yours,=C2=A0
Daniel

On Mon, Oct 14, 2019 at= 7:15 PM Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
Benjamin Kaduk has entered the follo= wing ballot position for
draft-ietf-ipsecme-implicit-iv-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-ipsecme-implicit-iv/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Please address the issue raised by the secdir reviewer where AES-CTR is
covered in the text but no codepoint allocated.



The current vers= ion does not cover AES-CTR. However, we provide some explanation on CBC, so= the current version explains why we are excluding CTR. This could be also = removed, if you prefer, I do not have strong preferences.=C2=A0
= =C2=A0
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2

nit: s/In some context/In some contexts/

Done=C2=A0

=C2=A0 =C2=A0This document limits its scope to the algorithms mentioned abo= ve.
=C2=A0 =C2=A0Other algorithms with similar properties may later be defined = to use
=C2=A0 =C2=A0this extension.

I'd suggest rewording this part; the "extension" here is just= the
per-algorithm codepoint for the IIV variant of the encryption transform, so what would be reused is probably better described as a "mechanism&q= uot; or
similar than an "extension".

= The following text has been replaced:
This document limits its sc= ope to the algorithms mentioned above.
Other algorithms with similar pro= perties may later be defined to use
similar mechanism.
=C2= =A0

Section 4.

=C2=A0 =C2=A0With the algorithms listed in Section 2, the 8 byte nonce MUST= NOT
=C2=A0 =C2=A0repeat.=C2=A0 The binding between a ESP packet and its nonce i= s provided

I suggest s/MUST NOT repeat/MUST NOT repeat for a given key/.
nit: s/a ESP/an ESP/
=C2=A0
This has been ch= anged accordingly.=C2=A0=C2=A0

Section 4

=C2=A0 =C2=A0This document solely defines the IV generation of the algorith= ms
=C2=A0 =C2=A0defined in [RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [R= FC7634]
=C2=A0 =C2=A0for ChaCha20-Poly1305.=C2=A0 Any other aspect (including using= the Key
=C2=A0 =C2=A0Length attribute) of applying those ciphers with the new Trans= form
=C2=A0 =C2=A0Types defined in this document MUST be taken from the document= s
=C2=A0 =C2=A0defining the use of the algorithms in ESP.

I suggest s/defines/modifies/; the whole paragraph is slightly confusing to read and could perhaps be reworded to something like "This document=
solely modifies the IV generation for the algorithms defined in
[RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [RFC7634] for
ChaCha20-Poly1305.=C2=A0 All other aspects and parameters of those algorith= ms
are unchanged, and are used as defined in their respective
specifications."

The proposed wording has been considered.=C2=A0
=
=C2=A0
Section 7

nit: the title should be "Security Considerations" plural.

I suggest to reiterate the RFC 4303 requirement for SAs to be closed or
rekeyed before sequence numbers grow too large to fit in 32 bits (for
"legacy" Sequence Number) or 64 bits for ESN.=C2=A0 This prevents= sequence
number overlaps for the mundane point-to-point case.

The following text has been added:

The sender's counter and the receiver's counter MUST be rese= t (by
establishing a new SA and thus a new key) prior to the transmissio= n of
the 2^32nd packet for an SA that uses a non extended Sequence Numbe= r
(respectively the 2^64nd packet for an SA that uses an Extended Sequen= ce
Number). This prevents sequence number overlaps for the mundane
po= int-to-point case.=C2=A0

=C2=A0
=C2=A0 =C2=A0This document defines three new encryption transforms that use=
=C2=A0 =C2=A0implicit IV.=C2=A0 Unlike most encryption transforms defined t= o date,
=C2=A0 =C2=A0which can be used for both ESP and IKEv2, these transforms are=
=C2=A0 =C2=A0defined for ESP only and cannot be used in IKEv2.=C2=A0 The re= ason is that
=C2=A0 =C2=A0IKEv2 messages don't contain unique per-message value, tha= t can be
=C2=A0 =C2=A0used for IV generation.=C2=A0 The Message-ID field in IKEv2 he= ader is

nit: s/unique/a unique/
nit: s/value,/value/

Changed accordingly.=C2=A0=C2=A0

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--000000000000f0b7dc0594f6a505-- From nobody Tue Oct 15 10:54:16 2019 Return-Path: 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 79C5112080D; Tue, 15 Oct 2019 10:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 o59V3Eg9cw7L; Tue, 15 Oct 2019 10:52:48 -0700 (PDT) Received: from mail-ua1-f46.google.com (mail-ua1-f46.google.com [209.85.222.46]) (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 B0C51120865; Tue, 15 Oct 2019 10:52:48 -0700 (PDT) Received: by mail-ua1-f46.google.com with SMTP id q11so6389456uao.1; Tue, 15 Oct 2019 10:52:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=efu2Yb67TsEEhvqikAs/0dHJmKc5XWCCAaa3PNJzNRU=; b=lHCiSLKKOUKXjy/e+JHuDiUF2FGdgKux43jA719Z7E75iag06yLbVISi4aWfliD7Ir GdqVzjF6sU6sra2bcjU7HMUvwBr9MjcuwBemHzzbdHcsHNsVx8pN2wqFF3rJhf1wrhWg 2g++J+bqLDOE6QnUpNBwLtKRZbpcDDXVp9Q1VqWq+qeLOkkZDE4DOAGzEBLQD1lwOGig RRm0/tiF27YRgBb6wFaoEEa4FkSWKTz/hUBeDTbpLy+CLixPGsiYydtT5pEU5LVng9AR rPMKLv2fA4bCVAOwi/jXlBuVnZrhgDImADLjtpU1vxbLglazXsNHyfmcRrpo3aJJ+oiO 9jFw== X-Gm-Message-State: APjAAAUEOx+Z1UiKeNTNxBnallbXWxvmmhNyqbpfnlBORdEgXAhG5Zwe X85H9Ss9i+2W4/lTLZvOil4pvkOjzrYSdPUfQCM= X-Google-Smtp-Source: APXvYqxZvGupCfFyCjzkGJApMjZO0puwwAB+63ax+ly6xrn4JA+h8GXFvdr/O4z08WlhenbBL0PDXm8+8t6n+cDrnFM= X-Received: by 2002:ab0:3347:: with SMTP id h7mr16895499uap.88.1571161967605; Tue, 15 Oct 2019 10:52:47 -0700 (PDT) MIME-Version: 1.0 References: <157114150226.18104.2305500883432225536.idtracker@ietfa.amsl.com> In-Reply-To: <157114150226.18104.2305500883432225536.idtracker@ietfa.amsl.com> From: Daniel Migault Date: Tue, 15 Oct 2019 13:52:36 -0400 Message-ID: To: Roman Danyliw Cc: The IESG , IPsecME WG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen Content-Type: multipart/alternative; boundary="000000000000f6be900594f6a6cc" Archived-At: Subject: Re: [IPsec] Roman Danyliw's No Objection on draft-ietf-ipsecme-implicit-iv-07: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 17:52:57 -0000 --000000000000f6be900594f6a6cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable HI Roman, Thanks for the feed back. Please find my response inline as well as the updated text: https://github.com/mglt/draft-mglt-ipsecme-implicit-iv/blob/master/draft-ie= tf-ipsecme-implicit-iv.txt We will probably publish the new version by tomorrow. Yours, Daniel On Tue, Oct 15, 2019 at 8:11 AM Roman Danyliw via Datatracker < noreply@ietf.org> wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-ipsecme-implicit-iv-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ** I support the DISCUSS position held by Ben Kaduk. (Derived from Magnu= s > Nystrom=E2=80=99s SECDIR review) The abstract, Section 2, Section 4 and S= ection 7 > make > references to AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 (four > algorithms). However, Section 4 also states =E2=80=9CThis document solel= y defines > the > IV generation of the algorithms defined in [RFC4106] for AES-GCM, > [RFC4309] for > AES-CCM and [RFC7634] for ChaCha20-Poly1305=E2=80=9D (i.e., AES-CTR is mi= ssing). > Likewise, no new code point is assigned for AES-CTR in Section 8. If > AES-CTR > is not in scope, then please don=E2=80=99t mention it in the draft. If i= t was > missed > from Section 4 and 8, please add it. > The same construction applies to CTR but none pushed for having it. As we are moving to AEAD encryption we did not feel the need to assign a code point that was not used for sure. We remove CTR and the text above includes CTR is there is a need to assign some code points in the future: """ Other algorithms with similar properties may later be defined to use similar mechanism. """ That said, re-reading the document, we provide some explanation on CBC, so the current version explains why we are excluding CTR. This could be also removed, if you prefer, I do not have strong preferences. > ** Section 7. I=E2=80=99m having difficulty reconciling these two sentenc= es: > > (1) Nonce generation for these algorithms has not been explicitly > defined.=E2=80=9D > > (2) This document provides an explicit and normative way to generate IVs. > > Isn=E2=80=99t this text saying the Nonce =3D Sequence number =3D IV? > Though I admit we could have been clearer and we will clarify the text. I have also provided more details in the response to Magnus - which was not sent at the time I am writing this response. The algorithms take a nonce as input. This nonce when used with IPsec is generated based on the IV value found in each ESP packet. Our document details how the IV value can be derived when the ESP packet does not provide the IV. In this case, the value associated to the IV is derived from the sequence number read in the ESP packet. Note also that GCM as defined by SP800-38D defines what we call nonce as IV, but RFC 4106 clarifies that GCM.IV =3D nonce. ** Section 7. Editorial. s/the IV is not allowed being repeated for one > particular key./the IV is not allowed to be repeated for a particular key= ./ > > Fixed > ** Section 7. Editorial. s/The Message-ID field in IKEv2 header is > somewhat > counterpart of SN field in ESP header, but recent =E2=80=A6/The Message-I= D field in > IKEv2 header is similar to the SN field in ESP header. However recent = =E2=80=A6/ > > Fixed as well. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --000000000000f6be900594f6a6cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
HI Roman,=C2=A0

Thanks for t= he feed back.=C2=A0

Please find my respo= nse inline as well as the updated=C2=A0text:

Yours,=C2=A0
Daniel
On T= ue, Oct 15, 2019 at 8:11 AM Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
Roman Danyliw has = entered the following ballot position for
draft-ietf-ipsecme-implicit-iv-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-ipsecme-implicit-iv/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** I support the DISCUSS position held by Ben Kaduk.=C2=A0 (Derived from Ma= gnus
Nystrom=E2=80=99s SECDIR review) The abstract, Section 2, Section 4 and Sec= tion 7 make
references to AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 (four
algorithms).=C2=A0 However, Section 4 also states =E2=80=9CThis document so= lely defines the
IV generation of the algorithms defined in [RFC4106] for AES-GCM, [RFC4309]= for
AES-CCM and [RFC7634] for ChaCha20-Poly1305=E2=80=9D (i.e., AES-CTR is miss= ing).
Likewise, no new code point is assigned for AES-CTR in Section 8.=C2=A0 If = AES-CTR
is not in scope, then please don=E2=80=99t mention it in the draft.=C2=A0 I= f it was missed
from Section 4 and 8, please add it.

Th= e same construction applies to CTR but none pushed for having it. As we are= moving to AEAD encryption we did not feel the need to assign a code point = that was not used for sure.=C2=A0 =C2=A0

We remove= CTR and the text above includes CTR is there is a need to assign some code= points in the future:
"""
Other algorit= hms with similar properties may later be defined to use
similar mechan= ism.
"""

That said, re-reading the document, we provide some explanation on CBC, s= o the current version explains why we are excluding CTR. This could be also= removed, if you prefer, I do not have strong preferences.=C2=A0
=C2=A0
** Section 7. I=E2=80=99m having difficulty reconciling these two sentences= :

(1)=C2=A0 Nonce generation for these algorithms has not been explicitly def= ined.=E2=80=9D

(2) This document provides an explicit and normative way to generate IVs.
Isn=E2=80=99t this text saying the Nonce =3D Sequence number =3D IV?

Though I admit we could have been clearer and= we will clarify the text. I have also provided more details in the respons= e to Magnus - which was not sent at the time I am writing this response. Th= e algorithms take a nonce as input. This nonce when used with IPsec is gene= rated based on the IV value found in each ESP packet. Our document details = how the IV value can be derived when the ESP packet does not provide the IV= . In this case, the value associated to the IV is derived from the sequence= number read in the ESP packet.=C2=A0

Note also th= at GCM as defined by SP800-38D defines what we call nonce as IV, but RFC 41= 06 clarifies that GCM.IV =3D nonce.=C2=A0 =C2=A0=C2=A0

=
** Section 7.=C2=A0 Editorial. s/the IV is not allowed being repeated for o= ne
particular key./the IV is not allowed to be repeated for a particular key./=

Fixed
=C2=A0
** Section 7.=C2=A0 Editorial.=C2=A0 s/The Message-ID field in IKEv2 header= is somewhat
counterpart of SN field in ESP header, but recent =E2=80=A6/The Message-ID = field in
IKEv2 header is similar to the SN field in ESP header.=C2=A0 However recent= =E2=80=A6/

=C2=A0Fixed as well.=C2=A0

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--000000000000f6be900594f6a6cc-- From nobody Tue Oct 15 19:51:41 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 780FD120856; Tue, 15 Oct 2019 19:51:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen , ipsecme-chairs@ietf.org, kivinen@iki.fi, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <157119428147.28057.3364707659942003352.idtracker@ietfa.amsl.com> Date: Tue, 15 Oct 2019 19:51:21 -0700 Archived-At: Subject: [IPsec] Adam Roach's Yes on draft-ietf-ipsecme-implicit-iv-07: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 02:51:33 -0000 Adam Roach has entered the following ballot position for draft-ietf-ipsecme-implicit-iv-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work on this mechanism. I have no substantive comments beyond those that have already been shared, although I do have some minor editorial comments. --------------------------------------------------------------------------- §2: > In some context, such as IoT, it may be preferable to avoid carrying Nit: "...some contexts..." --------------------------------------------------------------------------- §5: > An initiator supporting this feature SHOULD propose implicit IV > algorithms in the Transform Type 1 (Encryption Algorithm) > Substructure of the Proposal Substructure inside the SA Payload. Please expand "SA" on first use. --------------------------------------------------------------------------- > 7. Security Consideration Nit: "Considerations" --------------------------------------------------------------------------- §7: > extensions ([RFC6311], [RFC7383]) do allow it to repeat, so there is > no an easy way to derive unique IV from IKEv2 header fields. Nit: "...not an easy way..." From nobody Tue Oct 15 20:07:58 2019 Return-Path: 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 F37C0120846; Tue, 15 Oct 2019 20:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.475 X-Spam-Level: X-Spam-Status: No, score=-1.475 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 RmfxTkZWVOuS; Tue, 15 Oct 2019 20:07:47 -0700 (PDT) Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) (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 0EB5E12006B; Tue, 15 Oct 2019 20:07:47 -0700 (PDT) Received: by mail-vk1-f175.google.com with SMTP id f1so4833579vkh.9; Tue, 15 Oct 2019 20:07:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+YDC2NKb537MLbPlZerhJvkEOgeUQUMsLfJbyMwoKvI=; b=W/JOObx/l9CGNOnbc3CqX/Uw26pfwOY/mYCenHpZCm5ewDc57rujz7Vct7JeE6iRFa wTd3JCK/1rwCbfVrdOZJMg1+iw4ssbXxUHAEVddS7ciqwT6Pmbz18XbckU1JSY4TIjXU At4PafBJUsPTmxDO2tXViDABud0Ev66anR5HEjNQpW2ON36kPQSg+KVHzrgzZtLr5y4y OqsEbzHvhZqJp5CxjDuO3383RMXcXG/2pDUiemOg9uPU5BoSHkHvJ8DX7v/dyzQBcw4F OiK+pgKQXSrRk+g4Zk4zVvLZnYfmg+dua6ipdtsDZhkd9cauNveFACBdPeIAeAwbjPq0 HliA== X-Gm-Message-State: APjAAAWJ5zwyBPKiIJ1JlibRyrHhgIBlJRh7NFDOor95/Zf+3ClqkywT dkr/Pg+WsiR1HZmPxJX7KFIlbdj3m20m4l3cYPE= X-Google-Smtp-Source: APXvYqx63zcIGZhBb8buXECVnq9A7HiUfajjWf05kwuBCQsIuclAy5FKqejhrIbT3xlF8q7BMMADUpnlq7CjQBxo5Fc= X-Received: by 2002:a1f:2706:: with SMTP id n6mr10991vkn.89.1571195265897; Tue, 15 Oct 2019 20:07:45 -0700 (PDT) MIME-Version: 1.0 References: <157119428147.28057.3364707659942003352.idtracker@ietfa.amsl.com> In-Reply-To: <157119428147.28057.3364707659942003352.idtracker@ietfa.amsl.com> From: Daniel Migault Date: Tue, 15 Oct 2019 23:07:34 -0400 Message-ID: To: Adam Roach Cc: The IESG , IPsecME WG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen Content-Type: multipart/alternative; boundary="000000000000b258e40594fe67f6" Archived-At: Subject: Re: [IPsec] Adam Roach's Yes on draft-ietf-ipsecme-implicit-iv-07: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 03:07:50 -0000 --000000000000b258e40594fe67f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adam, Thanks for the feed back. All your comments have been fixed on the current local version available at: https://github.com/mglt/draft-mglt-ipsecme-implicit-iv/blob/master/draft-ie= tf-ipsecme-implicit-iv.txt We expect to publish the version tomorrow. Yours, Daniel On Tue, Oct 15, 2019 at 10:51 PM Adam Roach via Datatracker < noreply@ietf.org> wrote: > Adam Roach has entered the following ballot position for > draft-ietf-ipsecme-implicit-iv-07: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the work on this mechanism. I have no substantive comments > beyond those that have already been shared, although I do have some > minor editorial comments. > > -------------------------------------------------------------------------= -- > > =C2=A72: > > > In some context, such as IoT, it may be preferable to avoid carrying > > Nit: "...some contexts..." > > Fixed > -------------------------------------------------------------------------= -- > > =C2=A75: > > > An initiator supporting this feature SHOULD propose implicit IV > > algorithms in the Transform Type 1 (Encryption Algorithm) > > Substructure of the Proposal Substructure inside the SA Payload. > > Please expand "SA" on first use. > > Fixed > -------------------------------------------------------------------------= -- > > > 7. Security Consideration > > Nit: "Considerations" > Fixed > > -------------------------------------------------------------------------= -- > > =C2=A77: > > > extensions ([RFC6311], [RFC7383]) do allow it to repeat, so there is > > no an easy way to derive unique IV from IKEv2 header fields. > > Nit: "...not an easy way..." > Fixed > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --000000000000b258e40594fe67f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adam,=C2=A0

Thanks = for the feed back. All your comments have been fixed on the current local v= ersion available at:

We expect to publish= the version tomorrow.

Yours,=C2=A0
Daniel



On Tue, Oct 15, 2019 at 10:51 PM Adam Roach = via Datatracker <noreply@ietf.org> wrote:
Ada= m Roach has entered the following ballot position for
draft-ietf-ipsecme-implicit-iv-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-ipsecme-implicit-iv/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the work on this mechanism. I have no substantive comments
beyond those that have already been shared, although I do have some
minor editorial comments.

---------------------------------------------------------------------------=

=C2=A72:

>=C2=A0 In some context, such as IoT, it may be preferable to avoid carr= ying

Nit: "...some contexts..."

Fixed=C2=A0
---------------------------------------------------------------------------=

=C2=A75:

>=C2=A0 An initiator supporting this feature SHOULD propose implicit IV<= br> >=C2=A0 algorithms in the Transform Type 1 (Encryption Algorithm)
>=C2=A0 Substructure of the Proposal Substructure inside the SA Payload.=

Please expand "SA" on first use.

Fixed=C2=A0
---------------------------------------------------------------------------=

> 7.=C2=A0 Security Consideration

Nit: "Considerations"
Fixed=C2=A0

---------------------------------------------------------------------------=

=C2=A77:

>=C2=A0 extensions ([RFC6311], [RFC7383]) do allow it to repeat, so ther= e is
>=C2=A0 no an easy way to derive unique IV from IKEv2 header fields.

Nit: "...not an easy way..."
Fixed=C2=A0


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--000000000000b258e40594fe67f6-- From nobody Wed Oct 16 19:39:10 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FD412004A; Wed, 16 Oct 2019 19:39:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <157127994910.9958.5205731502613704306@ietfa.amsl.com> Date: Wed, 16 Oct 2019 19:39:09 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-implicit-iv-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 02:39:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP) Authors : Daniel Migault Tobias Guggemos Yoav Nir Filename : draft-ietf-ipsecme-implicit-iv-08.txt Pages : 8 Date : 2019-10-16 Abstract: Encapsulating Security Payload (ESP) sends an initialization vector (IV) in each packet. The size of IV depends on the applied transform, being usually 8 or 16 octets for the transforms defined by the time this document is written. Some algorithms such as AES-GCM, AES-CCM and ChaCha20-Poly1305 when used with IPsec, take the IV to generate a nonce that is used as an input parameter for encrypting and decrypting. These algorithms require a unique IV but do not require an unpredictable IV. As a result, the value provided in the ESP Sequence Number (SN) can be used instead to generate the nonce. This avoids sending the IV itself, and saves in the case of AES-GCM, AES-CCM and ChaCha20-Poly1305 8 octets per packet. This document describes how to do this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-08 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-implicit-iv-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-implicit-iv-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 16 20:30:07 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 344B2120024; Wed, 16 Oct 2019 20:30:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen , ipsecme-chairs@ietf.org, kivinen@iki.fi, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <157128300620.9968.15171563029563358723.idtracker@ietfa.amsl.com> Date: Wed, 16 Oct 2019 20:30:06 -0700 Archived-At: Subject: [IPsec] Benjamin Kaduk's No Objection on draft-ietf-ipsecme-implicit-iv-08: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 03:30:06 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-ipsecme-implicit-iv-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my Discuss! A few new comments on the -08: Abstract If we're going to differentiate between nonce and IV, I think that the algorithms require a unique but not necessarily unpredictable *nonce*, rather than *IV*. Section 2 nit: s/Initialize/Initialization/ nit: s/similar mechanism/similar mechanisms/ plural Section 7 My previous ballot was trying to note that the sender/receiver counters MUST be reset (as noted here) even without this document, as part of the core ESP requirements. So we don't need to use the "MUST" here as if it's a new requirement; we can just say that this behavior is already present due to the preexisting requirements From nobody Wed Oct 16 22:24:39 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90709120236; Wed, 16 Oct 2019 22:24:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen , ipsecme-chairs@ietf.org, kivinen@iki.fi, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <157128987258.9958.14206418883735067925.idtracker@ietfa.amsl.com> Date: Wed, 16 Oct 2019 22:24:32 -0700 Archived-At: Subject: [IPsec] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-ipsecme-implicit-iv-08=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 05:24:33 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-implicit-iv-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing the DISCUSS and my COMMENTS. I leave my previous comments here for log purpose == COMMENTS == -- Section 5 -- C.1) "inside the SA Payload" probably worth being a little more descriptive here (for instance, "SA payload in the IKE exchange" ?). Also suggest to use "IKE Initiator Behavior" for the section title. -- Section 8 -- C.2) please use the usual text for IANA considerations (notably asking IANA to register as this is not this document that registers the codes). == NITS == In several places, s/8 byte nonce/8-byte nonce/ From nobody Thu Oct 17 07:06:00 2019 Return-Path: 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 637CC12000F; Thu, 17 Oct 2019 07:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 YdKUbGxpqP2N; Thu, 17 Oct 2019 07:05:49 -0700 (PDT) Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) (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 7E39912085D; Thu, 17 Oct 2019 07:05:49 -0700 (PDT) Received: by mail-vs1-f51.google.com with SMTP id s7so1687577vsl.2; Thu, 17 Oct 2019 07:05:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g11VaHSLtwameCqeh/OkrPNBrWXROSLu5JJQ1/Efp1M=; b=Vupo/LpBE6ptRxmpLDo0dENdUG8QXL4r+70h5kn9qeDJ4bWUd95m2ORjJhNOvGHUFB 0C56FKPUM3TxfxK1yRqH2AF7GFdZVGjVibSGjal9Zd7dDwzmll3CPOsvv3iwRVezQsrP 3s1xY9XdGgcD+nygK1WUKKwZEcK/WkJSVWFJ3amnWh0yN3wc45jI4orLkTrbn7eXH5/v yJlI41rsA3NKnkMaKWGlPz+BqRHAqdRReDiw4Ov1tkm3MpRqcSMYQ105um/J1uNS24K+ pQ/OfwIn9z56HwfCnzIZMV3k3/WiqV16OWVqobrtA5VNuJMxtnfreUTdnZKXSw3+mLjV Mfpg== X-Gm-Message-State: APjAAAVB/9WFG0DYgFmRPYq+YWttI07u52XRVFDVAwMUVVz3qbPnSqRO qoyT6gGVm/wF25CiuU/bftOpBP3w3ZkD7LZrMzs= X-Google-Smtp-Source: APXvYqxe0Mw0u6762rbw9RO2gsWKGw6isuMx/qdh2dFOMLIYfTYNQc30lk370W9RntHYzCt41vC7Ijw/MvhABhNbuoI= X-Received: by 2002:a05:6102:21ce:: with SMTP id r14mr2110030vsg.69.1571321148293; Thu, 17 Oct 2019 07:05:48 -0700 (PDT) MIME-Version: 1.0 References: <157119428147.28057.3364707659942003352.idtracker@ietfa.amsl.com> In-Reply-To: From: Daniel Migault Date: Thu, 17 Oct 2019 10:05:37 -0400 Message-ID: To: Adam Roach , secdir@ietf.org Cc: The IESG , IPsecME WG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen Content-Type: multipart/alternative; boundary="000000000000df45d005951bb602" Archived-At: Subject: Re: [IPsec] Adam Roach's Yes on draft-ietf-ipsecme-implicit-iv-07: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 14:05:52 -0000 --000000000000df45d005951bb602 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Just to make everyone aware, we have issued a new version that we hope addresses all concerns. https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-08 Yours, Daniel On Tue, Oct 15, 2019 at 11:07 PM Daniel Migault wrote: > Hi Adam, > > Thanks for the feed back. All your comments have been fixed on the curren= t > local version available at: > > https://github.com/mglt/draft-mglt-ipsecme-implicit-iv/blob/master/draft-= ietf-ipsecme-implicit-iv.txt > > We expect to publish the version tomorrow. > > Yours, > Daniel > > > > On Tue, Oct 15, 2019 at 10:51 PM Adam Roach via Datatracker < > noreply@ietf.org> wrote: > >> Adam Roach has entered the following ballot position for >> draft-ietf-ipsecme-implicit-iv-07: Yes >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks for the work on this mechanism. I have no substantive comments >> beyond those that have already been shared, although I do have some >> minor editorial comments. >> >> >> ------------------------------------------------------------------------= --- >> >> =C2=A72: >> >> > In some context, such as IoT, it may be preferable to avoid carrying >> >> Nit: "...some contexts..." >> >> Fixed > >> >> ------------------------------------------------------------------------= --- >> >> =C2=A75: >> >> > An initiator supporting this feature SHOULD propose implicit IV >> > algorithms in the Transform Type 1 (Encryption Algorithm) >> > Substructure of the Proposal Substructure inside the SA Payload. >> >> Please expand "SA" on first use. >> >> Fixed > >> >> ------------------------------------------------------------------------= --- >> >> > 7. Security Consideration >> >> Nit: "Considerations" >> > Fixed > >> >> >> ------------------------------------------------------------------------= --- >> >> =C2=A77: >> >> > extensions ([RFC6311], [RFC7383]) do allow it to repeat, so there is >> > no an easy way to derive unique IV from IKEv2 header fields. >> >> Nit: "...not an easy way..." >> > Fixed > >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > --000000000000df45d005951bb602 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Just to make= everyone aware, we have issued a new version that we hope addresses all co= ncerns.=C2=A0
Yours,=C2= =A0
Daniel

On Tue, Oct 15, 2019 at 11:07 PM Daniel Mig= ault <d= aniel.migault@ericsson.com> wrote:
Hi Adam,=C2=A0<= div>
Thanks for the feed back. All your comments have been fi= xed on the current local version available at:
Yours,=C2=A0
Daniel


=

= On Tue, Oct 15, 2019 at 10:51 PM Adam Roach via Datatracker <noreply@ietf.org> wrote:<= br>
Adam Roach has e= ntered the following ballot position for
draft-ietf-ipsecme-implicit-iv-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-ipsecme-implicit-iv/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the work on this mechanism. I have no substantive comments
beyond those that have already been shared, although I do have some
minor editorial comments.

---------------------------------------------------------------------------=

=C2=A72:

>=C2=A0 In some context, such as IoT, it may be preferable to avoid carr= ying

Nit: "...some contexts..."

Fixed=C2=A0
---------------------------------------------------------------------------=

=C2=A75:

>=C2=A0 An initiator supporting this feature SHOULD propose implicit IV<= br> >=C2=A0 algorithms in the Transform Type 1 (Encryption Algorithm)
>=C2=A0 Substructure of the Proposal Substructure inside the SA Payload.=

Please expand "SA" on first use.

Fixed=C2=A0
---------------------------------------------------------------------------=

> 7.=C2=A0 Security Consideration

Nit: "Considerations"
Fixed=C2=A0

---------------------------------------------------------------------------=

=C2=A77:

>=C2=A0 extensions ([RFC6311], [RFC7383]) do allow it to repeat, so ther= e is
>=C2=A0 no an easy way to derive unique IV from IKEv2 header fields.

Nit: "...not an easy way..."
Fixed=C2=A0


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--000000000000df45d005951bb602-- From nobody Thu Oct 17 19:37:32 2019 Return-Path: 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 3E6A41200F6; Thu, 17 Oct 2019 19:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 QCMTXR1ZGAVg; Thu, 17 Oct 2019 19:37:22 -0700 (PDT) Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) (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 A46AA120044; Thu, 17 Oct 2019 19:37:22 -0700 (PDT) Received: by mail-vk1-f172.google.com with SMTP id d66so1012834vka.2; Thu, 17 Oct 2019 19:37:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CTqeEXc6eJOCMeHGjATaPt98chcHwSL/UEA6ziIRdpw=; b=XcDcbvRbrNgYBuMR0pEot2oiLBBC5aSijG2ezE9orggxSorEHF7hiTvVsAT8eM/LnI uPItu5F4b78SBgPxkqFYyz5WxvZpEU/vGeIdF7gbdWjalg/kWv4yIqLfOiTxNyKipDDG mBivus+ig4c+2WGrzQY4XF1YEs4KAmsNk5MIjIbB6vge0tUqChO08Iuog3RW10JN3u/P E/9qXCs3KjGFq8A4/19N/plaYsnEqDUT9Q6ZDTysykwViLUSMuq5I0SBf09K10cPZRir WiFTgbbyJ9GidhGAidswpMzqjK6qjsjxsQFNhmPxGLmj3+wm4Y+ziOCYOCfGUxWkq2Tw y2wg== X-Gm-Message-State: APjAAAXGokOd8wxxNAtE5zclk5bclqF65EjF9slTfqbJsn7bXzMGSyuF P7ZgrIqT6RrxQcgg1W2QpUEwjKJ724rYmsQKjDk= X-Google-Smtp-Source: APXvYqwoJbHfqrZBqRmlxIWxT+tBLs3fBleLAEUw7U6YtJzH1K0OOz5wd780JazlCLZsDe/WgOd/vavuhBDurTgQCKA= X-Received: by 2002:a1f:1d15:: with SMTP id d21mr3929416vkd.55.1571366241533; Thu, 17 Oct 2019 19:37:21 -0700 (PDT) MIME-Version: 1.0 References: <157128300620.9968.15171563029563358723.idtracker@ietfa.amsl.com> In-Reply-To: <157128300620.9968.15171563029563358723.idtracker@ietfa.amsl.com> From: Daniel Migault Date: Thu, 17 Oct 2019 22:37:10 -0400 Message-ID: To: Benjamin Kaduk Cc: The IESG , IPsecME WG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen Content-Type: multipart/alternative; boundary="000000000000a3859205952636e8" Archived-At: Subject: Re: [IPsec] Benjamin Kaduk's No Objection on draft-ietf-ipsecme-implicit-iv-08: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 02:37:24 -0000 --000000000000a3859205952636e8 Content-Type: text/plain; charset="UTF-8" Hi Benjamin, Thanks you for the comments. Please see in line my responses. Yours, Daniel On Wed, Oct 16, 2019 at 11:30 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-ipsecme-implicit-iv-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for addressing my Discuss! > > A few new comments on the -08: > > Abstract > > If we're going to differentiate between nonce and IV, I think that > the algorithms require a unique but not necessarily unpredictable *nonce*, > rather than *IV*. > > I would preferred to have IV instead of nonce is that IPsec provides constraints on the IV, not the nonce. I expected to have switched from algorithms to their implementations by writing "when used with IPsec" in the previous sentence. In order to flip-flop from algorithm to their implementations with IPsec, I propose to clarify this as follows: OLD: These algorithms require a unique IV but do not require an unpredictable IV. NEW: This IV must be unique but can be predictable. > Section 2 > > nit: s/Initialize/Initialization/ > Fixed > > nit: s/similar mechanism/similar mechanisms/ plural > Fixed > Section 7 > > My previous ballot was trying to note that the sender/receiver counters > MUST be reset (as noted here) even without this document, as part of > the core ESP requirements. So we don't need to use the "MUST" here as > if it's a new requirement; we can just say that this behavior is already > present due to the preexisting requirements > > > Well, the reason I included it was that - at least my reading of ESP - ESP seems to require key to be rekeyed when the SN reaches its limit only when anti-replay is activated. In our case, we need to have this property even without anti replay protection. Here is the text I considered rfc4303 section 2.2 """ The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a sequence number of 1; see Section 3.3.3 for more details on how the sequence number is generated.) If anti-replay is enabled (the default), the transmitted sequence number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. """ > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --000000000000a3859205952636e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Benjamin,

Thanks you for the comments. Please see in line my responses.=C2= =A0=C2=A0

Yours,=C2=A0
Daniel
On Wed, Oct 16, 2019 at 11:30= PM Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
Benjamin Kaduk has entered the following = ballot position for
draft-ietf-ipsecme-implicit-iv-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-ipsecme-implicit-iv/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my Discuss!

A few new comments on the -08:

Abstract

If we're going to differentiate between nonce and IV, I think that
the algorithms require a unique but not necessarily unpredictable *nonce*,<= br> rather than *IV*.

I would preferred to have IV instead of nonce is that= IPsec provides constraints on the IV, not the nonce. I expected to have sw= itched from algorithms to their implementations by writing "when used = with IPsec" in the previous sentence. In order to flip-flop from algor= ithm to their implementations with IPsec, I propose to clarify this as foll= ows:

OLD:
These
algorithms require a = unique IV but do not require an unpredictable IV.

<= div>NEW:
This IV must be unique but can be predictable.=C2= =A0=C2=A0
=C2=A0 =C2=A0
Section 2

nit: s/Initialize/Initialization/
Fixed=C2=A0

nit: s/similar mechanism/similar mechanisms/ plural
Fi= xed=C2=A0
=C2=A0
Section 7

My previous ballot was trying to note that the sender/receiver counters
MUST be reset (as noted here) even without this document, as part of
the core ESP requirements.=C2=A0 So we don't need to use the "MUST= " here as
if it's a new requirement; we can just say that this behavior is alread= y
present due to the preexisting requirements


Well, the reason I included it was that - at least my= reading of ESP - ESP seems to require key to be rekeyed when the SN reache= s its limit only when anti-replay is activated. In our case, we need to hav= e this property even without anti replay protection. Here is the text I con= sidered rfc4303 section 2.2=C2=A0=C2=A0

"&quo= t;"
The =
sender's counter and the receiver's counter are initialized to 0
   when an SA is established.  (The first packet sent using a given SA
   will have a sequence number of 1; see Section 3.3.3 for more details
   on how the sequence number is generated.)  If anti-replay is enabled
   (the default), the transmitted sequence number must never be allowed
   to cycle.  Thus, the sender's counter and the receiver's counter=
 MUST
   be reset (by establishing a new SA and thus a new key) prior to the
   transmission of the 2^32nd packet on an SA.
""= "
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--000000000000a3859205952636e8-- From nobody Fri Oct 18 12:43:43 2019 Return-Path: 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 A2ABB120817; Fri, 18 Oct 2019 12:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5CBTLcJS9lb9; Fri, 18 Oct 2019 12:43:38 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812E51208DE; Fri, 18 Oct 2019 12:43:38 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9IJhTIt009810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Oct 2019 15:43:32 -0400 Date: Fri, 18 Oct 2019 12:43:29 -0700 From: Benjamin Kaduk To: Daniel Migault Cc: The IESG , IPsecME WG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen Message-ID: <20191018194329.GK43312@kduck.mit.edu> References: <157128300620.9968.15171563029563358723.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] Benjamin Kaduk's No Objection on draft-ietf-ipsecme-implicit-iv-08: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 19:43:41 -0000 On Thu, Oct 17, 2019 at 10:37:10PM -0400, Daniel Migault wrote: > Hi Benjamin, > Thanks you for the comments. Please see in line my responses. > Yours, > Daniel > On Wed, Oct 16, 2019 at 11:30 PM Benjamin Kaduk via Datatracker > wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-ipsecme-implicit-iv-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for addressing my Discuss! > > A few new comments on the -08: > > Abstract > > If we're going to differentiate between nonce and IV, I think that > the algorithms require a unique but not necessarily unpredictable > *nonce*, > rather than *IV*. > > I would preferred to have IV instead of nonce is that IPsec provides > constraints on the IV, not the nonce. I expected to have switched from > algorithms to their implementations by writing "when used with IPsec" in > the previous sentence. In order to flip-flop from algorithm to their > implementations with IPsec, I propose to clarify this as follows: > OLD: > These > algorithms require a unique IV but do not require an unpredictable IV. > NEW: > This IV must be unique but can be predictable. Thanks! > > Section 2 > > nit: s/Initialize/Initialization/ > > Fixed > > nit: s/similar mechanism/similar mechanisms/ plural > > Fixed > > > Section 7 > > My previous ballot was trying to note that the sender/receiver counters > MUST be reset (as noted here) even without this document, as part of > the core ESP requirements. So we don't need to use the "MUST" here as > if it's a new requirement; we can just say that this behavior is already > present due to the preexisting requirements > > Well, the reason I included it was that - at least my reading of ESP - ESP > seems to require key to be rekeyed when the SN reaches its limit only when > anti-replay is activated. In our case, we need to have this property even > without anti replay protection. Here is the text I considered rfc4303 > section 2.2 > """ > > The sender's counter and the receiver's counter are initialized to 0 > when an SA is established. (The first packet sent using a given SA > will have a sequence number of 1; see Section 3.3.3 for more details > on how the sequence number is generated.) If anti-replay is enabled > (the default), the transmitted sequence number must never be allowed > to cycle. Thus, the sender's counter and the receiver's counter MUST > be reset (by establishing a new SA and thus a new key) prior to the > transmission of the 2^32nd packet on an SA. > > """ Ah, it seems I was reading too quickly and missed the precondition. Thanks for the attention to detail! -Ben From nobody Fri Oct 18 18:00:29 2019 Return-Path: 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 936C0120861; Fri, 18 Oct 2019 18:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 BBuk36i6b6fL; Fri, 18 Oct 2019 18:00:26 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25E1120105; Fri, 18 Oct 2019 18:00:26 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9J10Jch024741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Oct 2019 21:00:22 -0400 Date: Fri, 18 Oct 2019 18:00:19 -0700 From: Benjamin Kaduk To: Christian Hopps Cc: "ipsec@ietf.org WG" , ipsecme-chairs@ietf.org, Paul Wouters , mcr@sandelman.ca Message-ID: <20191019010019.GU43312@kduck.mit.edu> References: <90A18DDA-F20B-4B0C-8FB6-EF5969F7B121@nohats.ca> <2DD52B3F-B503-42FC-B8BF-26DBEAEE04A7@chopps.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2DD52B3F-B503-42FC-B8BF-26DBEAEE04A7@chopps.org> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] Possible new charter text to cover iptfs. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 01:00:29 -0000 I think we've got a couple potential recharter topics in flight, so I'd like to have the chairs assemble a consolidated version with all the updates in it, so that I can start the formal rechartering process. -Ben On Sun, Oct 13, 2019 at 03:10:36AM -0400, Christian Hopps wrote: > Hi ipsecme and charis, > > It seems like we've had a good amount of soak time on this. :) > > What are the next steps? > > Thanks, > Chris. > > > On Aug 7, 2019, at 7:04 PM, Paul Wouters wrote: > > > > Seems broad enough - works for me > > > > Sent from mobile device > > > >> On Aug 7, 2019, at 06:38, Christian Hopps wrote: > >> > >> Hi ipsecme and chairs, > >> > >> As discussed @IETF105 we need to update the charter in order to adopt the IPTFS draft, how does this look for addition to the charter? > >> > >> " > >> The demand for Traffic Flow Confidentiality has been increasing in the user > >> community; however, the current method defined in RFC4303 (i.e., add null > >> padding to each ESP payload) is very inefficient in it's use of network > >> resources. The working group will develop an alternative TFC solution that > >> provides for efficient use of network resources. > >> " > >> > >> Thanks, > >> Chris. > >> _______________________________________________ > >> 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 From nobody Fri Oct 18 18:39:40 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E02E120105; Fri, 18 Oct 2019 18:39:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.106.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <157144917736.3880.1675614872703396908@ietfa.amsl.com> Date: Fri, 18 Oct 2019 18:39:37 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-implicit-iv-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 01:39:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP) Authors : Daniel Migault Tobias Guggemos Yoav Nir Filename : draft-ietf-ipsecme-implicit-iv-09.txt Pages : 8 Date : 2019-10-18 Abstract: Encapsulating Security Payload (ESP) sends an initialization vector (IV) in each packet. The size of IV depends on the applied transform, being usually 8 or 16 octets for the transforms defined by the time this document is written. Some algorithms such as AES-GCM, AES-CCM and ChaCha20-Poly1305 when used with IPsec, take the IV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP Sequence Number (SN) can be used instead to generate the nonce. This avoids sending the IV itself, and saves in the case of AES-GCM, AES-CCM and ChaCha20-Poly1305 8 octets per packet. This document describes how to do this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-09 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-implicit-iv-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-implicit-iv-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 18 18:41:27 2019 Return-Path: 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 2799812012E; Fri, 18 Oct 2019 18:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 B9KiIz3Y-yQd; Fri, 18 Oct 2019 18:41:18 -0700 (PDT) Received: from mail-ua1-f52.google.com (mail-ua1-f52.google.com [209.85.222.52]) (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 BC18D120105; Fri, 18 Oct 2019 18:41:17 -0700 (PDT) Received: by mail-ua1-f52.google.com with SMTP id j5so2368032uak.12; Fri, 18 Oct 2019 18:41:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jpRbF7t7lduSSR7E7WqxA1bQw9tiXFcyNB96ixvm4Qs=; b=ljbFPkorxBYsyiaz44p3MazRre+zKWoGLsTxGzKPkZ4HSPmGnX+wq01KJ5v0eCyqFi W9DAd4whV96uwh0ZMG2FewdQFXtGLagw1/xGXV6xQ46fT/YK1qb6g2B6zJ7v7cKMQAvV VBYYtna4X+Cwy0+X+th1psghe0PAuejm1GegvnaOgSVSWAFZpZvRsDjqU8BhzXkOezzf GlM9NNclmHqCjpBmG3u0uVpk6mmmwviin5zHStuBDYzVCSu97sjN6eOwfLHbkvmQ3tht WU1rwnYzT4zlYn3ONwFtr69xB2GRNFoQO0v/rKnECPwNnrUXcJ/jwf4Sv56gFZfHzSVY FRTg== X-Gm-Message-State: APjAAAXYthfiCnCPrRk+o0B2iXhJ2sFlRs+PaZHaGSan7UapSghjN1fA zO/il+IBYPk5gn/x7XK759K7fkhcGNhFnbNVdEU= X-Google-Smtp-Source: APXvYqyK445LgdzB8QhYUPO0A7DEkw80T4AIk7F8E9AEDNFB9cWAKE91bha6k+LBTkmp0Z2C5myrE6iJ+7AS5gWpzE4= X-Received: by 2002:a9f:3673:: with SMTP id s48mr7042099uad.119.1571449276575; Fri, 18 Oct 2019 18:41:16 -0700 (PDT) MIME-Version: 1.0 References: <157128300620.9968.15171563029563358723.idtracker@ietfa.amsl.com> <20191018194329.GK43312@kduck.mit.edu> In-Reply-To: <20191018194329.GK43312@kduck.mit.edu> From: Daniel Migault Date: Fri, 18 Oct 2019 21:41:05 -0400 Message-ID: To: Benjamin Kaduk Cc: IPsecME WG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org, The IESG , Tero Kivinen Content-Type: multipart/alternative; boundary="000000000000e9b6a10595398b1e" Archived-At: Subject: Re: [IPsec] Benjamin Kaduk's No Objection on draft-ietf-ipsecme-implicit-iv-08: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 01:41:21 -0000 --000000000000e9b6a10595398b1e Content-Type: text/plain; charset="UTF-8" Thank you for the response, I just published a new version with the mentioned text. Thank you again for the comments! Yours, Daniel On Fri, Oct 18, 2019 at 3:43 PM Benjamin Kaduk wrote: > On Thu, Oct 17, 2019 at 10:37:10PM -0400, Daniel Migault wrote: > > Hi Benjamin, > > Thanks you for the comments. Please see in line my responses. > > Yours, > > Daniel > > On Wed, Oct 16, 2019 at 11:30 PM Benjamin Kaduk via Datatracker > > wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-ipsecme-implicit-iv-08: No Objection > > > > When responding, please keep the subject line intact and reply to > all > > email addresses included in the To and CC lines. (Feel free to cut > this > > introductory paragraph, however.) > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ > > > > > ---------------------------------------------------------------------- > > COMMENT: > > > ---------------------------------------------------------------------- > > > > Thanks for addressing my Discuss! > > > > A few new comments on the -08: > > > > Abstract > > > > If we're going to differentiate between nonce and IV, I think that > > the algorithms require a unique but not necessarily unpredictable > > *nonce*, > > rather than *IV*. > > > > I would preferred to have IV instead of nonce is that IPsec provides > > constraints on the IV, not the nonce. I expected to have switched from > > algorithms to their implementations by writing "when used with IPsec" > in > > the previous sentence. In order to flip-flop from algorithm to their > > implementations with IPsec, I propose to clarify this as follows: > > OLD: > > These > > algorithms require a unique IV but do not require an unpredictable IV. > > NEW: > > This IV must be unique but can be predictable. > > Thanks! > > > > > Section 2 > > > > nit: s/Initialize/Initialization/ > > > > Fixed > > > > nit: s/similar mechanism/similar mechanisms/ plural > > > > Fixed > > > > > > Section 7 > > > > My previous ballot was trying to note that the sender/receiver > counters > > MUST be reset (as noted here) even without this document, as part of > > the core ESP requirements. So we don't need to use the "MUST" here > as > > if it's a new requirement; we can just say that this behavior is > already > > present due to the preexisting requirements > > > > Well, the reason I included it was that - at least my reading of ESP > - ESP > > seems to require key to be rekeyed when the SN reaches its limit only > when > > anti-replay is activated. In our case, we need to have this property > even > > without anti replay protection. Here is the text I considered rfc4303 > > section 2.2 > > """ > > > > The sender's counter and the receiver's counter are initialized to 0 > > when an SA is established. (The first packet sent using a given SA > > will have a sequence number of 1; see Section 3.3.3 for more details > > on how the sequence number is generated.) If anti-replay is enabled > > (the default), the transmitted sequence number must never be allowed > > to cycle. Thus, the sender's counter and the receiver's counter MUST > > be reset (by establishing a new SA and thus a new key) prior to the > > transmission of the 2^32nd packet on an SA. > > > > """ > > Ah, it seems I was reading too quickly and missed the precondition. > Thanks for the attention to detail! > > -Ben > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --000000000000e9b6a10595398b1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the response, I just published a new version= with the mentioned=C2=A0 text.

Thank you again for the = comments!
Yours,=C2=A0
Daniel=C2=A0

On Fri, Oct 18= , 2019 at 3:43 PM Benjamin Kaduk <kaduk= @mit.edu> wrote:
On Thu, Oct 17, 2019 at 10:37:10PM -0400, Daniel Migault wrote:
>=C2=A0 =C2=A0 Hi Benjamin,
>=C2=A0 =C2=A0 Thanks you for the comments. Please see in line my respon= ses.=C2=A0
>=C2=A0 =C2=A0 Yours,
>=C2=A0 =C2=A0 Daniel
>=C2=A0 =C2=A0 On Wed, Oct 16, 2019 at 11:30 PM Benjamin Kaduk via Datat= racker
>=C2=A0 =C2=A0 <noreply@ietf.org> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 Benjamin Kaduk has entered the following ballot po= sition for
>=C2=A0 =C2=A0 =C2=A0 draft-ietf-ipsecme-implicit-iv-08: No Objection >
>=C2=A0 =C2=A0 =C2=A0 When responding, please keep the subject line inta= ct and reply to all
>=C2=A0 =C2=A0 =C2=A0 email addresses included in the To and CC lines. (= Feel free to cut this
>=C2=A0 =C2=A0 =C2=A0 introductory paragraph, however.)
>
>=C2=A0 =C2=A0 =C2=A0 Please refer to
>=C2=A0 =C2=A0 =C2=A0 https://www.ietf.o= rg/iesg/statement/discuss-criteria.html
>=C2=A0 =C2=A0 =C2=A0 for more information about IESG DISCUSS and COMMEN= T positions.
>
>=C2=A0 =C2=A0 =C2=A0 The document, along with other ballot positions, c= an be found here:
>=C2=A0 =C2=A0 =C2=A0 https://dat= atracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/
>
>=C2=A0 =C2=A0 =C2=A0 --------------------------------------------------= --------------------
>=C2=A0 =C2=A0 =C2=A0 COMMENT:
>=C2=A0 =C2=A0 =C2=A0 --------------------------------------------------= --------------------
>
>=C2=A0 =C2=A0 =C2=A0 Thanks for addressing my Discuss!
>
>=C2=A0 =C2=A0 =C2=A0 A few new comments on the -08:
>
>=C2=A0 =C2=A0 =C2=A0 Abstract
>
>=C2=A0 =C2=A0 =C2=A0 If we're going to differentiate between nonce = and IV, I think that
>=C2=A0 =C2=A0 =C2=A0 the algorithms require a unique but not necessaril= y unpredictable
>=C2=A0 =C2=A0 =C2=A0 *nonce*,
>=C2=A0 =C2=A0 =C2=A0 rather than *IV*.
>
>=C2=A0 =C2=A0 I would preferred to have IV instead of nonce is that IPs= ec provides
>=C2=A0 =C2=A0 constraints on the IV, not the nonce. I expected to have = switched from
>=C2=A0 =C2=A0 algorithms to their implementations by writing "when= used with IPsec" in
>=C2=A0 =C2=A0 the previous sentence. In order to flip-flop from algorit= hm to their
>=C2=A0 =C2=A0 implementations with IPsec, I propose to clarify this as = follows:
>=C2=A0 =C2=A0 OLD:
>=C2=A0 =C2=A0 These
>=C2=A0 =C2=A0 algorithms require a unique IV but do not require an unpr= edictable IV.
>=C2=A0 =C2=A0 NEW:
>=C2=A0 =C2=A0 This IV must be unique but can be predictable.=C2=A0

Thanks!

>
>=C2=A0 =C2=A0 =C2=A0 Section 2
>
>=C2=A0 =C2=A0 =C2=A0 nit: s/Initialize/Initialization/
>
>=C2=A0 =C2=A0 Fixed
>
>=C2=A0 =C2=A0 =C2=A0 nit: s/similar mechanism/similar mechanisms/ plura= l
>
>=C2=A0 =C2=A0 Fixed
>=C2=A0 =C2=A0 =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 Section 7
>
>=C2=A0 =C2=A0 =C2=A0 My previous ballot was trying to note that the sen= der/receiver counters
>=C2=A0 =C2=A0 =C2=A0 MUST be reset (as noted here) even without this do= cument, as part of
>=C2=A0 =C2=A0 =C2=A0 the core ESP requirements.=C2=A0 So we don't n= eed to use the "MUST" here as
>=C2=A0 =C2=A0 =C2=A0 if it's a new requirement; we can just say tha= t this behavior is already
>=C2=A0 =C2=A0 =C2=A0 present due to the preexisting requirements
>
>=C2=A0 =C2=A0 Well, the reason I included it was that - at least my rea= ding of ESP - ESP
>=C2=A0 =C2=A0 seems to require key to be rekeyed when the SN reaches it= s limit only when
>=C2=A0 =C2=A0 anti-replay is activated. In our case, we need to have th= is property even
>=C2=A0 =C2=A0 without anti replay protection. Here is the text I consid= ered rfc4303
>=C2=A0 =C2=A0 section 2.2=C2=A0
>=C2=A0 =C2=A0 """
>
>=C2=A0 The sender's counter and the receiver's counter are init= ialized to 0
>=C2=A0 =C2=A0 =C2=A0when an SA is established.=C2=A0 (The first packet = sent using a given SA
>=C2=A0 =C2=A0 =C2=A0will have a sequence number of 1; see Section 3.3.3= for more details
>=C2=A0 =C2=A0 =C2=A0on how the sequence number is generated.)=C2=A0 If = anti-replay is enabled
>=C2=A0 =C2=A0 =C2=A0(the default), the transmitted sequence number must= never be allowed
>=C2=A0 =C2=A0 =C2=A0to cycle.=C2=A0 Thus, the sender's counter and = the receiver's counter MUST
>=C2=A0 =C2=A0 =C2=A0be reset (by establishing a new SA and thus a new k= ey) prior to the
>=C2=A0 =C2=A0 =C2=A0transmission of the 2^32nd packet on an SA.
>
>=C2=A0 =C2=A0 """

Ah, it seems I was reading too quickly and missed the precondition.
Thanks for the attention to detail!

-Ben

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--000000000000e9b6a10595398b1e-- From nobody Mon Oct 21 04:49:15 2019 Return-Path: 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 8921E120110; Mon, 21 Oct 2019 04:49:13 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 ClOHCH3A9NSZ; Mon, 21 Oct 2019 04:49:10 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 5F76E120073; Mon, 21 Oct 2019 04:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1571658549; d=isode.com; s=june2016; i=@isode.com; bh=BoNaTl9v/GWDnThrCyAE+J5fGT9w6l3JyI4L1Lw/ZOU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=gn2AlnHSELma7/nA18rH4sAtCPvBb2wK39MAiZkHQnGyNgK2eM/GJgjiYCobeNtIpLjyK1 lsBlvS1jGGyaAdiiYF9W/kDSTs8+yPvIMQQ+E6JS5nwgipdEV1sONug8urTlf+jYS3NPxX mlo3TA9p/RVdwAyktZH4APsZD+ojUSs=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 21 Oct 2019 12:49:09 +0100 To: Daniel Migault , Adam Roach , secdir@ietf.org Cc: IPsecME WG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org, The IESG References: <157119428147.28057.3364707659942003352.idtracker@ietfa.amsl.com> From: Alexey Melnikov Message-ID: Date: Mon, 21 Oct 2019 12:48:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------61EAFEF949E1759879E2684A" Content-Language: en-GB Archived-At: Subject: Re: [IPsec] [secdir] Adam Roach's Yes on draft-ietf-ipsecme-implicit-iv-07: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 11:49:14 -0000 --------------61EAFEF949E1759879E2684A Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Daniel, On 17/10/2019 15:05, Daniel Migault wrote: > Hi, > > Just to make everyone aware, we have issued a new version that we hope=20 > addresses all concerns. > https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-08 Thank you for posting -08 and -09. I just need one more change: IANA pointed out that you removed the name=20 of the registry from the IANA Considerations section. You should add it=20 back, as not having it in the document is confusing. Thank you, Alexey > Yours, > Daniel > > On Tue, Oct 15, 2019 at 11:07 PM Daniel Migault=20 > > wrote: > > Hi Adam, > > Thanks for the feed back. All your comments have been fixed on the > current local version available at: > https://github.com/mglt/draft-mglt-ipsecme-implicit-iv/blob/master/dra= ft-ietf-ipsecme-implicit-iv.txt > > We expect to publish the version tomorrow. > > Yours, > Daniel > > > > On Tue, Oct 15, 2019 at 10:51 PM Adam Roach via Datatracker > > wrote: > > Adam Roach has entered the following ballot position for > draft-ietf-ipsecme-implicit-iv-07: Yes > > When responding, please keep the subject line intact and reply > to all > email addresses included in the To and CC lines. (Feel free to > cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found > here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ > > > > ------------------------------------------------------------------= ---- > COMMENT: > ------------------------------------------------------------------= ---- > > Thanks for the work on this mechanism. I have no substantive > comments > beyond those that have already been shared, although I do have > some > minor editorial comments. > > ------------------------------------------------------------------= --------- > > =C2=A72: > > >=C2=A0 In some context, such as IoT, it may be preferable to avoi= d > carrying > > Nit: "...some contexts..." > > Fixed > > ------------------------------------------------------------------= --------- > > =C2=A75: > > >=C2=A0 An initiator supporting this feature SHOULD propose implic= it IV > >=C2=A0 algorithms in the Transform Type 1 (Encryption Algorithm) > >=C2=A0 Substructure of the Proposal Substructure inside the SA > Payload. > > Please expand "SA" on first use. > > Fixed > > ------------------------------------------------------------------= --------- > > > 7.=C2=A0 Security Consideration > > Nit: "Considerations" > > Fixed > > > ------------------------------------------------------------------= --------- > > =C2=A77: > > >=C2=A0 extensions ([RFC6311], [RFC7383]) do allow it to repeat, s= o > there is > >=C2=A0 no an easy way to derive unique IV from IKEv2 header field= s. > > Nit: "...not an easy way..." > > Fixed > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --------------61EAFEF949E1759879E2684A Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Daniel,

On 17/10/2019 15:05, Daniel Migault wrote:
Hi,=C2=A0

Just to make everyone aware, we have issued a new version that we hope addresses all concerns.=C2=A0

Thank you for posting -08 and -09.

I just need one more change: IANA pointed out that you removed the name of the registry from the IANA Considerations section. You should add it back, as not having it in the document is confusing.

Thank you,

Alexey

Yours,=C2=A0
Daniel

On Tue, Oct 15, 2019 at 11:07 PM Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi Adam,=C2=A0

Thanks for the feed back. All your comments have been fixed on the current local version available at:

We expect to publish the version tomorrow.

Yours,=C2=A0
Daniel



On Tue, Oct 15, 2019 at 10:51 PM Adam Roach via Datatracker <noreply@ietf.org> wrote:
Adam Roach has entered the following ballot position for
draft-ietf-ipsecme-implicit-iv-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/stateme= nt/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/= draft-ietf-ipsecme-implicit-iv/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the work on this mechanism. I have no substantive comments
beyond those that have already been shared, although I do have some
minor editorial comments.

---------------------------------------------------------------------------<= br>
=C2=A72:

>=C2=A0 In some context, such as IoT, it may be preferabl= e to avoid carrying

Nit: "...some contexts..."

Fixed=C2=A0
---------------------------------------------------------------------------<= br>
=C2=A75:

>=C2=A0 An initiator supporting this feature SHOULD propose implicit IV
>=C2=A0 algorithms in the Transform Type 1 (Encryption Algorithm)
>=C2=A0 Substructure of the Proposal Substructure inside the SA Payload.

Please expand "SA" on first use.

Fixed=C2=A0
---------------------------------------------------------------------------<= br>
> 7.=C2=A0 Security Consideration

Nit: "Considerations"
Fixed=C2=A0

---------------------------------------------------------------------------<= br>
=C2=A77:

>=C2=A0 extensions ([RFC6311], [RFC7383]) do allow it to repeat, so there is
>=C2=A0 no an easy way to derive unique IV from IKEv2 header fields.

Nit: "...not an easy way..."
Fixed=C2=A0


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/list= info/ipsec

_______________________________=
________________
secdir mailing list
secdir=
@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirR=
eview
--------------61EAFEF949E1759879E2684A-- From nobody Mon Oct 21 04:55:11 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA76120113; Mon, 21 Oct 2019 04:55:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.106.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <157165890548.31862.5481269353392586355@ietfa.amsl.com> Date: Mon, 21 Oct 2019 04:55:05 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 11:55:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : IKEv2 Notification Status Types for IPv4/IPv6 Coexistence Author : Mohamed Boucadair Filename : draft-ietf-ipsecme-ipv6-ipv4-codes-04.txt Pages : 7 Date : 2019-10-21 Abstract: This document specifies new IKEv2 notification status types to better manage IPv4 and IPv6 co-existence. This document updates RFC7296. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ipv6-ipv4-codes-04 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ipv6-ipv4-codes-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ipv6-ipv4-codes-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 21 12:28:44 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 926FA12084A; Mon, 21 Oct 2019 12:28:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.106.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <157168611752.31862.14783102680670622152@ietfa.amsl.com> Date: Mon, 21 Oct 2019 12:28:37 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-implicit-iv-10.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 19:28:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP) Authors : Daniel Migault Tobias Guggemos Yoav Nir Filename : draft-ietf-ipsecme-implicit-iv-10.txt Pages : 8 Date : 2019-10-21 Abstract: Encapsulating Security Payload (ESP) sends an initialization vector (IV) in each packet. The size of IV depends on the applied transform, being usually 8 or 16 octets for the transforms defined by the time this document is written. Some algorithms such as AES-GCM, AES-CCM and ChaCha20-Poly1305 when used with IPsec, take the IV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP Sequence Number (SN) can be used instead to generate the nonce. This avoids sending the IV itself, and saves in the case of AES-GCM, AES-CCM and ChaCha20-Poly1305 8 octets per packet. This document describes how to do this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-10 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-implicit-iv-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-implicit-iv-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 21 12:30:43 2019 Return-Path: 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 0E55612086C; Mon, 21 Oct 2019 12:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 DjDTQwaJ5OCq; Mon, 21 Oct 2019 12:30:26 -0700 (PDT) Received: from mail-vs1-f65.google.com (mail-vs1-f65.google.com [209.85.217.65]) (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 A9DF71208B8; Mon, 21 Oct 2019 12:30:25 -0700 (PDT) Received: by mail-vs1-f65.google.com with SMTP id v19so9684561vsv.3; Mon, 21 Oct 2019 12:30:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Drs9YQIPcb6crNlgYPNih2kiFPiuBKFxKfjUn0iEIK8=; b=Gy7/za9YBDIR1DFo6vj+bKcUW80A0vak8TtUkY/2lVMTyrJxTzePF5FQV0A/xSbZ4K Di76mtxmOHU/8UqymcnumMCXoOiQmDSX7Km4W5oezGpjJN48DjoANsjpRLIls1522Ehh M2aiB+9QaPsg2SobZoiqDQa1iJlkIjTjf20SSNcY7J0Xh6DtYmnWDCiPqKT5mUqE803Z hzomYh5YzqDPKlU7p4TYI/LvGnZtGNWHCFxJ6HkEpwEcdZij24fTxdClJLjZnypQgyky f2nFMvwIcYP7kNYMq0s8aJz6oSCV5NbfrfYRM9jk1jl1oZe9+cX6+gfz6pTSRxUkYGRG 988A== X-Gm-Message-State: APjAAAUYT5qPDgyHKWOboaEkBzGVAlsuAExvhAYWXivTwNaJL18XYgXv 6N/gZ1gyFoTTsxinAsU8L0L1MGn87xWPTHU9JKeJcOB4UWo= X-Google-Smtp-Source: APXvYqzvkF5re67UyMGTIG+/zPERnNlEoy0IglN7TZEwsMczfsptUMLKYAwk1bhmM/nAWf2sMQCzAd22w/8vVevC/qE= X-Received: by 2002:a67:e88b:: with SMTP id x11mr14296897vsn.180.1571686224552; Mon, 21 Oct 2019 12:30:24 -0700 (PDT) MIME-Version: 1.0 References: <157119428147.28057.3364707659942003352.idtracker@ietfa.amsl.com> In-Reply-To: From: Daniel Migault Date: Mon, 21 Oct 2019 15:30:13 -0400 Message-ID: To: Alexey Melnikov Cc: Daniel Migault , Adam Roach , secdir@ietf.org, IPsecME WG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org, The IESG Content-Type: multipart/alternative; boundary="0000000000001ce8b1059570b77c" Archived-At: Subject: Re: [IPsec] [secdir] Adam Roach's Yes on draft-ietf-ipsecme-implicit-iv-07: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 19:30:37 -0000 --0000000000001ce8b1059570b77c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Alexey, I just posted a new version with the following text: """ The IANA has assigned the following code points to the registry Transform Type 1 - Encryption Algorithm Transform IDs [IANA]: """ Yours, Daniel On Mon, Oct 21, 2019 at 7:49 AM Alexey Melnikov wrote: > Hi Daniel, > On 17/10/2019 15:05, Daniel Migault wrote: > > Hi, > > Just to make everyone aware, we have issued a new version that we hope > addresses all concerns. > https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-08 > > Thank you for posting -08 and -09. > > I just need one more change: IANA pointed out that you removed the name o= f > the registry from the IANA Considerations section. You should add it back= , > as not having it in the document is confusing. > > Thank you, > > Alexey > > Yours, > Daniel > > On Tue, Oct 15, 2019 at 11:07 PM Daniel Migault < > daniel.migault@ericsson.com> wrote: > >> Hi Adam, >> >> Thanks for the feed back. All your comments have been fixed on the >> current local version available at: >> >> https://github.com/mglt/draft-mglt-ipsecme-implicit-iv/blob/master/draft= -ietf-ipsecme-implicit-iv.txt >> >> We expect to publish the version tomorrow. >> >> Yours, >> Daniel >> >> >> >> On Tue, Oct 15, 2019 at 10:51 PM Adam Roach via Datatracker < >> noreply@ietf.org> wrote: >> >>> Adam Roach has entered the following ballot position for >>> draft-ietf-ipsecme-implicit-iv-07: Yes >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Thanks for the work on this mechanism. I have no substantive comments >>> beyond those that have already been shared, although I do have some >>> minor editorial comments. >>> >>> >>> -----------------------------------------------------------------------= ---- >>> >>> =C2=A72: >>> >>> > In some context, such as IoT, it may be preferable to avoid carrying >>> >>> Nit: "...some contexts..." >>> >>> Fixed >> >>> >>> -----------------------------------------------------------------------= ---- >>> >>> =C2=A75: >>> >>> > An initiator supporting this feature SHOULD propose implicit IV >>> > algorithms in the Transform Type 1 (Encryption Algorithm) >>> > Substructure of the Proposal Substructure inside the SA Payload. >>> >>> Please expand "SA" on first use. >>> >>> Fixed >> >>> >>> -----------------------------------------------------------------------= ---- >>> >>> > 7. Security Consideration >>> >>> Nit: "Considerations" >>> >> Fixed >> >>> >>> >>> -----------------------------------------------------------------------= ---- >>> >>> =C2=A77: >>> >>> > extensions ([RFC6311], [RFC7383]) do allow it to repeat, so there is >>> > no an easy way to derive unique IV from IKEv2 header fields. >>> >>> Nit: "...not an easy way..." >>> >> Fixed >> >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >> > _______________________________________________ > secdir mailing listsecdir@ietf.orghttps://www.ietf.org/mailman/listinfo/s= ecdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0000000000001ce8b1059570b77c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Alexey,=C2=A0

I just posted a ne= w version with the following text:

""&qu= ot;
=C2=A0 =C2=A0The IANA has assigned the following code points = to the registry
=C2=A0 =C2=A0Transform Type 1 - Encryption Algorithm Tra= nsform IDs [IANA]:

"""=C2=A0
Yours,=C2=A0
Daniel

On Mon, Oct 21, 2019 at 7:49 AM Ale= xey Melnikov <alexey.melnik= ov@isode.com> wrote:
=20 =20 =20

Hi Daniel,

On 17/10/2019 15:05, Daniel Migault wrote:
=20
Hi,=C2=A0

Just to make everyone aware, we have issued a new version that we hope addresses all concerns.=C2=A0

Thank you for posting -08 and -09.

I just need one more change: IANA pointed out that you removed the name of the registry from the IANA Considerations section. You should add it back, as not having it in the document is confusing.

Thank you,

Alexey

Yours,=C2=A0
Daniel

On Tue, Oct 15, 2019 at 11:07 PM Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi Adam,=C2=A0

Thanks for the feed back. All your comments have been fixed on the current local version available at:

We expect to publish the version tomorrow.

Yours,=C2=A0
Daniel



On Tue, Oct 15, 2019 at 10:51 PM Adam Roach via Datatracker <noreply@ietf.org> wrote:
Adam Roach = has entered the following ballot position for
draft-ietf-ipsecme-implicit-iv-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www= .ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.= ietf.org/doc/draft-ietf-ipsecme-implicit-iv/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the work on this mechanism. I have no substantive comments
beyond those that have already been shared, although I do have some
minor editorial comments.

---------------------------------------------------------------------------=

=C2=A72:

>=C2=A0 In some context, such as IoT, it may be preferab= le to avoid carrying

Nit: "...some contexts..."

Fixed=C2=A0
---------------------------------------------------------------------------=

=C2=A75:

>=C2=A0 An initiator supporting this feature SHOULD propose implicit IV
>=C2=A0 algorithms in the Transform Type 1 (Encryption Algorithm)
>=C2=A0 Substructure of the Proposal Substructure inside the SA Payload.

Please expand "SA" on first use.

Fixed=C2=A0
---------------------------------------------------------------------------=

> 7.=C2=A0 Security Consideration

Nit: "Considerations"
Fixed=C2=A0

---------------------------------------------------------------------------=

=C2=A77:

>=C2=A0 extensions ([RFC6311], [RFC7383]) do allow it to repeat, so there is
>=C2=A0 no an easy way to derive unique IV from IKEv2 header fields.

Nit: "...not an easy way..."
Fixed=C2=A0


_______________________________________________
IPsec mailing list
IPsec@i= etf.org
https://www.ietf.org/mailman/listinfo/ips= ec

_______________________________________________
secdir mailing list
secdir@ietf.org
=
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--0000000000001ce8b1059570b77c-- From nobody Mon Oct 21 14:45:34 2019 Return-Path: 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 411F312001A; Mon, 21 Oct 2019 14:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 PKtV9Bu6yufQ; Mon, 21 Oct 2019 14:45:29 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4E468120019; Mon, 21 Oct 2019 14:45:29 -0700 (PDT) Received: from stubbs.int.chopps.org (172-222-100-236.res.spectrum.com [172.222.100.236]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 732FA600E7; Mon, 21 Oct 2019 21:45:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Christian Hopps In-Reply-To: <20191019010019.GU43312@kduck.mit.edu> Date: Mon, 21 Oct 2019 17:45:27 -0400 Cc: Christian Hopps , "ipsec@ietf.org WG" , ipsecme-chairs@ietf.org, Paul Wouters , mcr@sandelman.ca Content-Transfer-Encoding: quoted-printable Message-Id: <905631BC-A6F3-4364-BF25-50B0945A88AE@chopps.org> References: <90A18DDA-F20B-4B0C-8FB6-EF5969F7B121@nohats.ca> <2DD52B3F-B503-42FC-B8BF-26DBEAEE04A7@chopps.org> <20191019010019.GU43312@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [IPsec] Possible new charter text to cover iptfs. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 21:45:31 -0000 Hi Ben, To perhaps speed this up a little bit, could we maybe run the process in = parallel then? We had very positive feedback at the last meeting for = adopting draft-hopps-ipsecme-iptfs-01 draft as a WG item, but since new = work in ipsecme needs specific charter changes as well, and that seems = to take a while, this adoption call has been delayed almost a full = meeting cycle at this point. IOW, could we do an adoption call contingent on the charter change, and = then when the charter change happens we can at the same time adopt the = draft as a WG item, thus avoiding more process delay? Thanks, Chris. > On Oct 18, 2019, at 9:00 PM, Benjamin Kaduk wrote: >=20 > I think we've got a couple potential recharter topics in flight, so = I'd > like to have the chairs assemble a consolidated version with all the > updates in it, so that I can start the formal rechartering process. >=20 > -Ben >=20 > On Sun, Oct 13, 2019 at 03:10:36AM -0400, Christian Hopps wrote: >> Hi ipsecme and charis, >>=20 >> It seems like we've had a good amount of soak time on this. :) >>=20 >> What are the next steps? >>=20 >> Thanks, >> Chris. >>=20 >>> On Aug 7, 2019, at 7:04 PM, Paul Wouters wrote: >>>=20 >>> Seems broad enough - works for me >>>=20 >>> Sent from mobile device >>>=20 >>>> On Aug 7, 2019, at 06:38, Christian Hopps = wrote: >>>>=20 >>>> Hi ipsecme and chairs, >>>>=20 >>>> As discussed @IETF105 we need to update the charter in order to = adopt the IPTFS draft, how does this look for addition to the charter? >>>>=20 >>>> " >>>> The demand for Traffic Flow Confidentiality has been increasing in = the user >>>> community; however, the current method defined in RFC4303 (i.e., = add null >>>> padding to each ESP payload) is very inefficient in it's use of = network >>>> resources. The working group will develop an alternative TFC = solution that >>>> provides for efficient use of network resources. >>>> " >>>>=20 >>>> Thanks, >>>> Chris. >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 From nobody Tue Oct 22 13:20:49 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44805120077; Tue, 22 Oct 2019 13:20:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.107.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <157177564321.13153.13299702553406737341@ietfa.amsl.com> Date: Tue, 22 Oct 2019 13:20:43 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-implicit-iv-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 20:20:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP) Authors : Daniel Migault Tobias Guggemos Yoav Nir Filename : draft-ietf-ipsecme-implicit-iv-11.txt Pages : 8 Date : 2019-10-22 Abstract: Encapsulating Security Payload (ESP) sends an initialization vector (IV) in each packet. The size of IV depends on the applied transform, being usually 8 or 16 octets for the transforms defined by the time this document is written. Some algorithms such as AES-GCM, AES-CCM and ChaCha20-Poly1305 when used with IPsec, take the IV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP Sequence Number (SN) can be used instead to generate the nonce. This avoids sending the IV itself, and saves in the case of AES-GCM, AES-CCM and ChaCha20-Poly1305 8 octets per packet. This document describes how to do this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-11 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-implicit-iv-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-implicit-iv-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 23 11:21:23 2019 Return-Path: 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 2FD79120CB1; Wed, 23 Oct 2019 11:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Abu3d3zNA6au; Wed, 23 Oct 2019 11:21:19 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBAB2120D10; Wed, 23 Oct 2019 11:21:16 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9NILBYb030230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Oct 2019 14:21:13 -0400 Date: Wed, 23 Oct 2019 11:21:11 -0700 From: Benjamin Kaduk To: Christian Hopps Cc: "ipsec@ietf.org WG" , ipsecme-chairs@ietf.org, Paul Wouters , mcr@sandelman.ca Message-ID: <20191023182111.GY69013@kduck.mit.edu> References: <90A18DDA-F20B-4B0C-8FB6-EF5969F7B121@nohats.ca> <2DD52B3F-B503-42FC-B8BF-26DBEAEE04A7@chopps.org> <20191019010019.GU43312@kduck.mit.edu> <905631BC-A6F3-4364-BF25-50B0945A88AE@chopps.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <905631BC-A6F3-4364-BF25-50B0945A88AE@chopps.org> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] Possible new charter text to cover iptfs. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 18:21:22 -0000 Hi Chris, On Mon, Oct 21, 2019 at 05:45:27PM -0400, Christian Hopps wrote: > Hi Ben, > > To perhaps speed this up a little bit, could we maybe run the process in parallel then? We had very positive feedback at the last meeting for adopting draft-hopps-ipsecme-iptfs-01 draft as a WG item, but since new work in ipsecme needs specific charter changes as well, and that seems to take a while, this adoption call has been delayed almost a full meeting cycle at this point. > > IOW, could we do an adoption call contingent on the charter change, and then when the charter change happens we can at the same time adopt the draft as a WG item, thus avoiding more process delay? Yes, it should be possible to run a contigent adoption call in parallel with rechartering discussions. -Ben From nobody Fri Oct 25 14:12:17 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1D112004A; Fri, 25 Oct 2019 14:12:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ipsec@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203792012.2724.7753700338560191884.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:00 -0700 Archived-At: Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 106 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 21:12:00 -0000 Dear Tero Kivinen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipsecme Session 1 (1:30 requested) Thursday, 21 November 2019, Afternoon Session II 1550-1720 Room Name: Olivia size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/106/sessions/ipsecme.ics Request Information: --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: suit Technology Overlap: i2nsf curdle tls saag cfrg tcpm Key Participant Conflict: uta 6lo 6tisch lwig ace People who must be present: Tero Kivinen David Waltermire Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Oct 26 00:29:17 2019 Return-Path: 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 D66C912006E; Sat, 26 Oct 2019 00:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 uvU-mLY4ac8A; Sat, 26 Oct 2019 00:29:06 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 154B712006F; Sat, 26 Oct 2019 00:29:06 -0700 (PDT) Received: from stubbs.int.chopps.org.chopps.org (172-222-100-236.res.spectrum.com [172.222.100.236]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 5B2436016D; Sat, 26 Oct 2019 07:29:05 +0000 (UTC) User-agent: mu4e 1.3.4; emacs 26.3 From: Christian Hopps To: Benjamin Kaduk Cc: Christian Hopps , "ipsec\@ietf.org WG" , ipsecme-chairs@ietf.org, Paul Wouters , mcr@sandelman.ca Date: Sat, 26 Oct 2019 03:29:04 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [IPsec] Request for call for adoption contingent on charter changes. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2019 07:29:16 -0000 --=-=-= Content-Type: text/plain; format=flowed Hi, Given the positive feedback for adopting during the previous IETF meeting, a desire to lower the process overhead, and the blessing of the AD, I'd like to request the chairs issue a call for adoption, contingent on the appropriate charter changes being adopted, be made for draft-hopps-ipsecme-iptfs-01. It would be great to make some progress on this prior to the next meeting which is imminent. :) Thanks, Chris. Benjamin Kaduk writes: > Hi Chris, > > On Mon, Oct 21, 2019 at 05:45:27PM -0400, Christian Hopps wrote: >> Hi Ben, >> >> To perhaps speed this up a little bit, could we maybe run the process in parallel then? We had very positive feedback at the last meeting for adopting draft-hopps-ipsecme-iptfs-01 draft as a WG item, but since new work in ipsecme needs specific charter changes as well, and that seems to take a while, this adoption call has been delayed almost a full meeting cycle at this point. >> >> IOW, could we do an adoption call contingent on the charter change, and then when the charter change happens we can at the same time adopt the draft as a WG item, thus avoiding more process delay? > > Yes, it should be possible to run a contigent adoption call in parallel > with rechartering discussions. > > -Ben --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl2z9cAACgkQLh2DDte4 MCWkQBAAjUHmxcFryRLQaZXflRzi1TG35nf9syhfgMWxDYfEmxmzK/5v/aChtraD /oL2t7Lbg99rvQpR0jwWB5AbEtwxcoNYj0wZh67PQoJvC5nhfyLpFl5QEzgOSaQX cnIA36VZRP0rT0e2EPNsuIIFZhzVhHpecooagZ9wqCqHEsqPEUzX/rYdQLYfOD34 cvONfB4+1njFBDh+51M+wwkvk2bBdctwsPLFXJ/fSfu5sdxi49fCjsCWiBG1WVpL ZUXOWmnF7qVr0hX+/T22rsPlJFqSFv1p2mqI1iWrmrmrleDAzz5zDiEdkWdP32zb 0gv+GdI07Qrv0G4C52kDKF2Tu3KRcl6/HeZNUrti2C4BAQrirg8+crXaI7in4EsH 6VQLXTY4pIeGEu45bAkEVNyUVwcAiAq5ucm3Pcd1tAGIwHdSdFalDjI8J0PZub9I V9ztraXSRrbNqTliHDgsEHm/uTcSi30r2VbMfN74ktwhIFEzXUr0q8f19rLmn+TV 25AmMT7yljR5+TIyA1tvOrOk35cXCZJ7AMM0XmTriaSETSO01v5bZHNBUYXV94H4 xWnpUL7ke+WzkIYnv41ZEiXcwitfCfu2PA5m6yO2eF+YlCxdZ+iCW+sq/mrSktG6 Ep2hSY0bOX2r9RpZg9vsQFUSqr5hl5T7SSU+9IyVqbNlZl9ie0g= =DaL8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 26 08:12:25 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD461200B4; Sat, 26 Oct 2019 08:12:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157210274390.7657.6246232206100028640.idtracker@ietfa.amsl.com> Date: Sat, 26 Oct 2019 08:12:23 -0700 Archived-At: Subject: [IPsec] The IPSECME WG has placed draft-hopps-ipsecme-iptfs in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2019 15:12:24 -0000 The IPSECME WG has placed draft-hopps-ipsecme-iptfs in state Call For Adoption By WG Issued (entered by Tero Kivinen) The document is available at https://datatracker.ietf.org/doc/draft-hopps-ipsecme-iptfs/ Comment: The charter item is being processed in parallel to WG adoption call. From nobody Sat Oct 26 08:17:21 2019 Return-Path: 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 7F0EF1200B2 for ; Sat, 26 Oct 2019 08:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no 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 8GZ4jCxPLBBq for ; Sat, 26 Oct 2019 08:17:19 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B8712007A for ; Sat, 26 Oct 2019 08:17:18 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x9QFHGRN006108 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 26 Oct 2019 18:17:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x9QFHGAj002276; Sat, 26 Oct 2019 18:17:16 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23988.25468.681313.594115@fireball.acr.fi> Date: Sat, 26 Oct 2019 18:17:16 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 4 min Archived-At: Subject: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2019 15:17:20 -0000 So this is fast (one week) adoption call for the draft-hopps-ipsecme-iptfs draft to be accepted to the WG document. We did have quite positive feedback in last IETF meeting and the charter item is being worked on in parallel to this call. If you support adopting this document as WG document and as a starting place for the charter item proposed for the WG, then send email indicating your support to the ipsec@ietf.org mailing-list. If you have any comments or reservations send them to list too. This adoption call finishes at 2019-11-04. ---------------------------------------------------------------------- The demand for Traffic Flow Confidentiality has been increasing in the user community; however, the current method defined in RFC4303 (i.e., add null padding to each ESP payload) is very inefficient in it's use of network resources. The working group will develop an alternative TFC solution that provides for efficient use of network resources. -- kivinen@iki.fi From nobody Sat Oct 26 22:40:03 2019 Return-Path: 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 329C712004A for ; Sat, 26 Oct 2019 22:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 7RsfZjJCz8EP for ; Sat, 26 Oct 2019 22:39:59 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 16556120018 for ; Sat, 26 Oct 2019 22:39:59 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id s4so6990900ljj.10 for ; Sat, 26 Oct 2019 22:39:58 -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:thread-index:content-language; bh=zjigHBRVIzBMiaVqHzXXTg8z8r/qKqvSdZS427AydvM=; b=Hpy9TbiOblVXpIm3pvUt1E6yQSrU01QkwVUSy4JQgP1aAYmbmSRIGmal12XMpJZ9yB lZwAcfxaday2/XV5iys+HYMsswxdMAk7H1YFVtsnA60ZcSbTBvG8xGjj7C+vbShUERFt s8KyCVpnnPJfulBGzUOo1JR77pOThNg4oj/yl/QaWdzLNybrcv0rErF6t3jP+una7O4B vExECMH39rESD3BuiWeLntVw/s7wRgyM/bFJYrLQeOF6Qqzh1hA9a1TD3Ts5rwaakAGi 9QeLsaSL/7zKE5t3u/pYqs6zkyJHD3qI/RP7F/U4rJ7UVWhXnowYAw2hd8j4vGXD1S6h dQkA== 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:thread-index :content-language; bh=zjigHBRVIzBMiaVqHzXXTg8z8r/qKqvSdZS427AydvM=; b=QMJFBFDdGktIH6R+pSop9kD+hdvwD0lx1wEy6oNv3rmJ1SOpW4gJ/+7kHCzd1rBXCk PYGYfEFRvHerv5Btn1CGAWTWx9FvYlY3vL9TSSnMQ69T2aXKeyamA5tq//+N9stOcgHT Cm+A7YtKSTBo7FcL+9CraTRoDWwAlh2qccwD01Ghxos25vGiJnokZZbsTMQKQxIhuEPg kwNQEqLZtvHCSgOsf9ksxdZ1JCWfrHrvLL5CmSaEsjQ9kj7r23s5+UNBw6XQdgpIKogw JhDSgn2PEXUCOUiXhpjQpvKBkh58COa/YbvdTwVf0LJe1/LiuxcAXrw+BeRA71qOorwp ff5w== X-Gm-Message-State: APjAAAWzkx3rQ/zIqYwt1ff5+kbCxayeawZgWThKkV1a+TMp1teWQOL1 UTirRK4ZmzlhjCY/bQ1YEBhgcsn0 X-Google-Smtp-Source: APXvYqyVEKGgbJyjMzlgh9QHM2fJMIt1ZUd18uHo5C8gOpJccT1RpwkEAW8LjVb6ieMrRI6Q5bkogw== X-Received: by 2002:a2e:99cf:: with SMTP id l15mr7744014ljj.109.1572154796418; Sat, 26 Oct 2019 22:39:56 -0700 (PDT) Received: from svannotebook ([185.48.36.128]) by smtp.gmail.com with ESMTPSA id q124sm3534993ljb.28.2019.10.26.22.39.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Oct 2019 22:39:55 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" , References: <23988.25468.681313.594115@fireball.acr.fi> In-Reply-To: <23988.25468.681313.594115@fireball.acr.fi> Date: Sun, 27 Oct 2019 08:39:54 +0300 Message-ID: <001801d58c88$f691d150$e3b573f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQL7Zy6wwPyb2KUEt21aF/XVetYHraUiPh9Q Content-Language: ru Archived-At: Subject: Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2019 05:40:01 -0000 Hi, I've read the draft and I think it addresses an important problem. So, I support adoption of the draft as a starting point ( I think the draft has some issues that can be addressed in WG). Regards, Valery. > -----Original Message----- > From: IPsec On Behalf Of Tero Kivinen > Sent: Saturday, October 26, 2019 6:17 PM > To: ipsec@ietf.org > Subject: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs > > So this is fast (one week) adoption call for the draft-hopps-ipsecme-iptfs draft > to be accepted to the WG document. We did have quite positive feedback in > last IETF meeting and the charter item is being worked on in parallel to this call. > > If you support adopting this document as WG document and as a starting place > for the charter item proposed for the WG, then send email indicating your > support to the ipsec@ietf.org mailing-list. If you have any comments or > reservations send them to list too. > > This adoption call finishes at 2019-11-04. > > ---------------------------------------------------------------------- > The demand for Traffic Flow Confidentiality has been increasing in the user > community; however, the current method defined in RFC4303 (i.e., add null > padding to each ESP payload) is very inefficient in it's use of network > resources. The working group will develop an alternative TFC solution that > provides for efficient use of network resources. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sun Oct 27 07:05:55 2019 Return-Path: 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 E60FF12012A for ; Sun, 27 Oct 2019 07:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 WQGy2U3SCU8N for ; Sun, 27 Oct 2019 07:05:52 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C378E120122 for ; Sun, 27 Oct 2019 07:05:52 -0700 (PDT) Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 993E3F4013F52 for ; Sun, 27 Oct 2019 08:05:50 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id OjB0iN5MPXy4mOjB0iHr1X; Sun, 27 Oct 2019 08:05:50 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=QYRIQPTv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10:nop_charset_1 a=xqWC_Br6kY4A:10:nop_ipv6 a=XobE76Q3jBoA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=48vgC7mUAAAA:8 a=HJ2gHA37ykDUxFPf0CQA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=gPXq3GBd8ssA:10:uccc_2email_address a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=NJ/jSLylRHmq6mDE5k2wdCLlu0NzBEY7J0i7f8Nff2A=; b=eMWsc+Ne74ah65Mwhs6lTvrPEj pNuQ1Aw1qX47fBgjlaRC/J14ZzWnyri+g6/VfUr1ua+kTQLtm+MHFYpWnsjir41TCTr2+AV/jkidq E+lldnKygT4cMpAjGT+VfspR1; Received: from [127.0.0.1] (port=24141 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iOjB0-0038jy-9t; Sun, 27 Oct 2019 08:05:50 -0600 To: Tero Kivinen , ipsec@ietf.org References: <23988.25468.681313.594115@fireball.acr.fi> From: Lou Berger Message-ID: Date: Sun, 27 Oct 2019 10:05:45 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <23988.25468.681313.594115@fireball.acr.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1iOjB0-0038jy-9t X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:24141 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2019 14:05:54 -0000 Hi, I support adoption and the charter addition.  (No surprise as I'm a contributor to this work.) Also, I know of no IPR that applies to this draft. Lou On 10/26/2019 11:17 AM, Tero Kivinen wrote: > So this is fast (one week) adoption call for the > draft-hopps-ipsecme-iptfs draft to be accepted to the WG document. We > did have quite positive feedback in last IETF meeting and the charter > item is being worked on in parallel to this call. > > If you support adopting this document as WG document and as a starting > place for the charter item proposed for the WG, then send email > indicating your support to the ipsec@ietf.org mailing-list. If you > have any comments or reservations send them to list too. > > This adoption call finishes at 2019-11-04. > > ---------------------------------------------------------------------- > The demand for Traffic Flow Confidentiality has been increasing in the user > community; however, the current method defined in RFC4303 (i.e., add null > padding to each ESP payload) is very inefficient in it's use of network > resources. The working group will develop an alternative TFC solution that > provides for efficient use of network resources. From nobody Sun Oct 27 11:32:04 2019 Return-Path: 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 B03CC1200C3 for ; Sun, 27 Oct 2019 11:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 XDOqSuTxAiQr for ; Sun, 27 Oct 2019 11:32:02 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 31C8C120046 for ; Sun, 27 Oct 2019 11:32:02 -0700 (PDT) Received: from stubbs.int.chopps.org (172-222-100-236.res.spectrum.com [172.222.100.236]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 77255600E7; Sun, 27 Oct 2019 18:32:01 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Christian Hopps In-Reply-To: <23988.25468.681313.594115@fireball.acr.fi> Date: Sun, 27 Oct 2019 14:32:00 -0400 Cc: Christian Hopps , Tero Kivinen Content-Transfer-Encoding: quoted-printable Message-Id: <2115F4B0-216F-4593-8F4C-D768D0497DFC@chopps.org> References: <23988.25468.681313.594115@fireball.acr.fi> To: "ipsec@ietf.org WG" X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2019 18:32:04 -0000 As author, I know of no IPR that applies to this draft, and support its = adoption by the WG. Thanks, Chris. > On Oct 26, 2019, at 11:17 AM, Tero Kivinen wrote: >=20 > So this is fast (one week) adoption call for the > draft-hopps-ipsecme-iptfs draft to be accepted to the WG document. We > did have quite positive feedback in last IETF meeting and the charter > item is being worked on in parallel to this call. >=20 > If you support adopting this document as WG document and as a starting > place for the charter item proposed for the WG, then send email > indicating your support to the ipsec@ietf.org mailing-list. If you > have any comments or reservations send them to list too. >=20 > This adoption call finishes at 2019-11-04. >=20 > ---------------------------------------------------------------------- > The demand for Traffic Flow Confidentiality has been increasing in the = user > community; however, the current method defined in RFC4303 (i.e., add = null > padding to each ESP payload) is very inefficient in it's use of = network > resources. The working group will develop an alternative TFC solution = that > provides for efficient use of network resources. > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 From nobody Mon Oct 28 07:30:32 2019 Return-Path: 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 792A712011C for ; Mon, 28 Oct 2019 07:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 NgYknvLs1Lfa for ; Mon, 28 Oct 2019 07:30:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF81412006E for ; Mon, 28 Oct 2019 07:30:29 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E2DC03897A for ; Mon, 28 Oct 2019 10:27:46 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8B6D93BF0 for ; Mon, 28 Oct 2019 10:30:28 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: <23988.25468.681313.594115@fireball.acr.fi> References: <23988.25468.681313.594115@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 14:30:31 -0000 --=-=-= Content-Type: text/plain I have read the document in a few iterations. I think that it addresses an important need both for resistance to traffic analysis, but also it has the potential to deal with the PMTU problems that tunnels always seem to create. Please adopt! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl22+4QACgkQgItw+93Q 3WUUpgf/foUFynIMxnL28aQXRq+GTZ9zBnfIcxuPb4H1IRR6Cxg9HTYDJmzS2wk7 hAvYxRdJ2X1NvK3Ki8kS/tgCRfVtT39RlmKEyNbp1Oezw1KJoXUeONlCMtimKznH 73POL24QNToyaZN8TQGtC+yW/QN6xdcQtGyJafNNYWWq9qn1xMdCCGd4/VQQ7/kI 4jryv4eLSxk+rd9OMwFfoh6ai29f1MNhEnWR14ZR7BVeiYJaJko8MNIjVA6vTHua K574bAfzSpOwHnQcX0jVn8Uo5Jju/bMYwG5B8EyvNifes/Vjl2EwMK0/fW2bZTer jjbTfIYF7asjA3QMtg1L4GCsj4cQDQ== =KZbC -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 28 09:44:38 2019 Return-Path: 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 4DC6F1200B4 for ; Mon, 28 Oct 2019 09:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 zmE09q2suEQ0 for ; Mon, 28 Oct 2019 09:44:35 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263A3120098 for ; Mon, 28 Oct 2019 09:44:35 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x9SGVNOt042783; Mon, 28 Oct 2019 09:44:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=ZHLhz+j879dnuxbxSP22rc+7ZRNFcRQkkbxfj4SxUuk=; b=r9EwABQwiFG8OLN4nnpfv9ABbydvBAc54nTGyd4q5iGe2hHPYTGuFJV1Z3qRWBsqDhVA 5G0V6xM6IxR18OLyi/nIOVerXvDSygnsO0H2O5rbodMLZ7wdoOf6ySgGpQcXblC7LiAu eTel+Fpltx6KrZhB3KheB2ecnGUpy0fXNlec3gG4v6Z6gQMw+/sU39wbrCJFsTFaYsA9 6BMUkXmTBvVaEhseFxMtz81zgz56qHedlatSwHjwTLhbosibjE2SOojbRCmW8ffIjk4R AWSNH1F6E2igpncxQmkRJotX1y8CXLcH6QXWUbEwKIFlXd3LwcR7H0MVBYDONf/fhGW8 6w== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2vvjttthb6-19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 28 Oct 2019 09:44:33 -0700 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q0300GQDFU6Y370@ma1-mtap-s02.corp.apple.com>; Mon, 28 Oct 2019 09:44:30 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q0300G00FS25Y00@nwk-mmpp-sz11.apple.com>; Mon, 28 Oct 2019 09:44:30 -0700 (PDT) X-Va-A: X-Va-T-CD: 7b7c4a48706c56c09df429cd423b7c05 X-Va-E-CD: 87da3a9bbaa3527eb114afd29701fe95 X-Va-R-CD: f45a1599ad82be1ed75eba480cd9a2d0 X-Va-CD: 0 X-Va-ID: 8908570f-df50-4e60-8219-1ce644056c1c X-V-A: X-V-T-CD: 7b7c4a48706c56c09df429cd423b7c05 X-V-E-CD: 87da3a9bbaa3527eb114afd29701fe95 X-V-R-CD: f45a1599ad82be1ed75eba480cd9a2d0 X-V-CD: 0 X-V-ID: d4cbc3cc-6a1a-4d14-a07b-0778890f61aa X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-28_06:,, signatures=0 Received: from [17.192.171.228] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q0300BRBFU67B20@nwk-mmpp-sz11.apple.com>; Mon, 28 Oct 2019 09:44:30 -0700 (PDT) Sender: tpauly@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) From: Tommy Pauly In-reply-to: <23988.25468.681313.594115@fireball.acr.fi> Date: Mon, 28 Oct 2019 09:44:18 -0700 Cc: ipsec@ietf.org Content-transfer-encoding: quoted-printable Message-id: <175DBE4C-550F-4E5A-8594-8438CB37C25E@apple.com> References: <23988.25468.681313.594115@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-28_06:, , signatures=0 Archived-At: Subject: Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 16:44:37 -0000 I've read the document and think this is good problem area to work on, = and this document is a good starting place to adopt. Going forward, I would like to see more discussion and review of the use = IP fragmentation (how often is that really needed, and is it worth the = concerns stated in = https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17), as well = as the use of Congestion Control (considerations for how having multiple = layers of CC works, and if we can make sure that the format of the = payload is aligned with current work in QUIC, etc). Thanks, Tommy > On Oct 26, 2019, at 8:17 AM, Tero Kivinen wrote: >=20 > So this is fast (one week) adoption call for the > draft-hopps-ipsecme-iptfs draft to be accepted to the WG document. We > did have quite positive feedback in last IETF meeting and the charter > item is being worked on in parallel to this call. >=20 > If you support adopting this document as WG document and as a starting > place for the charter item proposed for the WG, then send email > indicating your support to the ipsec@ietf.org mailing-list. If you > have any comments or reservations send them to list too. >=20 > This adoption call finishes at 2019-11-04. >=20 > ---------------------------------------------------------------------- > The demand for Traffic Flow Confidentiality has been increasing in the = user > community; however, the current method defined in RFC4303 (i.e., add = null > padding to each ESP payload) is very inefficient in it's use of = network > resources. The working group will develop an alternative TFC solution = that > provides for efficient use of network resources. > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Oct 28 11:56:20 2019 Return-Path: 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 5D08B120904 for ; Mon, 28 Oct 2019 11:56:10 -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_HELO_NONE=0.001, SPF_PASS=-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 nUyS-1vBlc1z for ; Mon, 28 Oct 2019 11:56:08 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 55E361208FB for ; Mon, 28 Oct 2019 11:56:08 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id 6so330902wmf.0 for ; Mon, 28 Oct 2019 11:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z5nh16PlSurD2p1ViViijOPaLAGSxNYqCXtbKGXH9oU=; b=OogLSWsXBXZRm485WxH/3+124WRZP9K3AJXNqwSD/LVSf9/rzmgeOGmKW8MovSv3xw aGGFZ+fGRo6nD+pUNk0b5cQeD/hGFEEZ/k6MUxb79EYasvVL8A30WNB0W9TeILieLuTB 1blWJc1LKL3ElOXFm0z4QZAMe7WB2CuH2ODCXqcUE+0lkjFqo1ApEUU+iNH4wHqOm0XM 8GeAQ7YBhrwvOaHW1Uq3Obv6Q8iD4gb0+vYoU/5KQSRastYY4RRHJ0h6wdOmBOdAe8Wd iYC/gPNsSQl0Z0tjjDzsmDwkvq5h8Avh4I/8R0OCtZJxQeA3fpVaBgNRqB01H1yjaLos 5n4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z5nh16PlSurD2p1ViViijOPaLAGSxNYqCXtbKGXH9oU=; b=mUh02Z0iaq35oUgHI5fiMnVanjnYhuG0Cf+IN+LoK+X9hdr1egiTiNLmfrD+IoQMkQ CV+5MTge5GBAJcvyZ7j+vK0pn0ppL62Val5k8A7IQu0XoNDGwmuljwbMYbHD4w4B/e/u c5iU9FfHUMKrcOGzLmFej+SH1pVoz8JEWDvavyQBe91OleB1kXvqxj+yK87D1bxRF6Md sisp6TeqGP+C3fI1YjhW5Mt8nG1g3YmiIPircNQhS8ZaDHO1Oojo08RJjsYQOkDneGHJ q7w189Cug1t+tnCINx5jcUtSJrJggqpmrc3jfZRufZwwXce+KX5+njWMnBYK30L3iwLU ckDQ== X-Gm-Message-State: APjAAAUGl/y5N7vMOZo/vSH73WDH3ElwSICkCbutA1MFNK1CnGIsapGM i80a3O+j/bGRZrQJGGFPmd8= X-Google-Smtp-Source: APXvYqwdGcZORY21aPgMFzFtEjsUCU4vzr0L/jQXUyRXHoILR/3WIq3h0WeoPJsbip6bxS7er5NcdQ== X-Received: by 2002:a1c:8055:: with SMTP id b82mr704048wmd.176.1572288966864; Mon, 28 Oct 2019 11:56:06 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 126sm425359wma.48.2019.10.28.11.56.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Oct 2019 11:56:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Yoav Nir In-Reply-To: <23988.25468.681313.594115@fireball.acr.fi> Date: Mon, 28 Oct 2019 20:56:02 +0200 Cc: ipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0E43F185-CB3B-4751-96C6-D3C311507AA5@gmail.com> References: <23988.25468.681313.594115@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 18:56:18 -0000 I have read the -01 version of this draft. I believe it addresses a = useful use case and that the solution presented there is a good starting = point. I support its adoption. Yoav > On 26 Oct 2019, at 18:17, Tero Kivinen wrote: >=20 > So this is fast (one week) adoption call for the > draft-hopps-ipsecme-iptfs draft to be accepted to the WG document. We > did have quite positive feedback in last IETF meeting and the charter > item is being worked on in parallel to this call. >=20 > If you support adopting this document as WG document and as a starting > place for the charter item proposed for the WG, then send email > indicating your support to the ipsec@ietf.org mailing-list. If you > have any comments or reservations send them to list too. >=20 > This adoption call finishes at 2019-11-04. >=20 > ---------------------------------------------------------------------- > The demand for Traffic Flow Confidentiality has been increasing in the = user > community; however, the current method defined in RFC4303 (i.e., add = null > padding to each ESP payload) is very inefficient in it's use of = network > resources. The working group will develop an alternative TFC solution = that > provides for efficient use of network resources. > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Oct 29 16:12:02 2019 Return-Path: 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 881E8120132 for ; Tue, 29 Oct 2019 16:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 l_a_GxGM1N2z for ; Tue, 29 Oct 2019 16:11:58 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D559120119 for ; Tue, 29 Oct 2019 16:11:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 472nQz2lDCzFck; Wed, 30 Oct 2019 00:11:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1572390715; bh=r5UMJQaHQRme3CTsCx7YfMwWctpVYd7vfCn8vX+pMUE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ggtlcpLRcwmZgoyTkune6tp2TiIlLOUK7c1D7V+TAHhr7aSH1A//KJBpwLD0pz3Vf bT3wR8YBc7UM12COYbJbGDumilm3P2CyRhS7fgPh6uwP5YZt3hJANKOW7qnI2YauTt j6Cc1UMAPOs2PQThG2kPKrDAq5Iw6/evyMCTtbx4= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 4pO0Xpy6iYQT; Wed, 30 Oct 2019 00:11:53 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 30 Oct 2019 00:11:53 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 2DD60606AA31; Tue, 29 Oct 2019 19:11:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2A25F65E69; Tue, 29 Oct 2019 19:11:52 -0400 (EDT) Date: Tue, 29 Oct 2019 19:11:52 -0400 (EDT) From: Paul Wouters To: Tero Kivinen cc: ipsec@ietf.org In-Reply-To: <23988.25468.681313.594115@fireball.acr.fi> Message-ID: References: <23988.25468.681313.594115@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 23:12:00 -0000 On Sat, 26 Oct 2019, Tero Kivinen wrote: > So this is fast (one week) adoption call for the > draft-hopps-ipsecme-iptfs draft to be accepted to the WG document. We > did have quite positive feedback in last IETF meeting and the charter > item is being worked on in parallel to this call. I'm in favour of adopting this document to work on in the WG. I'm very nervous about the current document's requirement of a new IP protocol number, and would hope the WG can find a way to avoid that. Paul From nobody Thu Oct 31 13:51:24 2019 Return-Path: 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 5F4681209FA for ; Thu, 31 Oct 2019 13:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 hSH7Xn4vMaJp for ; Thu, 31 Oct 2019 13:51:17 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5B63120A01 for ; Thu, 31 Oct 2019 13:51:16 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x9VKpENw020359 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 31 Oct 2019 22:51:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x9VKpEEO026821; Thu, 31 Oct 2019 22:51:14 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23995.18754.697585.815824@fireball.acr.fi> Date: Thu, 31 Oct 2019 22:51:14 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min Archived-At: Subject: [IPsec] Agenda for IPsecME WG in IETF 106 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2019 20:51:23 -0000 If you have some agenda slots or presentations you want to make in the IETF 106 IPsecME WG meeting in Singapore send email to ipsecme-chairs@ietf.org to request a slot. -- kivinen@iki.fi