Re: [IPsec] Benjamin Kaduk's Discuss on draft-ietf-ipsecme-implicit-iv-07: (with DISCUSS and COMMENT)

Daniel Migault <daniel.migault@ericsson.com> Tue, 15 October 2019 17:52 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 <daniel.migault@ericsson.com>
Date: Tue, 15 Oct 2019 13:52:19 -0400
Message-ID: <CADZyTkn6ukSG=CTLhGx8BVn=qGgPQG9mT1BTPea9Z5O10EGR4g@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, IPsecME WG <ipsec@ietf.org>, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen <kivinen@iki.fi>
Content-Type: multipart/alternative; boundary="000000000000f0b7dc0594f6a505"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/4fXiGVfncZQ9QR13zucgXtqCvMg>
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 <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Oct 2019 17:52:41 -0000

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
>