From nobody Fri Oct 1 08:15:35 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CA13A0C25; Fri, 1 Oct 2021 08:15:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: Cc: draft-ietf-netconf-notification-capabilities.all@ietf.org, last-call@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163310133388.21527.3735122449294464093@ietfa.amsl.com> Reply-To: Barry Leiba Date: Fri, 01 Oct 2021 08:15:33 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-netconf-notification-capabilities-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2021 15:15:34 -0000 Reviewer: Barry Leiba Review result: Has Nits Well written and easy to read; thanks. I only have some very minor editorial suggestions that I ask you to consider: — Section 1 — Many such capabilities are specific to either the complete system, individual YANG datastores [RFC8342], specific parts of the YANG schema, or even individual data nodes. Nit: “either” is correctly used for two items (“either A or B”). For the four items here, you might just eliminate the word “either”, as it’s not really needed. A NMS implementation that wants to support notifications, needs the information about a system's capability to send "on-change" notifications. I often find that I have to read this sort of thing (“A needs B to do C”) twice to determine whether you mean that A requires that B do C, or that A needs B so that A can do C — it’s ambiguous, so it requires extra analysis by the reader. I suggest the following (which also eliminates the personification of NMS): NEW An NMS implementation that supports notifications needs the information about a system's capability so it can send "on-change" notifications. END — Section 2 — This allows a user to discover capabilities both at implementation-time and run-time. Nit: The “at” is factored wrong with respect to “both”. Either “both at implementation time and at run time” or “at both implementation time and run time”. In either case, no hyphens here, as they’re not compound modifiers. The file MUST be available already at implementation-time retrievable in a way that does not depend on a live network node. Nit: No hyphen (again, not a modifier), and it needs a comma after it: “implementation time,” For the run-time use-case Nit: Here, “run-time” is a modifier and needs the hyphen, but “use case” is a noun and does not. (implementing the publisher) during run-time. Implementations that support changing these capabilities at run-time SHOULD Nit: No hyphens in “run time” for these two (nouns, not modifiers). — Section 3 — A specific case is the need to specify capabilities is the YANG-Push functionality. I’m not sure of the right fix for this, but the two instances of “is” can’t both be right. Maybe the first should be “of”? As defined in [RFC8641] a publisher may allow subscribers to subscribe to updates from a datastore and subsequently push such update notifications to the receiver. It’s unclear who is pushing: it looks like it could be the subscribers. Maybe clarify this way?: NEW As defined in [RFC8641] a publisher may allow subscribers to subscribe to updates from a datastore and will subsequently push such update notifications to the subscriber. END unless the subscriber has some means to identify which objects "on-change" notifications are supported. Missing word: “are supported for.” — Section 4 — It SHOULD be used by other modules to augment-in specific capability information. The term “augment-in” is not one I’m familiar with. If it’s common in YANG, that’s fine. If not, maybe rephrase? data is considered as if it was part of the running datastore. Ultra-nit: “as if it were part”: subjunctive mood is needed after “as if”. From nobody Mon Oct 4 05:29:10 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7A83A1467; Mon, 4 Oct 2021 05:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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 4PkaZFFzLGk6; Mon, 4 Oct 2021 05:28:56 -0700 (PDT) Received: from mail-ua1-f50.google.com (mail-ua1-f50.google.com [209.85.222.50]) (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 320933A1465; Mon, 4 Oct 2021 05:28:53 -0700 (PDT) Received: by mail-ua1-f50.google.com with SMTP id e7so2922004ual.11; Mon, 04 Oct 2021 05:28:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X9RkeSoPP1Qcc3IbiSBqZ/0crx1Jsww0mRvcceYb++Y=; b=pHgkElEqmEBl57TAimBmPXwDqFw9rPjfLWQ979V/4faD9/tLz9mEv4yfwImoKOtS6b V7D1nFt6txjlGbdI05FQyR2FokokM5wK8/Q7/mUk/QwHfeyEIGBx3W957Kzram5xxtEx UeoiyaGsQ98Z+CD+wnJD0aZqOM3JjWokJJ20xppMX85E2k301Fhu5gWvHigOD5p3NhAN vwWaaJMXQrLe6qTx4F+BWYlTRzZmXFNZRWRlpLRCk/HgbYbrwbjTj/Wdm/lfDHfY9Y4t YkzSqIoVmFQyomQ0aKRarKuYsXMt0cP0x+/nLJbs43xFgyXUESWpaZCUmcjuAItaIeaO vrnA== X-Gm-Message-State: AOAM533vHTiDmRO46l/jB8zdBdgbNg3luXu5EvzxmIrjF1AZ4k2uo9v+ tj6gTX6YBv7KIiObERFmx1LT+OaL8MeimIQZ3Y4= X-Google-Smtp-Source: ABdhPJxyaEslB7eRyw0iVkbKoKjrVs2KEl8xpJe9ft/6mO2BbfBpnx+Xbv8dUd1L8CJ4m29AH4GiUQEzQNQ/FeUJTE4= X-Received: by 2002:ab0:21ce:: with SMTP id u14mr6172823uan.74.1633350532153; Mon, 04 Oct 2021 05:28:52 -0700 (PDT) MIME-Version: 1.0 References: <163310133388.21527.3735122449294464093@ietfa.amsl.com> <42ab0032-4994-396e-08cc-3437fcf971a7@huawei.com> In-Reply-To: <42ab0032-4994-396e-08cc-3437fcf971a7@huawei.com> From: Barry Leiba Date: Mon, 4 Oct 2021 08:28:41 -0400 Message-ID: To: Benoit Claise Cc: draft-ietf-netconf-notification-capabilities.all@ietf.org, last-call@ietf.org, netconf@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="0000000000004344e205cd860eba" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-netconf-notification-capabilities-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 12:29:01 -0000 --0000000000004344e205cd860eba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Beno=C3=AEt! Barry On Mon, Oct 4, 2021 at 8:16 AM Benoit Claise wrote: > Hi Barry, > > Thanks for your insightful review. > All remarks improve (the reading of) the specifications. > See inline for some some specific remarks. > > On 10/1/2021 5:15 PM, Barry Leiba via Datatracker wrote: > > Reviewer: Barry Leiba > > Review result: Has Nits > > > > Well written and easy to read; thanks. I only have some very minor > editorial > > suggestions that I ask you to consider: > > > > =E2=80=94 Section 1 =E2=80=94 > > > > Many such capabilities are > > specific to either the complete system, individual YANG datastores > > [RFC8342], specific parts of the YANG schema, or even individual da= ta > > nodes. > > > > Nit: =E2=80=9Ceither=E2=80=9D is correctly used for two items (=E2=80= =9Ceither A or B=E2=80=9D). For > the four > > items here, you might just eliminate the word =E2=80=9Ceither=E2=80=9D,= as it=E2=80=99s not > really > > needed. > > > > A NMS implementation that wants to > > support notifications, needs the information about a system's > > capability to send "on-change" notifications. > > > > I often find that I have to read this sort of thing (=E2=80=9CA needs B= to do > C=E2=80=9D) twice > > to determine whether you mean that A requires that B do C, or that A > needs B so > > that A can do C =E2=80=94 it=E2=80=99s ambiguous, so it requires extra = analysis by the > reader. > > I suggest the following (which also eliminates the personification of > NMS): > > > > NEW > > An NMS implementation that supports > > notifications needs the information about a system's > > capability so it can send "on-change" notifications. > > END > > > > =E2=80=94 Section 2 =E2=80=94 > > > > This allows a user to > > discover capabilities both at implementation-time and run-time. > > > > Nit: The =E2=80=9Cat=E2=80=9D is factored wrong with respect to =E2=80= =9Cboth=E2=80=9D. Either =E2=80=9Cboth at > > implementation time and at run time=E2=80=9D or =E2=80=9Cat both implem= entation time and > run > > time=E2=80=9D. In either case, no hyphens here, as they=E2=80=99re not= compound > modifiers. > > > > The file MUST be > > available already at implementation-time retrievable in a way th= at > > does not depend on a live network node. > > > > Nit: No hyphen (again, not a modifier), and it needs a comma after it: > > =E2=80=9Cimplementation time,=E2=80=9D > > > > For the run-time use-case > > > > Nit: Here, =E2=80=9Crun-time=E2=80=9D is a modifier and needs the hyphe= n, but =E2=80=9Cuse case=E2=80=9D > is a > > noun and does not. > > > > (implementing the publisher) during run-time. Implementations > > that support changing these capabilities at run-time SHOULD > > > > Nit: No hyphens in =E2=80=9Crun time=E2=80=9D for these two (nouns, not= modifiers). > > > > =E2=80=94 Section 3 =E2=80=94 > > > > A specific case is the need to specify capabilities is the YANG-Pus= h > > functionality. > > > > I=E2=80=99m not sure of the right fix for this, but the two instances o= f =E2=80=9Cis=E2=80=9D > can=E2=80=99t > > both be right. Maybe the first should be =E2=80=9Cof=E2=80=9D? > > A specific case is the need to specify capabilities in the YANG-Push > functionality. > > > > > As defined in [RFC8641] a publisher may allow > > subscribers to subscribe to updates from a datastore and subsequent= ly > > push such update notifications to the receiver. > > > > It=E2=80=99s unclear who is pushing: it looks like it could be the subs= cribers. > Maybe > > clarify this way?: > > > > NEW > > As defined in [RFC8641] a publisher may allow > > subscribers to subscribe to updates from a datastore and will > > subsequently push such update notifications to the subscriber. > > END > Yes to the above. > > > > unless the subscriber has some means to > > identify which objects "on-change" notifications are supported. > > > > Missing word: =E2=80=9Care supported for.=E2=80=9D > > > > =E2=80=94 Section 4 =E2=80=94 > > > > It SHOULD be used by other modules to augment-in specific > > capability information. > > > > The term =E2=80=9Caugment-in=E2=80=9D is not one I=E2=80=99m familiar w= ith. If it=E2=80=99s common in > YANG, > > that=E2=80=99s fine. If not, maybe rephrase? > > It SHOULD be used by other modules to augment in specific > capability information. > > > > > > data is considered as if it was part > > of the running datastore. > > > > Ultra-nit: =E2=80=9Cas if it were part=E2=80=9D: subjunctive mood is ne= eded after =E2=80=9Cas > if=E2=80=9D. > > > > > > . > Thanks again. > > Regards, Benoit > --0000000000004344e205cd860eba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Beno=C3=AEt!

Barry

On Mon, Oct 4, 2021 at 8:16 AM Benoit Claise <<= a href=3D"mailto:benoit.claise@huawei.com">benoit.claise@huawei.com>= wrote:
Hi Barry,

Thanks for your insightful review.
All remarks improve (the reading of) the specifications.
See inline for some some specific remarks.

On 10/1/2021 5:15 PM, Barry Leiba via Datatracker wrote:
> Reviewer: Barry Leiba
> Review result: Has Nits
>
> Well written and easy to read; thanks.=C2=A0 I only have some very min= or editorial
> suggestions that I ask you to consider:
>
> =E2=80=94 Section 1 =E2=80=94
>
>=C2=A0 =C2=A0 =C2=A0Many such capabilities are
>=C2=A0 =C2=A0 =C2=A0specific to either the complete system, individual = YANG datastores
>=C2=A0 =C2=A0 =C2=A0[RFC8342], specific parts of the YANG schema, or ev= en individual data
>=C2=A0 =C2=A0 =C2=A0nodes.
>
> Nit: =E2=80=9Ceither=E2=80=9D is correctly used for two items (=E2=80= =9Ceither A or B=E2=80=9D).=C2=A0 For the four
> items here, you might just eliminate the word =E2=80=9Ceither=E2=80=9D= , as it=E2=80=99s not really
> needed.
>
>=C2=A0 =C2=A0 =C2=A0A NMS implementation that wants to
>=C2=A0 =C2=A0 =C2=A0support notifications, needs the information about = a system's
>=C2=A0 =C2=A0 =C2=A0capability to send "on-change" notificati= ons.
>
> I often find that I have to read this sort of thing (=E2=80=9CA needs = B to do C=E2=80=9D) twice
> to determine whether you mean that A requires that B do C, or that A n= eeds B so
> that A can do C =E2=80=94 it=E2=80=99s ambiguous, so it requires extra= analysis by the reader.
> I suggest the following (which also eliminates the personification of = NMS):
>
> NEW
>=C2=A0 =C2=A0 =C2=A0An NMS implementation that supports
>=C2=A0 =C2=A0 =C2=A0notifications needs the information about a system&= #39;s
>=C2=A0 =C2=A0 =C2=A0capability so it can send "on-change" not= ifications.
> END
>
> =E2=80=94 Section 2 =E2=80=94
>
>=C2=A0 =C2=A0 =C2=A0This allows a user to
>=C2=A0 =C2=A0 =C2=A0discover capabilities both at implementation-time a= nd run-time.
>
> Nit: The =E2=80=9Cat=E2=80=9D is factored wrong with respect to =E2=80= =9Cboth=E2=80=9D. Either =E2=80=9Cboth at
> implementation time and at run time=E2=80=9D or =E2=80=9Cat both imple= mentation time and run
> time=E2=80=9D.=C2=A0 In either case, no hyphens here, as they=E2=80=99= re not compound modifiers.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 The file MUST be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 available already at implementation-time re= trievable in a way that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 does not depend on a live network node.
>
> Nit: No hyphen (again, not a modifier), and it needs a comma after it:=
> =E2=80=9Cimplementation time,=E2=80=9D
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 For the run-time use-case
>
> Nit: Here, =E2=80=9Crun-time=E2=80=9D is a modifier and needs the hyph= en, but =E2=80=9Cuse case=E2=80=9D is a
> noun and does not.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (implementing the publisher) during run-tim= e.=C2=A0 Implementations
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 that support changing these capabilities at= run-time SHOULD
>
> Nit: No hyphens in =E2=80=9Crun time=E2=80=9D for these two (nouns, no= t modifiers).
>
> =E2=80=94 Section 3 =E2=80=94
>
>=C2=A0 =C2=A0 =C2=A0A specific case is the need to specify capabilities= is the YANG-Push
>=C2=A0 =C2=A0 =C2=A0functionality.
>
> I=E2=80=99m not sure of the right fix for this, but the two instances = of =E2=80=9Cis=E2=80=9D can=E2=80=99t
> both be right.=C2=A0 Maybe the first should be =E2=80=9Cof=E2=80=9D?
A specific case is the need to specify capabilities in the YANG-Push
=C2=A0 =C2=A0 functionality.

>
>=C2=A0 =C2=A0 =C2=A0As defined in [RFC8641] a publisher may allow
>=C2=A0 =C2=A0 =C2=A0subscribers to subscribe to updates from a datastor= e and subsequently
>=C2=A0 =C2=A0 =C2=A0push such update notifications to the receiver.
>
> It=E2=80=99s unclear who is pushing: it looks like it could be the sub= scribers.=C2=A0 Maybe
> clarify this way?:
>
> NEW
>=C2=A0 =C2=A0 =C2=A0As defined in [RFC8641] a publisher may allow
>=C2=A0 =C2=A0 =C2=A0subscribers to subscribe to updates from a datastor= e and will
>=C2=A0 =C2=A0 =C2=A0subsequently push such update notifications to the = subscriber.
> END
Yes to the above.
>
>=C2=A0 =C2=A0 =C2=A0unless the subscriber has some means to
>=C2=A0 =C2=A0 =C2=A0identify which objects "on-change" notifi= cations are supported.
>
> Missing word: =E2=80=9Care supported for.=E2=80=9D
>
> =E2=80=94 Section 4 =E2=80=94
>
>=C2=A0 =C2=A0 =C2=A0It SHOULD be used by other modules to augment-in sp= ecific
>=C2=A0 =C2=A0 =C2=A0capability information.
>
> The term =E2=80=9Caugment-in=E2=80=9D is not one I=E2=80=99m familiar = with.=C2=A0 If it=E2=80=99s common in YANG,
> that=E2=80=99s fine.=C2=A0 If not, maybe rephrase?

=C2=A0 =C2=A0 It SHOULD be used by other modules to augment in specific
=C2=A0 =C2=A0 capability information.


>
>=C2=A0 =C2=A0 =C2=A0data is considered as if it was part
>=C2=A0 =C2=A0 =C2=A0of the running datastore.
>
> Ultra-nit: =E2=80=9Cas if it were part=E2=80=9D: subjunctive mood is n= eeded after =E2=80=9Cas if=E2=80=9D.
>
>
> .
Thanks again.

Regards, Benoit
--0000000000004344e205cd860eba-- From nobody Tue Oct 5 08:09:16 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AD63A14FD; Mon, 4 Oct 2021 05:16:43 -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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 WgfqfO0LaBdv; Mon, 4 Oct 2021 05:16:39 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354913A14A3; Mon, 4 Oct 2021 05:16:35 -0700 (PDT) Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HNKPn3z3pz67hkD; Mon, 4 Oct 2021 20:13:49 +0800 (CST) Received: from [10.47.79.104] (10.47.79.104) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Mon, 4 Oct 2021 14:16:28 +0200 To: Barry Leiba , CC: , , References: <163310133388.21527.3735122449294464093@ietfa.amsl.com> From: Benoit Claise Message-ID: <42ab0032-4994-396e-08cc-3437fcf971a7@huawei.com> Date: Mon, 4 Oct 2021 14:15:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <163310133388.21527.3735122449294464093@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [10.47.79.104] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To fraeml736-chm.china.huawei.com (10.206.15.217) X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Tue, 05 Oct 2021 08:09:14 -0700 Subject: Re: [secdir] Secdir last call review of draft-ietf-netconf-notification-capabilities-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 12:16:48 -0000 Hi Barry, Thanks for your insightful review. All remarks improve (the reading of) the specifications. See inline for some some specific remarks. On 10/1/2021 5:15 PM, Barry Leiba via Datatracker wrote: > Reviewer: Barry Leiba > Review result: Has Nits > > Well written and easy to read; thanks. I only have some very minor editorial > suggestions that I ask you to consider: > > — Section 1 — > > Many such capabilities are > specific to either the complete system, individual YANG datastores > [RFC8342], specific parts of the YANG schema, or even individual data > nodes. > > Nit: “either” is correctly used for two items (“either A or B”). For the four > items here, you might just eliminate the word “either”, as it’s not really > needed. > > A NMS implementation that wants to > support notifications, needs the information about a system's > capability to send "on-change" notifications. > > I often find that I have to read this sort of thing (“A needs B to do C”) twice > to determine whether you mean that A requires that B do C, or that A needs B so > that A can do C — it’s ambiguous, so it requires extra analysis by the reader. > I suggest the following (which also eliminates the personification of NMS): > > NEW > An NMS implementation that supports > notifications needs the information about a system's > capability so it can send "on-change" notifications. > END > > — Section 2 — > > This allows a user to > discover capabilities both at implementation-time and run-time. > > Nit: The “at” is factored wrong with respect to “both”. Either “both at > implementation time and at run time” or “at both implementation time and run > time”. In either case, no hyphens here, as they’re not compound modifiers. > > The file MUST be > available already at implementation-time retrievable in a way that > does not depend on a live network node. > > Nit: No hyphen (again, not a modifier), and it needs a comma after it: > “implementation time,” > > For the run-time use-case > > Nit: Here, “run-time” is a modifier and needs the hyphen, but “use case” is a > noun and does not. > > (implementing the publisher) during run-time. Implementations > that support changing these capabilities at run-time SHOULD > > Nit: No hyphens in “run time” for these two (nouns, not modifiers). > > — Section 3 — > > A specific case is the need to specify capabilities is the YANG-Push > functionality. > > I’m not sure of the right fix for this, but the two instances of “is” can’t > both be right. Maybe the first should be “of”? A specific case is the need to specify capabilities in the YANG-Push functionality. > > As defined in [RFC8641] a publisher may allow > subscribers to subscribe to updates from a datastore and subsequently > push such update notifications to the receiver. > > It’s unclear who is pushing: it looks like it could be the subscribers. Maybe > clarify this way?: > > NEW > As defined in [RFC8641] a publisher may allow > subscribers to subscribe to updates from a datastore and will > subsequently push such update notifications to the subscriber. > END Yes to the above. > > unless the subscriber has some means to > identify which objects "on-change" notifications are supported. > > Missing word: “are supported for.” > > — Section 4 — > > It SHOULD be used by other modules to augment-in specific > capability information. > > The term “augment-in” is not one I’m familiar with. If it’s common in YANG, > that’s fine. If not, maybe rephrase? It SHOULD be used by other modules to augment in specific capability information. > > data is considered as if it was part > of the running datastore. > > Ultra-nit: “as if it were part”: subjunctive mood is needed after “as if”. > > > . Thanks again. Regards, Benoit From nobody Tue Oct 5 08:09:55 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2693A097B; Mon, 4 Oct 2021 09:19:21 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 fvNMoo1KC0QW; Mon, 4 Oct 2021 09:19:16 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFDCE3A0976; Mon, 4 Oct 2021 09:19:15 -0700 (PDT) Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HNQnL64J9z67Pf9; Tue, 5 Oct 2021 00:16:06 +0800 (CST) Received: from [10.47.64.144] (10.47.64.144) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Mon, 4 Oct 2021 18:19:08 +0200 To: Barry Leiba CC: , , , References: <163310133388.21527.3735122449294464093@ietfa.amsl.com> <42ab0032-4994-396e-08cc-3437fcf971a7@huawei.com> From: Benoit Claise Message-ID: <21c39f1f-9cc4-4d86-85ae-56fbd1425826@huawei.com> Date: Mon, 4 Oct 2021 18:18:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DD0102712A823FEA17433938" Content-Language: en-GB X-Originating-IP: [10.47.64.144] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To fraeml736-chm.china.huawei.com (10.206.15.217) X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Tue, 05 Oct 2021 08:09:14 -0700 Subject: Re: [secdir] Secdir last call review of draft-ietf-netconf-notification-capabilities-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 16:19:22 -0000 --------------DD0102712A823FEA17433938 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Barry, all, In order to help the IESG with the telechat review for this coming Thursday, I posted version v18 https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/ Thanks, Benoit On 10/4/2021 2:28 PM, Barry Leiba wrote: > Thanks, Benoît! > > Barry > > On Mon, Oct 4, 2021 at 8:16 AM Benoit Claise > wrote: > > Hi Barry, > > Thanks for your insightful review. > All remarks improve (the reading of) the specifications. > See inline for some some specific remarks. > > On 10/1/2021 5:15 PM, Barry Leiba via Datatracker wrote: > > Reviewer: Barry Leiba > > Review result: Has Nits > > > > Well written and easy to read; thanks.  I only have some very > minor editorial > > suggestions that I ask you to consider: > > > > — Section 1 — > > > >     Many such capabilities are > >     specific to either the complete system, individual YANG > datastores > >     [RFC8342], specific parts of the YANG schema, or even > individual data > >     nodes. > > > > Nit: “either” is correctly used for two items (“either A or > B”).  For the four > > items here, you might just eliminate the word “either”, as it’s > not really > > needed. > > > >     A NMS implementation that wants to > >     support notifications, needs the information about a system's > >     capability to send "on-change" notifications. > > > > I often find that I have to read this sort of thing (“A needs B > to do C”) twice > > to determine whether you mean that A requires that B do C, or > that A needs B so > > that A can do C — it’s ambiguous, so it requires extra analysis > by the reader. > > I suggest the following (which also eliminates the > personification of NMS): > > > > NEW > >     An NMS implementation that supports > >     notifications needs the information about a system's > >     capability so it can send "on-change" notifications. > > END > > > > — Section 2 — > > > >     This allows a user to > >     discover capabilities both at implementation-time and run-time. > > > > Nit: The “at” is factored wrong with respect to “both”. Either > “both at > > implementation time and at run time” or “at both implementation > time and run > > time”.  In either case, no hyphens here, as they’re not compound > modifiers. > > > >        The file MUST be > >        available already at implementation-time retrievable in a > way that > >        does not depend on a live network node. > > > > Nit: No hyphen (again, not a modifier), and it needs a comma > after it: > > “implementation time,” > > > >        For the run-time use-case > > > > Nit: Here, “run-time” is a modifier and needs the hyphen, but > “use case” is a > > noun and does not. > > > >        (implementing the publisher) during run-time. Implementations > >        that support changing these capabilities at run-time SHOULD > > > > Nit: No hyphens in “run time” for these two (nouns, not modifiers). > > > > — Section 3 — > > > >     A specific case is the need to specify capabilities is the > YANG-Push > >     functionality. > > > > I’m not sure of the right fix for this, but the two instances of > “is” can’t > > both be right.  Maybe the first should be “of”? > > A specific case is the need to specify capabilities in the YANG-Push >     functionality. > > > > >     As defined in [RFC8641] a publisher may allow > >     subscribers to subscribe to updates from a datastore and > subsequently > >     push such update notifications to the receiver. > > > > It’s unclear who is pushing: it looks like it could be the > subscribers.  Maybe > > clarify this way?: > > > > NEW > >     As defined in [RFC8641] a publisher may allow > >     subscribers to subscribe to updates from a datastore and will > >     subsequently push such update notifications to the subscriber. > > END > Yes to the above. > > > >     unless the subscriber has some means to > >     identify which objects "on-change" notifications are supported. > > > > Missing word: “are supported for.” > > > > — Section 4 — > > > >     It SHOULD be used by other modules to augment-in specific > >     capability information. > > > > The term “augment-in” is not one I’m familiar with.  If it’s > common in YANG, > > that’s fine.  If not, maybe rephrase? > >     It SHOULD be used by other modules to augment in specific >     capability information. > > > > > >     data is considered as if it was part > >     of the running datastore. > > > > Ultra-nit: “as if it were part”: subjunctive mood is needed > after “as if”. > > > > > > . > Thanks again. > > Regards, Benoit > --------------DD0102712A823FEA17433938 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Barry, all,

In order to help the IESG with the telechat review for this coming Thursday, I posted version v18
https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/

Thanks, Benoit
On 10/4/2021 2:28 PM, Barry Leiba wrote:
Thanks, Benoît!

Barry

On Mon, Oct 4, 2021 at 8:16 AM Benoit Claise <benoit.claise@huawei.com> wrote:
Hi Barry,

Thanks for your insightful review.
All remarks improve (the reading of) the specifications.
See inline for some some specific remarks.

On 10/1/2021 5:15 PM, Barry Leiba via Datatracker wrote:
> Reviewer: Barry Leiba
> Review result: Has Nits
>
> Well written and easy to read; thanks.  I only have some very minor editorial
> suggestions that I ask you to consider:
>
> — Section 1 —
>
>     Many such capabilities are
>     specific to either the complete system, individual YANG datastores
>     [RFC8342], specific parts of the YANG schema, or even individual data
>     nodes.
>
> Nit: “either” is correctly used for two items (“either A or B”).  For the four
> items here, you might just eliminate the word “either”, as it’s not really
> needed.
>
>     A NMS implementation that wants to
>     support notifications, needs the information about a system's
>     capability to send "on-change" notifications.
>
> I often find that I have to read this sort of thing (“A needs B to do C”) twice
> to determine whether you mean that A requires that B do C, or that A needs B so
> that A can do C — it’s ambiguous, so it requires extra analysis by the reader.
> I suggest the following (which also eliminates the personification of NMS):
>
> NEW
>     An NMS implementation that supports
>     notifications needs the information about a system's
>     capability so it can send "on-change" notifications.
> END
>
> — Section 2 —
>
>     This allows a user to
>     discover capabilities both at implementation-time and run-time.
>
> Nit: The “at” is factored wrong with respect to “both”. Either “both at
> implementation time and at run time” or “at both implementation time and run
> time”.  In either case, no hyphens here, as they’re not compound modifiers.
>
>        The file MUST be
>        available already at implementation-time retrievable in a way that
>        does not depend on a live network node.
>
> Nit: No hyphen (again, not a modifier), and it needs a comma after it:
> “implementation time,”
>
>        For the run-time use-case
>
> Nit: Here, “run-time” is a modifier and needs the hyphen, but “use case” is a
> noun and does not.
>
>        (implementing the publisher) during run-time.  Implementations
>        that support changing these capabilities at run-time SHOULD
>
> Nit: No hyphens in “run time” for these two (nouns, not modifiers).
>
> — Section 3 —
>
>     A specific case is the need to specify capabilities is the YANG-Push
>     functionality.
>
> I’m not sure of the right fix for this, but the two instances of “is” can’t
> both be right.  Maybe the first should be “of”?

A specific case is the need to specify capabilities in the YANG-Push
    functionality.

>
>     As defined in [RFC8641] a publisher may allow
>     subscribers to subscribe to updates from a datastore and subsequently
>     push such update notifications to the receiver.
>
> It’s unclear who is pushing: it looks like it could be the subscribers.  Maybe
> clarify this way?:
>
> NEW
>     As defined in [RFC8641] a publisher may allow
>     subscribers to subscribe to updates from a datastore and will
>     subsequently push such update notifications to the subscriber.
> END
Yes to the above.
>
>     unless the subscriber has some means to
>     identify which objects "on-change" notifications are supported.
>
> Missing word: “are supported for.”
>
> — Section 4 —
>
>     It SHOULD be used by other modules to augment-in specific
>     capability information.
>
> The term “augment-in” is not one I’m familiar with.  If it’s common in YANG,
> that’s fine.  If not, maybe rephrase?

    It SHOULD be used by other modules to augment in specific
    capability information.


>
>     data is considered as if it was part
>     of the running datastore.
>
> Ultra-nit: “as if it were part”: subjunctive mood is needed after “as if”.
>
>
> .
Thanks again.

Regards, Benoit

--------------DD0102712A823FEA17433938-- From nobody Tue Oct 5 13:07:58 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 827403A0BB0; Tue, 5 Oct 2021 13:07:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Samuel Weiler via Datatracker To: Cc: draft-ietf-trill-multilevel-single-nickname.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163346447545.9898.7820598060509599586@ietfa.amsl.com> Reply-To: Samuel Weiler Date: Tue, 05 Oct 2021 13:07:55 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-trill-multilevel-single-nickname-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2021 20:07:56 -0000 Reviewer: Samuel Weiler Review result: Not Ready I'm not satisfied with the weak anti-spoofing protections of TRILL, but I don't see this making things worse. I have what I hope is a naive question: since this proposes to label level 1 areas by the set of RBs that connect them to the level 2, expanding on Section 6 (One Border RBridge Connects Multiple Areas), what happens when the set of RBs connecting to multiple areas is the same, such that all of those areas would then get the same name, under this scheme? (I'm hoping this works, and I'm just not sorting out the details, but I'm making sure...) From nobody Tue Oct 5 18:34:02 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061413A0FC5; Tue, 5 Oct 2021 18:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 (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 C5u_UNCS6_IV; Tue, 5 Oct 2021 18:33:46 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 1AE323A0FB9; Tue, 5 Oct 2021 18:33:46 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id g2so143375ild.1; Tue, 05 Oct 2021 18:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bQZb+k616R3bLBJpkP8mH5YknSLGvlnRH7C+6hmMfDk=; b=C/5RKX3g8JyrxCGwFEf/RTa7WLw0u+tyUAvHbIiMwMniFJA3KEIPl5j/PYOeMzJyCb oQsL0GZs5+I3w16MjdX1mbffVd62dxyse3+tMpX9o+DZ2XJvrWSKPSKkG1wwjOfTepDq OwGmLXhtEJb3U3vG7uh01hwWAAy1Xv6Ph5bGjX80KakRpm2+zuUCve1xvoF+0uuorF4k ni3EQwVNS2iESUlPELISjP2TYHpuh0wCj1pZm/Q/QjclZnIJPlbubrac73WTLCfRWKoS D+ZZJVGUOQRQMCsetxOBWedSpWMp8+MT8p9+YG7dCF06octDAYRQiXqvUu1x0ilNQQL5 zCpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bQZb+k616R3bLBJpkP8mH5YknSLGvlnRH7C+6hmMfDk=; b=jmr5uMLjrdDBCLqIC2WV7pI0IOH10CG+PHB64MRKlycFXTSfHWG1xSGhHxI0RpF2f3 coMQZGSofb317JrGOwotz9hZgZP+4Amp4N8KkE6kcM2RwQnLj8719VWBlZjVl96KPpqI QrygEvZMEUCkHEDEgdOx9q2XIvCMB1TXQMWxbEmnzVDkVL5N2fE1QkvYh/3xi4VMIAH8 LFceXxccO/AKmfhjwqFY5h53Gqus+T78Db/bSOPROOLXJtEs4abzJYxLbHekeM08dbdu wZAisrW/BCZi8Jd5fGG9KiPY7gw3BJ3lQkJ92FQm3KqDVgCCDZ58+nwiwpnUE/sT0eP5 HOeA== X-Gm-Message-State: AOAM5329DCRaYgavJUNoHSMRMH8SxlXqnJKYiwZneN9rqzim6UOQ5LqZ qf9CtsvlrgkiwfH9YdWXohJN1300e5egu78o7OY2b7YH X-Google-Smtp-Source: ABdhPJxxMRbk7JgWOTKe8B9YhhezYGrjvp0V/HlobIdseegZZsCsP1WR0BBLvDEUZPw9CoTKtho3rai8lZMBtVq8irU= X-Received: by 2002:a05:6e02:1a6d:: with SMTP id w13mr5169321ilv.304.1633484025155; Tue, 05 Oct 2021 18:33:45 -0700 (PDT) MIME-Version: 1.0 References: <163346447545.9898.7820598060509599586@ietfa.amsl.com> In-Reply-To: <163346447545.9898.7820598060509599586@ietfa.amsl.com> From: Donald Eastlake Date: Tue, 5 Oct 2021 21:33:34 -0400 Message-ID: To: Samuel Weiler Cc: secdir , draft-ietf-trill-multilevel-single-nickname.all@ietf.org, Last Call Content-Type: multipart/alternative; boundary="00000000000010d5fe05cda523e9" Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-trill-multilevel-single-nickname-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 01:33:54 -0000 --00000000000010d5fe05cda523e9 Content-Type: text/plain; charset="UTF-8" Hi, See below. On Tue, Oct 5, 2021 at 4:07 PM Samuel Weiler via Datatracker < noreply@ietf.org> wrote: > > Reviewer: Samuel Weiler > Review result: Not Ready > > I'm not satisfied with the weak anti-spoofing protections of TRILL, but I don't > see this making things worse. Can you be more specific? Are you talking about spoofing routing control messages or spoofing data or what? > I have what I hope is a naive question: since this proposes to label level 1 > areas by the set of RBs that connect them to the level 2, expanding on Section > 6 (One Border RBridge Connects Multiple Areas), what happens when the set of > RBs connecting to multiple areas is the same, such that all of those areas > would then get the same name, under this scheme? (I'm hoping this works, and > I'm just not sorting out the details, but I'm making sure...) In the situation you hypothesize, there are three cases generally covered by Section 6 of the draft: - There is no reason to treat outbound traffic to L2 from any of the L1 areas you hypothesize differently from any other, so there is no problem in this case. - On inbound traffic from L2, the MAC and data label have to be looked up to determine the egress RBridge and output port and the output port determines the actual L1 area. - On traffic between L1 areas on an border RBridge, that border RBridge will see itself as the egress nickname in the TRILL packet it receives and do the lookup as in the immediately previous case. I am working on an update to resolve various IESG COMMENTs which should be posted shortly. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com --00000000000010d5fe05cda523e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

See below.

On Tue, Oct 5, 2021 at 4:07 P= M Samuel Weiler via Datatracker <noreply@ietf.org> wrote:
>
> Reviewer: Sa= muel Weiler
> Review result: Not Ready
>
> I'm not sa= tisfied with the weak anti-spoofing protections of TRILL, but I don't> see this making things worse.

Can you be more specific? Are y= ou talking about spoofing routing control messages or spoofing data or what= ?

> I have what I hope is a naive question: since this proposes = to label level 1
> areas by the set of RBs that connect them to the l= evel 2, expanding on Section
> 6 (One Border RBridge Connects Multipl= e Areas), what happens when the set of
> RBs connecting to multiple a= reas is the same, such that all of those areas
> would then get the s= ame name, under this scheme? =C2=A0 (I'm hoping this works, and
>= I'm just not sorting out the details, but I'm making sure...)
=
In the situation you hypothesize, there are three cases gene= rally covered by Section 6 of the draft:
  • There is no reas= on to treat outbound traffic to L2 from any of the L1 areas you hypothesize= differently from any other, so there is no problem in this case.
  • O= n inbound traffic from L2, the MAC and data label have to be looked up to d= etermine the egress RBridge and output port and the output port determines = the actual L1 area.
  • On traffic between L1 areas on an border RBridg= e, that border RBridge will see itself as the egress nickname in the TRILL = packet it receives and do the lookup as in the immediately previous case.
I am working on an update to resolve various IESG COMMEN= Ts which should be posted shortly.

Thanks,
Donald
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cel= l)
=C2=A02386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com
--00000000000010d5fe05cda523e9-- From nobody Thu Oct 7 05:53:59 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 728CE3A101F; Thu, 7 Oct 2021 05:53:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Derek Atkins via Datatracker To: Cc: bess@ietf.org, draft-ietf-bess-evpn-optimized-ir.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163361121039.16337.12285140758441545338@ietfa.amsl.com> Reply-To: Derek Atkins Date: Thu, 07 Oct 2021 05:53:30 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-bess-evpn-optimized-ir-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2021 12:53:33 -0000 Reviewer: Derek Atkins Review result: Ready Hi, 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 with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: * Ready to Publish Details: * It is unclear to me how one would protect from a (D)DoS attack with a forged BM packet sent into the replicator and prevent amplification attacks. -derek From nobody Thu Oct 7 14:58:07 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012F43A08FA for ; Thu, 7 Oct 2021 14:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 yrGuggVke2vK for ; Thu, 7 Oct 2021 14:58:02 -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 DB56B3A0F0C for ; Thu, 7 Oct 2021 14:58:01 -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 197Lvs4u010579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 7 Oct 2021 17:57:59 -0400 Date: Thu, 7 Oct 2021 14:57:53 -0700 From: Benjamin Kaduk To: Melinda Shore Cc: secdir@ietf.org Message-ID: <20211007215753.GQ4103@kduck.mit.edu> References: <162847975484.5697.10348648212211041099@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <162847975484.5697.10348648212211041099@ietfa.amsl.com> Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-regext-epp-registry-maintenance-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2021 21:58:06 -0000 Hi Melinda, Thanks for the review! The confusion about transport security requirements is quite understandable, and we actually ended up having a discussion in the IESG about TLS usage for EPP when the core EPP specs were getting promoted to Internet Standard. I no longer remember the specifics of the discussion, but we did conclude that TLS or equivalent is required, across the whole collection of documents. -Ben On Sun, Aug 08, 2021 at 08:29:14PM -0700, Melinda Shore via Datatracker wrote: > Reviewer: Melinda Shore > Review result: Has Issues > > The security considerations section is scanty - transport security is not > described at all, nor is the question of defense against a malicious actor > spoofing a server. It may be the case that there are, in fact, mitigations in > common use but they are not spelled out in this draft nor in RFC 5730 (and I’ll > be the first to admit that I may have missed something). Because of this I do > have reservations about progressing the document towards publication. > > Section 3.3: Is it the case that if an element is not explicitly identified as > optional, it’s mandatory? If that’s the case you may want to mention that in > the first paragraph of this section > > Nits: > > There’s occasionally some unidiomatic English (for example, “The command > mappings described here are specifically for the use to notify [ … ]” rather > than, for example, “The command mappings described here are specifically used > to notify [ … ]”, “The information on a [ … ]” rather than “The information > about a [ … ], etc.), > > Section 1, first paragraph: It’s actually not very clear about what registries > are informing registrars. It may be clearer to start with something along the > lines of “Registries usually inform registrars of maintenance activities in > different ways.” > > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Fri Oct 8 02:09:30 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D483A15D4 for ; Fri, 8 Oct 2021 02:09:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <163368416802.4605.11900211724764045570@ietfa.amsl.com> Date: Fri, 08 Oct 2021 02:09:28 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 09:09:29 -0000 Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview For telechat 2021-10-21 Reviewer LC end Draft Shaun Cooley 2021-10-18 draft-ietf-jmap-smime Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy Dacheng Zhang 2021-09-07 draft-ietf-bess-evpn-bum-procedure-updates Last calls: Reviewer LC end Draft John Bradley 2021-09-06 draft-ietf-core-senml-data-ct Shaun Cooley 2021-10-18 draft-ietf-jmap-smime Daniel Franke 2021-09-22 draft-ietf-cbor-network-addresses Phillip Hallam-Baker 2021-10-12 draft-ietf-cbor-cddl-control Scott Kelly 2021-10-27 draft-ietf-regext-rfc7484bis Tero Kivinen 2021-10-21 draft-zern-webp Watson Ladd 2021-10-01 draft-ietf-netmod-yang-instance-file-format Chris Lonvick None draft-ietf-opsawg-l2nm Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 David Mandelberg 2021-10-14 draft-ietf-tsvwg-rfc4960-bis Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Tim Polk 2021-08-06 draft-ietf-opsawg-vpn-common Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Samuel Weiler 2021-08-25 draft-ietf-alto-path-vector Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2021-08-30 draft-ietf-alto-cdni-request-routing-alto Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Liang Xia 2021-03-17 draft-ietf-core-sid Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy Dacheng Zhang 2021-09-07 draft-ietf-bess-evpn-bum-procedure-updates Early review requests: Reviewer Due Draft Stephen Farrell 2021-09-15 draft-ietf-ippm-ioam-direct-export Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Tina Tsou 2021-08-25 draft-ietf-opsawg-sbom-access Sean Turner 2021-08-18 draft-ietf-taps-interface Loganaden Velvindron 2021-08-18 draft-ietf-taps-arch Next in the reviewer rotation: Catherine Meadows Alexey Melnikov Daniel Migault Adam Montville Kathleen Moriarty Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman From nobody Fri Oct 8 11:37:04 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C64D3A08FC; Fri, 8 Oct 2021 07:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1633703994; bh=/mmHp6IxsNB8czV8Driqcajh4TnZaLeQEHFTKTOffXU=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=YCbI/HhhHgiftVVq+1UaH/+QCfqIkqJcQwAo78R6fC9BpH3XZIWKckLyxEw1AMSIc XP9YhoVykfq/5oGUO/HkGFbHbDGqvoH8HO/54W5pQ6hM1sA2J748NYjYKWnp9Rnwbf 95K5ks2OBNVzpJK6I3MFL60hqiEMpSW5r8GvJgeM= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Oct 8 07:39:53 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7713A08F3; Fri, 8 Oct 2021 07:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1633703993; bh=/mmHp6IxsNB8czV8Driqcajh4TnZaLeQEHFTKTOffXU=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=npoLmYYAYeMZ8gDyQUvYu4preHwNsJZvhsgbDusEPljH0WHD/6+TV7YdkrIwu6Lcb a/WYVqDcyTURFtgiPPeQynbZjL1d5Mhc7fqZRWQKGICcE088OXUZ1VDA8eSFSgmIkk H3kWNn6BRP/1zuFt23FAe1GnGJOWFtoafKkMkBok= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48AF3A08F3 for ; Fri, 8 Oct 2021 07:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 (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 p7NPr7Yoi6qp for ; Fri, 8 Oct 2021 07:39:46 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 682D53A08ED for ; Fri, 8 Oct 2021 07:39:46 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id k19so814370qvm.13 for ; Fri, 08 Oct 2021 07:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version:content-language :thread-index; bh=HEd/Ox6ZtcstubV7YE+62/pXgMSdDA1u6+9WfFshbMk=; b=nph4VViBPAHBn86xcFARJahBWPw/UpCS9J4yWMXwShQW6/ZjNou6WVLeVyXkxha4O6 0Feru8o+OH1j/kKs67GB8BwK8ut9Ids6gYOG51fzRmJM8M4uWm/XuIPg20SRLH/Bgdx4 uY14IgmgxLoD9XqHxFnWzkyzDNZwh0ttxc+j8a3WfJyAPJ8owBHXuy3jmC+y/FI50R8k rvPUQxHQtQ1WyIZegUaE0SLf66yOvYctGQC0LE+9BFGunjpHmwGJ0I5kDa0sKGYlAYDN v8Z2FeodyBd0N25Ovf/Mbohe+O3jNhKDArN+/YMbIB24aekZCAv2/efLPRaUurgFiFdT XtKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-language:thread-index; bh=HEd/Ox6ZtcstubV7YE+62/pXgMSdDA1u6+9WfFshbMk=; b=fGkaDAZo2G+PuQeOs9gtTeMi7Kf7cqpr33a6+ZV5TmVYGWBjmQNnUYi6r/2ZbtQrP2 k6gDYtXiCRivZnhZw4HT2jOtC7TLCrgBsWNoqhV+2skbZikOwdPmN9i27vm1fJ5yvdAW nc4sI7fw6bAYYuvptmjrwQRY5PynE8M04yJqOVufYLyVWxcreZKlVq3EfKiFZvUgAifI 3W/d+qjiznbOHQeOn19e//BIRjHsyKp/Us3U1ZGm8c+xI+YgsQQZXW8hDMY0VUqJQdMX il6kr1vJMRpdSTf+lTtVph/ZQAyO1deNqqSZrLn7/6de1/KJTOEH+Np9Jte0+y+dJttA ufpQ== X-Gm-Message-State: AOAM5323NCHh5e0y8+VHaLaG7Dol348mxog4e9YKU397ksiUrKXjimzT 1KBPCVHk+w2BCdV1F22Dw1E= X-Google-Smtp-Source: ABdhPJxiiGW8ryCpfyTEXhN18NlsZH9Lo9ilG0XwoBIuW5eUnPrVss6jCP8rOkE0Qyt1aIYyCiYfPg== X-Received: by 2002:ad4:5c48:: with SMTP id a8mr10070659qva.20.1633703985327; Fri, 08 Oct 2021 07:39:45 -0700 (PDT) Received: from DESKTOP6VF5FH7 (pool-96-249-149-147.hrbgpa.fios.verizon.net. [96.249.149.147]) by smtp.gmail.com with ESMTPSA id v2sm2577553qtw.8.2021.10.08.07.39.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Oct 2021 07:39:44 -0700 (PDT) From: To: Date: Fri, 8 Oct 2021 10:39:42 -0400 Message-ID: <07c101d7bc52$551ec8e0$ff5c5aa0$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: Ade8UiOON+L/q5vuRouhiJ+29zvxHg== Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Cc: "'Stanley, Dorothy'" , Paul Nikolich Content-Type: multipart/mixed; boundary="===============0402697847986963705==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 08 Oct 2021 11:36:41 -0700 Subject: [secdir] [new-work] IEEE 802 PARs under consideration: Nov 2021 Plenary X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 14:39:56 -0000 This is a multipart message in MIME format. --===============0402697847986963705== Content-Type: multipart/alternative; boundary="----=_NextPart_000_07C2_01D7BC30.CE0D9E10" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_07C2_01D7BC30.CE0D9E10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, The following Project Authorization Requests (PARs) and ICAID will be considered at the IEEE 802 Nov 2021 Plenary, which will be held electronically - * 802.1ASds - Amendment: Support for the IEEE Std 802.3 Clause 4 Media Access Control (MAC) operating in half-duplex, PAR and CSD * 802.3df - Amendment: Media Access Control Parameters, Physical Layers and Management Parameters for 200 Gb/s, 400 Gb/s, 800 Gb/s, and 1.6 Tb/s Operation, PAR and CSD * 802.11bb - Amendment: Light Communication, PAR Modification , and CSD * 802.15ma - Standard for High Data Rate Wireless Multi-Media Networks - Revision to IEEE Standard 802.15.3-2016, PAR and CSD The PARs and ICAID can be found at http://www.ieee802.org/PARs.shtml along with the supporting IEEE 802 Criteria for Standards Development, or CSD, (which includes the 5 criteria, i.e. the explanations of how they fit the IEEE 802 criteria for initiating new work). Any comments on a proposed PAR / ICAID should be sent to the Working Group chair identified on the respective document to be received by 10 Nov 2021, AoE Regards, John D'Ambrosia Recording Secretary, IEEE 802 LMSC ------=_NextPart_000_07C2_01D7BC30.CE0D9E10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IEEE 802 PARs under consideration: Nov 2021 Plenary

All,

The = following Project Authorization Requests (PARs) and ICAID will be = considered at the IEEE 802 Nov 2021 Plenary, which will = be held electronically –  

·       = 802.1ASds  - Amendment: Support for = the IEEE Std 802.3 Clause 4 Media Access Control (MAC) operating in = half-duplex, PAR and CSD

·       802.3df - Amendment: = Media Access Control Parameters, Physical Layers and Management = Parameters for 200 Gb/s, 400 Gb/s, 800 Gb/s, and 1.6 Tb/s = Operation, PAR and CSD

·       802.11bb - Amendment: = Light Communication, PAR = Modification, and CSD

·       802.15ma - Standard for = High Data Rate Wireless Multi-Media Networks - Revision to = IEEE Standard 802.15.3-2016, PAR and CSD

The = PARs and ICAID can be found at = http://www.ieee802.org/PARs.shtml along with the = supporting IEEE 802 Criteria for Standards Development, or CSD, (which = includes the 5 criteria, i.e. the explanations of how they fit the IEEE = 802 criteria for initiating new work).

Any = comments on a proposed PAR / ICAID should be sent to the Working Group = chair identified on the respective document to be received = by = 10 Nov 2021, AoE

Regards,

John = D’Ambrosia

Recording Secretary, IEEE 802 LMSC

------=_NextPart_000_07C2_01D7BC30.CE0D9E10-- --===============0402697847986963705== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============0402697847986963705==-- From nobody Fri Oct 8 11:37:08 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BE73A0CC6; Fri, 8 Oct 2021 11:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1633716480; bh=iVbwag6DvqIgiS/Ldzb/l61yUg8s8eumvP0L85Q7VOM=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=dxhfAWnWDKdYvzas9o7IpvilZvDlg09veXFwzS7nXnOHcsfIoJpQDlF8SwSwQRfRk PmliBpc2Feq0/7kYPNpNG5I7UResmEkiqJzH7if3c+bLm3ccyvSJaA0ywNztX49OMP 52nuIgMnTpy6PmZQmJBTAb+YL6ts1m5g++gOEmv8= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Oct 8 11:07:54 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5034F3A0CA5; Fri, 8 Oct 2021 11:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1633716474; bh=iVbwag6DvqIgiS/Ldzb/l61yUg8s8eumvP0L85Q7VOM=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=lPd8AnF5Iyd+Fwh0Cr3rTHwdr3N7fF5wyEGmRi6eZJ2iS31NXU/CDoZEmyW0mWnPB 9HJBFZRetU52wXni/OKINrI1KB81eghKwYZqVZw8azcL8DVkoE2EB9bVl44tvHjOpP HuXLeERak3fDzgI66jMIl71YeErYEh1++9PpczJ8= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BE23A0C43 for ; Fri, 8 Oct 2021 11:07:46 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <163371646654.27211.13068601397982814069@ietfa.amsl.com> Date: Fri, 08 Oct 2021 11:07:46 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 08 Oct 2021 11:36:41 -0700 Subject: [secdir] [new-work] WG Review: System for Cross-domain Identity Management (scim) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 18:08:08 -0000 QSBuZXcgSUVURiBXRyBoYXMgYmVlbiBwcm9wb3NlZCBpbiB0aGUgQXBwbGljYXRpb25zIGFuZCBS ZWFsLVRpbWUgQXJlYS4gVGhlCklFU0cgaGFzIG5vdCBtYWRlIGFueSBkZXRlcm1pbmF0aW9uIHll dC4gVGhlIGZvbGxvd2luZyBkcmFmdCBjaGFydGVyIHdhcwpzdWJtaXR0ZWQsIGFuZCBpcyBwcm92 aWRlZCBmb3IgaW5mb3JtYXRpb25hbCBwdXJwb3NlcyBvbmx5LiBQbGVhc2Ugc2VuZCB5b3VyCmNv bW1lbnRzIHRvIHRoZSBJRVNHIG1haWxpbmcgbGlzdCAoaWVzZ0BpZXRmLm9yZykgYnkgMjAyMS0x MC0xOC4KClN5c3RlbSBmb3IgQ3Jvc3MtZG9tYWluIElkZW50aXR5IE1hbmFnZW1lbnQgKHNjaW0p Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCkN1cnJlbnQgc3RhdHVzOiBQcm9wb3NlZCBXRwoKQ2hhaXJzOgogIE5h bmN5IENhbS1XaW5nZXQgPG5jYW13aW5nQGNpc2NvLmNvbT4KCkFzc2lnbmVkIEFyZWEgRGlyZWN0 b3I6CiAgUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPgoKQXBwbGljYXRpb25zIGFuZCBSZWFs LVRpbWUgQXJlYSBEaXJlY3RvcnM6CiAgTXVycmF5IEt1Y2hlcmF3eSA8c3VwZXJ1c2VyQGdtYWls LmNvbT4KICBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29u LmNvbT4KCk1haWxpbmcgbGlzdDoKICBBZGRyZXNzOiBzY2ltQGlldGYub3JnCiAgVG8gc3Vic2Ny aWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0KICBBcmNoaXZl OiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL3NjaW0vCgpHcm91cCBw YWdlOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2dyb3VwL3NjaW0vCgpDaGFydGVyOiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtc2NpbS8KClRoZSBT eXN0ZW0gZm9yIENyb3NzLWRvbWFpbiBJZGVudGl0eSBNYW5hZ2VtZW50IChTQ0lNKSBzcGVjaWZp Y2F0aW9ucyBwcm92aWRlCmFuIEhUVFAtYmFzZWQgcHJvdG9jb2wgKFJGQzc2NDMpIGFuZCBzY2hl bWEgKFJGQzc2NDQpIHRoYXQgbWFrZXMgbWFuYWdpbmcKaWRlbnRpdGllcyBpbiBtdWx0aS1kb21h aW4gc2NlbmFyaW9zIGVhc2llci4gIFNpbmNlIGl0cyBwdWJsaWNhdGlvbiBpbiAyMDE1LApTQ0lN IGhhcyBzZWVuIGdyb3dpbmcgYWRvcHRpb24uCgpUaGUgZmlyc3QgZ29hbCBvZiB0aGlzIHdvcmtp bmcgZ3JvdXAgaXMgdG8gaW5jb3Jwb3JhdGUgaW1wbGVtZW50YXRpb24KZXhwZXJpZW5jZTsgZXJy YXRhIGFuZCBpbnRlcm9wZXJhYmlsaXR5IGZlZWRiYWNrOyBhbmQgY3VycmVudCBzZWN1cml0eSBh bmQKYmVzdCBwcmFjdGljZXMgaW50byBhIHJldmlzZWQgdmVyc2lvbiBvZiBSRkM3NjQzIChwcm90 b2NvbCkgYW5kIFJGQzc2NDQgKGJhc2UKc2NoZW1hKSBzdWl0YWJsZSBmb3IgY29uc2lkZXJhdGlv biBhdCB0aGUgSW50ZXJuZXQgU3RhbmRhcmQgbGV2ZWwgb2YKc3BlY2lmaWNhdGlvbiBtYXR1cml0 eS4KCkFkZGl0aW9uYWxseSwgaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSB3aXRoIFNDSU0gaGFz IHN1cmZhY2VkIG5ldyB1c2UgY2FzZXMKYW5kIHJlcXVpcmVtZW50cy4gIFRoZSBXRyB3aWxsIGRv Y3VtZW50IHRoZW0gaW4gYSByZXZpc2lvbiBvZiBSRkM3NjQyLiBUaGUgV0cKd2lsbCBhbHNvIGNv bnNpZGVyIHB1Ymxpc2hpbmcgZXh0ZW5zaW9ucyB0byBTQ0lNIHRoYXQgaGF2ZSBmb3VuZCBicm9h ZAphZG9wdGlvbi4gVGhlc2UgZXh0ZW5zaW9ucyBtYXkgaW5jbHVkZSBwcm9maWxlcyBhbmQgc2No ZW1hcyBmb3IKaW50ZXJvcGVyYWJpbGl0eSBpbiBhZGRpdGlvbmFsIHVzZSBjYXNlcy4KClRoZSBj dXJyZW50bHkgcGxhbm5lZCBzY29wZSBvZiB3b3JrIGZvciB0aGUgU0NJTSBXRyBpczoKCiogUmV2 aXNpb24gb2YgUkZDIDc2NDIgdGhhdCB3aWxsOgogICAgKiBGb2N1cyBvbiBVc2UgY2FzZXMgYW5k IGltcGxlbWVudGF0aW9uIHBhdHRlcm5zCiAgICAgICAgKiBQdWxsIHZzLiBQdXNoIGJhc2VkIHVz ZSBjYXNlcwogICAgICAgICogRXZlbnRzIGFuZCBzaWduYWxzIHVzZSBjYXNlcwogICAgICAgICog RGVsZXRpb24gdXNlIGNhc2VzCiAgICAqIE5ldyB1c2UgY2FzZXMgbWF5IGJlIGFkZGVkIHRvIHRo ZSByZXZpc2VkIFJGQwoqIFJldmlzaW9uIG9mIFJGQyA3NjQzIGFuZCA3NjQ0IHRoYXQgd2lsbCBp bmNsdWRlOgogICAgKiBQcm9maWxpbmcgU0NJTSByZWxhdGlvbnNoaXBzIHdpdGggb3RoZXIgaWRl bnRpdHktY2VudHJpYyBwcm90b2NvbHMgc3VjaAogICAgYXMgT0F1dGggMi4wLCBPcGVuSUQgQ29u bmVjdCwgU2hhcmVkIFNpZ25hbHMsIGFuZCBGYXN0ZmVkICogVXBkYXRlcyB0bwogICAgdGhlIGV2 b2x1dGlvbiBvZiB0aGUgZXh0ZXJuYWxpZCB1c2FnZQogICAgICAgICogVXBkYXRlcyB0byBhY2Nv dW50IHN0YXRlIGZvciBjYXB0dXJpbmcgY29udGV4dCBvZiB0aGUgc3RhdGUgb3IKICAgICAgICBj aGFuZ2UgaW4gc3RhdGUgb2YgdGhlIHVzZXJzIGFjY291bnQKKiBNdWx0aS1WYWx1ZSBRdWVyeSBG aWx0ZXJpbmcgYW5kIFBhZ2luZyAoYmFzZWQgb24gZHJhZnQtaHVudC1zY2ltLW12LXBhZ2luZykK KiBEZWZpbmUgYSBtZXRob2QgZm9yIGNvb3JkaW5hdGluZyByZXNvdXJjZXMgYmV0d2VlbiBkb21h aW5zOgogICAgKiBJbmNyZW1lbnRhbCBhcHByb2FjaCB0byBzeW5jaHJvbml6YXRpb24KICAgICog Q29uc2lkZXIgYnVpbGRpbmcgb2ZmIG9mIFJGQzg0MTcgYW5kIGRyYWZ0LWh1bnQtaWRldmVudC1z Y2ltCiogU3VwcG9ydCBmb3IgZGVsZXRpb24tcmVsYXRlZCBnb2FscyBpbmNsdWRpbmc6CiAgICAq IEhhbmRsaW5nIERlbGV0ZXMgaW4gU0NJTSBTZXJ2ZXJzIHRoYXQgZG9u4oCZdCBhbGxvdyBEZWxl dGVzIChTb2Z0CiAgICBEZWxldGVzKSAoYmFzZWQgb24gZHJhZnQtYW5zYXJpLXNjaW0tc29mdC1k ZWxldGUpCiogU3VwcG9ydCBmb3IgYWR2YW5jZWQgYXV0b21hdGlvbiBzY2VuYXJpb3Mgc3VjaCBh czoKICAgICogRGlzY292ZXJ5IGFuZCBuZWdvdGlhdGlvbiBvZiBjbGllbnQgY3JlZGVudGlhbHMK ICAgICogQXR0cmlidXRlIG1hcHBpbmcKICAgICogUGVyLWF0dHJpYnV0ZSBzY2hlbWEgbmVnb3Rp YXRpb24KKiBFbmhhbmNlIHRoZSBleGlzdGluZyBzY2hlbWEgdG8gc3VwcG9ydCBleGNoYW5naW5n IG9mIEhSLCBFbnRlcnByaXNlIGdyb3VwCmFuZCBwcml2aWxlZ2VkIGFjY2VzcyBtYW5hZ2VtZW50 IChiYXNlZCBvbiBkcmFmdC1ncml6emxlLXNjaW0tcGFtLWV4dCkKCk1pbGVzdG9uZXM6CgogIERl YyAyMDIxIC0gV29ya2luZyBncm91cCBhZG9wdGlvbiBvZiBJLUQgZm9yIHJldmlzaW5nIFJGQzc2 NDIKCiAgRGVjIDIwMjEgLSBXb3JraW5nIGdyb3VwIGFkb3B0aW9uIG9mIEktRHMgZm9yIFNvZnQg RGVsZXRlCgogIE1hciAyMDIyIC0gV29ya2luZyBncm91cCBhZG9wdGlvbiBvZiBJLURzIChlaXRo ZXIgbmV3IG9yIGV4aXN0aW5nKSBmb3IKICBwcml2aWxlZ2VkIGFjY2VzcyBtYW5hZ2VtZW50Cgog IE1hciAyMDIyIC0gV29ya2luZyBncm91cCBhZG9wdGlvbiBvZiBJLURzIGZvciBNdWx0aS12YWx1 ZWQgcGFnaW5nCgogIE1hciAyMDIyIC0gV29ya2luZyBHcm91cCBhZG9wdGlvbiBvZiBJLURzIGZv ciBjb29yZGluYXRpb24vc3luY2hyb25pemF0aW9uCiAgYmV0d2VlbiBkb21haW5zCgogIEp1biAy MDIyIC0gUHJvZ3Jlc3MgSS1EIHJldmlzaW5nIFJGQzc2NDIgdG8gV0dMQwoKICBKdW4gMjAyMiAt IFdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gb2YgSS1EIHJldmlzaW5nIFJGQzc2NDMKCiAgSnVuIDIw MjIgLSBXb3JraW5nIGdyb3VwIGFkb3B0aW9uIG9mIEktRCByZXZpc2luZyBSRkM3NjQ0CgogIERl YyAyMDIyIC0gUHJvZ3Jlc3MgSS1EcyBmb3IgU29mdCBEZWxldGUgdG8gV0dMQwoKICBEZWMgMjAy MiAtIFByb2dyZXNzIEktRHMgZm9yIE11bHRpLXZhbHVlZCBwYWdpbmcgdG8gV0dMQwoKICBNYXIg MjAyMyAtIFByb2dyZXNzIEktRHMgKGVpdGhlciBuZXcgb3IgZXhpc3RpbmcpIGZvciBwcml2aWxl Z2VkIGFjY2VzcwogIG1hbmFnZW1lbnQgdG8gV0dMQwoKICBKdW4gMjAyMyAtIFByb2dyZXNzIEkt RHMgZm9yIGNvb3JkaW5hdGlvbi9zeW5jaHJvbml6YXRpb24gYmV0d2VlbiBkb21haW5zCiAgdG8g V0dMQwoKICBKdW4gMjAyMyAtIFByb2dyZXNzIEktRCByZXZpc2luZyBSRkM3NjQzIHRvIFdHTEMK CiAgSnVuIDIwMjMgLSBQcm9ncmVzcyBJLUQgcmV2aXNpbmcgUkZDNzY0NCB0byBXR0xDCgoKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldy13b3JrIG1h aWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldy13b3JrCg== From nobody Sun Oct 10 09:21:35 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 906053A0597; Sun, 10 Oct 2021 09:21:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Chris Lonvick via Datatracker To: Cc: draft-ietf-opsawg-l2nm.all@ietf.org, last-call@ietf.org, opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163388288155.10643.2924710804028152302@ietfa.amsl.com> Reply-To: Chris Lonvick Date: Sun, 10 Oct 2021 09:21:21 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-opsawg-l2nm-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2021 16:21:22 -0000 Reviewer: Chris Lonvick Review result: Ready Hello, 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. The summary of the review is READY with some very minor nits in the Security Considerations section. I'm not well versed in this area but I'll say that the entire document is understandable and appears well written. I found no obvious errors or problems in my brief review. The first paragraph in the Security Considerations section lists that this work is built atop YANG, NETCONF, or RESTCONF, and lists the transport protocols that are used for them, but stops short of providing guidance. My recommendation is to address this by adding a sentence such as, "Developers, implementers, and administrators of this specification should be familiar with the Security Considerations sections of those RFCs." The remaining paragraphs of the Security Considerations section provide a list of tools that may be used along with guidance on using them to secure access to sensitive items. The authors may wish to summarize this by adding a sentence such as, "Administrators may consider using these, and perhaps other tools, to enforce a security policy." Regards, Chris From nobody Sun Oct 10 22:46:55 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B033A0418; Sun, 10 Oct 2021 22:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 LStrf9Vu3sDh; Sun, 10 Oct 2021 22:44:41 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 0B5363A040D; Sun, 10 Oct 2021 22:44:41 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr26.francetelecom.fr (ESMTP service) with ESMTPS id 4HSSRV69rLz13rc; Mon, 11 Oct 2021 07:44:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1633931078; bh=6Oz5q/hT2PDQ0D69Gt94Zswmv4lUQBD4YRmM8jTU2QA=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=u482K4e9Kac3ekkMx9LbT2IYRDrr4So2w05UW9H8n18MtsioBLbJPxtHv8TTvEsfj /MwUk1FjeYhURCR9tlwc8amPbh6NMTlw1YiI/Td+1wbTPSM2F+VORJ307sG5076YUW 1wTPPYdd5FOaiU8R+dK6kv8vTSqPcCn4ruS52TN1NZfOlvx5lLFQ1+jhBr8c8uPmF1 AbZhZwMvj/I8Tp2LRkYgMOnqEvdCnxeTBLNSoFltRnKa2aPMAa5BmmacmVx1Wr4oos Uvwq/nyRm0zb9DQ8nDPp+mMZjid7gU1QXW1H6pDaoCFkEaOTviYX6YlIVhPUxFjch3 3u7SO/KEIObyQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr03.francetelecom.fr (ESMTP service) with ESMTPS id 4HSSRV4v1LzDq7V; Mon, 11 Oct 2021 07:44:38 +0200 (CEST) From: To: Chris Lonvick , "secdir@ietf.org" CC: "draft-ietf-opsawg-l2nm.all@ietf.org" , "last-call@ietf.org" , "opsawg@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-opsawg-l2nm-07 Thread-Index: AQHXvfLfIJ/vpn8EgE+hDExcqAJlIKvNSKWQ Content-Class: Date: Mon, 11 Oct 2021 05:44:37 +0000 Message-ID: <12576_1633931078_6163CF46_12576_267_1_787AE7BB302AE849A7480A190F8B933035425FC2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <163388288155.10643.2924710804028152302@ietfa.amsl.com> In-Reply-To: <163388288155.10643.2924710804028152302@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2021-10-11T05:39:07Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=6fcc23c0-d8bc-4f02-8d9e-7baa3f3a67d6; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-opsawg-l2nm-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2021 05:44:48 -0000 SGkgQ2hyaXMsDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4gTXVjaCBhcHByZWNpYXRlZC4g DQoNCkZvciB0aGUgc2VjdXJpdHkgZ3VpZGVsaW5lcywgd2UgYXJlIGZvbGxvd2luZyB0aGlzIHJl Y29tbWVuZGF0aW9uIGZyb20gUkZDODQwNzoNCg0KICAgVGhpcyBzZWN0aW9uIE1VU1QgYmUgcGF0 dGVybmVkIGFmdGVyIHRoZSBsYXRlc3QgYXBwcm92ZWQgdGVtcGxhdGUNCiAgIChhdmFpbGFibGUg YXQgPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL29wcy93aWtpL3lhbmctc2VjdXJpdHktDQog ICBndWlkZWxpbmVzPikuICBTZWN0aW9uIDMuNy4xIGNvbnRhaW5zIHRoZSBzZWN1cml0eSBjb25z aWRlcmF0aW9ucw0KICAgdGVtcGxhdGUgZGF0ZWQgMjAxMy0wNS0wOCBhbmQgbGFzdCB1cGRhdGVk IG9uIDIwMTgtMDctMDIuICBBdXRob3JzDQogICBNVVNUIGNoZWNrIHRoZSB3ZWIgcGFnZSBhdCB0 aGUgVVJMIGxpc3RlZCBhYm92ZSBpbiBjYXNlIHRoZXJlIGlzIGENCiAgIG1vcmUgcmVjZW50IHZl cnNpb24gYXZhaWxhYmxlLg0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj4gRGXCoDogQ2hyaXMgTG9udmljayB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlA aWV0Zi5vcmc+DQo+IEVudm95w6nCoDogZGltYW5jaGUgMTAgb2N0b2JyZSAyMDIxIDE4OjIxDQo+ IMOAwqA6IHNlY2RpckBpZXRmLm9yZw0KPiBDY8KgOiBkcmFmdC1pZXRmLW9wc2F3Zy1sMm5tLmFs bEBpZXRmLm9yZzsgbGFzdC1jYWxsQGlldGYub3JnOw0KPiBvcHNhd2dAaWV0Zi5vcmcNCj4gT2Jq ZXTCoDogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vcHNhd2ctbDJubS0w Nw0KPiANCj4gUmV2aWV3ZXI6IENocmlzIExvbnZpY2sNCj4gUmV2aWV3IHJlc3VsdDogUmVhZHkN Cj4gDQo+IEhlbGxvLA0KPiANCj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFy dCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncw0KPiBvbmdvaW5nIGVmZm9ydCB0byByZXZp ZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4NCj4gVGhl c2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhl IHNlY3VyaXR5IGFyZWENCj4gZGlyZWN0b3JzLg0KPiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cg Y2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55DQo+IG90aGVy IGxhc3QgY2FsbCBjb21tZW50cy4NCj4gDQo+IFRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXMg UkVBRFkgd2l0aCBzb21lIHZlcnkgbWlub3Igbml0cyBpbiB0aGUNCj4gU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMgc2VjdGlvbi4NCj4gDQo+IEknbSBub3Qgd2VsbCB2ZXJzZWQgaW4gdGhpcyBhcmVh IGJ1dCBJJ2xsIHNheSB0aGF0IHRoZSBlbnRpcmUgZG9jdW1lbnQgaXMNCj4gdW5kZXJzdGFuZGFi bGUgYW5kIGFwcGVhcnMgd2VsbCB3cml0dGVuLiBJIGZvdW5kIG5vIG9idmlvdXMgZXJyb3JzIG9y DQo+IHByb2JsZW1zIGluIG15IGJyaWVmIHJldmlldy4NCj4gDQo+IFRoZSBmaXJzdCBwYXJhZ3Jh cGggaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gbGlzdHMgdGhhdCB0aGlz DQo+IHdvcmsgaXMgYnVpbHQgYXRvcCBZQU5HLCBORVRDT05GLCBvciBSRVNUQ09ORiwgYW5kIGxp c3RzIHRoZSB0cmFuc3BvcnQNCj4gcHJvdG9jb2xzIHRoYXQgYXJlIHVzZWQgZm9yIHRoZW0sIGJ1 dCBzdG9wcyBzaG9ydCBvZiBwcm92aWRpbmcgZ3VpZGFuY2UuDQo+IE15IHJlY29tbWVuZGF0aW9u IGlzIHRvIGFkZHJlc3MgdGhpcyBieSBhZGRpbmcgYSBzZW50ZW5jZSBzdWNoIGFzLA0KPiAiRGV2 ZWxvcGVycywgaW1wbGVtZW50ZXJzLCBhbmQgYWRtaW5pc3RyYXRvcnMgb2YgdGhpcyBzcGVjaWZp Y2F0aW9uIHNob3VsZA0KPiBiZSBmYW1pbGlhciB3aXRoIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyBzZWN0aW9ucyBvZiB0aG9zZSBSRkNzLiINCj4gDQo+IFRoZSByZW1haW5pbmcgcGFyYWdy YXBocyBvZiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBwcm92aWRlIGENCj4g bGlzdCBvZiB0b29scyB0aGF0IG1heSBiZSB1c2VkIGFsb25nIHdpdGggZ3VpZGFuY2Ugb24gdXNp bmcgdGhlbSB0byBzZWN1cmUNCj4gYWNjZXNzIHRvIHNlbnNpdGl2ZSBpdGVtcy4gVGhlIGF1dGhv cnMgbWF5IHdpc2ggdG8gc3VtbWFyaXplIHRoaXMgYnkNCj4gYWRkaW5nIGEgc2VudGVuY2Ugc3Vj aCBhcywgIkFkbWluaXN0cmF0b3JzIG1heSBjb25zaWRlciB1c2luZyB0aGVzZSwgYW5kDQo+IHBl cmhhcHMgb3RoZXIgdG9vbHMsIHRvIGVuZm9yY2UgYSBzZWN1cml0eSBwb2xpY3kuIg0KPiANCj4g UmVnYXJkcywNCj4gQ2hyaXMNCj4gDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQg ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Mon Oct 11 19:12:21 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE03F3A0B91 for ; Mon, 11 Oct 2021 19:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=mandelberg.org header.b=GxVrtTYY; dkim=pass (2048-bit key) header.d=mandelberg.org header.b=Jmdn0NJY 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 PXdBjQqyxaiO for ; Mon, 11 Oct 2021 19:12:12 -0700 (PDT) Received: from mail-ua1-x962.google.com (mail-ua1-x962.google.com [IPv6:2607:f8b0:4864:20::962]) (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 290283A0B83 for ; Mon, 11 Oct 2021 19:12:12 -0700 (PDT) Received: by mail-ua1-x962.google.com with SMTP id h19so4377914uax.5 for ; Mon, 11 Oct 2021 19:12:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:dkim-signature:dkim-signature:to:from:subject :message-id:date:user-agent:mime-version:content-language :content-transfer-encoding; bh=4xOiGvxffyzZvc7j/Rr9A2jLcSL2ZDsRzSBKOPM3Vww=; b=UcG68RZQn5ZqpftOBgditXdiigDuaGrb5lcgdcVbSEPodbX7h6qU0Ky+v3XW/LaBio b7o/b5+PJkoBfz6ME7jMyHlTT2TS9H9c7Y2J3yBpCqxo895WJrLxZo1hbJXgLEdUNNO5 JXF1jCvYnWZYUI5zsScJmDm5cuvnTBtU5ENiLJWsSe6JYts78g1/yIRAyLT+lNV2NJpR ze0c0F/xl6mSe/M4DtbH4ehKHcP7RXvL6uYYV07GoG7t6prwdqGcZuXjJq+JARRGxa0d /vJWekzpXBz0Y+vRyqky9ggBA10RH5EBxGh55kGdIGg7kPqqv8EPKje1iq4Rut6Ow79e bnDA== X-Gm-Message-State: AOAM532N2OvffaplzMwo5u4SRKzxzAjknEq7xUSoE5DbYdlDYCfx5lor PqYnjUCeRp+gs+hE//C+bjCcHQE3pK8T9dU/JjzfGr/VIev3GA== X-Google-Smtp-Source: ABdhPJw+eHjmJzkwuab6apsrvj4KKf+XjzfYtS2wYkGbF1XQtSu9ZZSNAYe6SlMBCjiaNebZds6lHrkio/sU X-Received: by 2002:a67:ac42:: with SMTP id n2mr28216024vsh.21.1634004730890; Mon, 11 Oct 2021 19:12:10 -0700 (PDT) Received: from mail-outbound-e14cf917.virgo.mandelberg.org (pool-74-104-157-60.bstnma.fios.verizon.net. [74.104.157.60]) by smtp-relay.gmail.com with ESMTPS id e15sm2299114uaa.0.2021.10.11.19.12.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Oct 2021 19:12:10 -0700 (PDT) X-Relaying-Domain: mandelberg.org DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=mandelberg.org; i=@mandelberg.org; q=dns/txt; s=mail-outbound-e14cf917-07914516; t=1634004730; h=to : from : subject : message-id : date : mime-version : content-type : content-transfer-encoding : from; bh=xyAHBCBNoQ8R1QXVMw5tsyjE21N3mjN5VJdqzR3zZAc=; b=GxVrtTYYXoln80Bai1Ajk/20cWtAyAnJc8L433Sqk8uEOKbPtFTTgbP4DQaHGBrtLrUlc KmKMifZYEUQZLS0DA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; i=@mandelberg.org; q=dns/txt; s=mail-outbound-e14cf917-b7c648a2; t=1634004730; h=to : from : subject : message-id : date : mime-version : content-type : content-transfer-encoding : from; bh=xyAHBCBNoQ8R1QXVMw5tsyjE21N3mjN5VJdqzR3zZAc=; b=Jmdn0NJYBHLIZcdKpBL4s6Sg+LJxYxTqyQb6Lre6OX99UDn4Mz5193x73G7QZCDXf3ROc MwucOcnoWRwRQ603BSkuUm9bshZQznybs/T5M2i7saKONpdFD169ExtR8Q3h3CEE8e6LgDL Rl0un/DgfYx049Qv59lLzINy6kydF3xxENp4wLdrpGtA/bjGpPZOWjTxfZAYTcM3keZAB7R R1PppKlLUYuOPBJlAqQ6f6aYUfg9yZb+Qkp7i3ehcLf69j2v6hNSJ2QdnhiJqtrGCoxPPgB U01j4osTiLVT7PnUljbjt9dpcwwh4ifk6s+SbzGkjGzBCx1Dc4fA/LgcsAFw== Received: from [IPv6:fde5:2b79:35f0:2::14e] (solaria.virgo.mandelberg.org [IPv6:fde5:2b79:35f0:2::14e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by mail-outbound-e14cf917.virgo.mandelberg.org (Postfix) with ESMTPSA id 4HSzgt2Ck4z10Zt; Tue, 12 Oct 2021 02:12:10 +0000 (UTC) To: secdir@ietf.org, iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org From: David Mandelberg Message-ID: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> Date: Mon, 11 Oct 2021 22:12:10 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2021 02:12:18 -0000 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. The summary of the review is Ready with nits. (nit) Section 2.3 describes MACs as "based on cryptographic hash functions using a secret key". If the intent is to limit this to MACs that use cryptographic hash functions, I'd suggest using the term HMAC instead of MAC. If not, I think there are other MAC algorithms that don't use hashes. (nit) The description of Chunk Length in Section 3.2 seems a bit complicated. (Not a lot complicated, just a bit.) I'd expect at least occasional security issues from incorrect implementations in programming languages that don't enforce in-bounds memory access. I'm guessing it's either too late to simplify the field, or there are good reasons for it to be the way it is? Are there any lessons learned by existing implementations that would be worth mentioning to help future implementors avoid issues with out-of-bounds memory access here? ("No" is a fine answer if this turns out to not have been a problem.) (nit) Section 5.1.5, bullet point 4 says 'If the elapsed time is longer than the lifespan carried in the State Cookie, then ... the endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer endpoint.' That's different from the behavior if the MAC fails in bullet point 2. Does that mean that endpoints are REQUIRED to keep track of every secret they've ever used, so that they can distinguish between failed MACs and expired cookies for very old cookies? Should that be relaxed a bit to let implementations only store moderately recent secrets? (nit) Section 12.2.3 says "Regardless of where confidentiality is provided, the Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] SHOULD be used for key management." That makes sense for ESP, but is it intended to apply to DTLS too? (DTLS is mentioned earlier in the same section.) P.S. This was a very long document, so I ended up just skimming a bunch of the parts that I guessed were less likely to be relevant to security. Let me know if there are any particular sections I should take a closer look at. From nobody Mon Oct 11 20:30:49 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FD13A0CB3; Mon, 11 Oct 2021 20:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 RdgUr05mPUA1; Mon, 11 Oct 2021 20:30:45 -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 AF80B3A0CB0; Mon, 11 Oct 2021 20:30:41 -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 19C3UUi1021832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Oct 2021 23:30:38 -0400 Date: Mon, 11 Oct 2021 20:30:29 -0700 From: Benjamin Kaduk To: David Mandelberg Cc: secdir@ietf.org, iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org Message-ID: <20211012033029.GZ4103@kduck.mit.edu> References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2021 03:30:48 -0000 Hi David, Thanks for the review! On Mon, Oct 11, 2021 at 10:12:10PM -0400, David Mandelberg 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. > > The summary of the review is Ready with nits. > > (nit) Section 2.3 describes MACs as "based on cryptographic hash > functions using a secret key". If the intent is to limit this to MACs > that use cryptographic hash functions, I'd suggest using the term HMAC > instead of MAC. If not, I think there are other MAC algorithms that > don't use hashes. This is a very good point to raise about the precise definition of MACs, though I think HMAC is not going to be quite right either even for the hash-based case. A MAC is inherently going to involve a secret key; otherwise it would just be a checksum. But HMAC is not the only game in town for hash-based MACs (e.g., KMAC), and cipher-based MACs like CMAC are also defined. I think we will need the authors to help clarify whether the fully general MAC is the appropriate definition or a more-specific subset is intended. -Ben From nobody Mon Oct 11 20:48:42 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2143A0CBB for ; Mon, 11 Oct 2021 20:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=mandelberg.org header.b=4/TZpNL9; dkim=pass (2048-bit key) header.d=mandelberg.org header.b=Tg5HlV4c 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 jR0_Ye3mEwG6 for ; Mon, 11 Oct 2021 20:48:29 -0700 (PDT) Received: from mail-ua1-x963.google.com (mail-ua1-x963.google.com [IPv6:2607:f8b0:4864:20::963]) (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 B92563A0CBA for ; Mon, 11 Oct 2021 20:48:29 -0700 (PDT) Received: by mail-ua1-x963.google.com with SMTP id r17so7879963uaf.8 for ; Mon, 11 Oct 2021 20:48:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:dkim-signature:dkim-signature:subject:to:cc :references:from:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=YqeO6ER73qRvC7kzVC7zWpMD9ZEEPZdsx/zgrjn6J1M=; b=bWsYVdS+SCaA6wmF0tKeDt/UmsKRFqGSIt6TkycFJUQ0xg2LExB8y3TFJixDH7FLow Tj8iDTeRMErzSpUMLLY1MsfneXibzvUDJPQi1QQf2Gi0eAmsJvJ0kqtRFw6I19mt0dAQ 09CSqISA5PZT8qu/5dlEvvEx83pt94ouak2q1zrwa3hQFgpXc2sz1KIJqlasrjqO8+/F ZJTZUk4MhIh4IcoRgQiQHNarJDV5RHWSM/E42rOt+eGCah2iOPUwzH9QMgZe/TK8utKp 5h+j+zogKhc0JX/pWDNzEPw8LDRVQUlx6f6y7tXr5W7UafCqvKbcDR5JVve0DiiOTq1m gyVA== X-Gm-Message-State: AOAM53378AA8TIon9GrfFBk74qoIhYecNlk/fThY4QnTCwm+QQilJt/2 zUuEa7lAUGl5fGxBk29xv6FASZUzPQ0uBqcX5KXydMJVfrs5GQ== X-Google-Smtp-Source: ABdhPJx5gyi6tEaMBySCq5fXxOaf+F0eH+V2BJdmLaU1J35HCpCY2WTZDX2A4D4CUE6Ogru2zi3shHosCQ79 X-Received: by 2002:a67:e19c:: with SMTP id e28mr28274872vsl.38.1634010507902; Mon, 11 Oct 2021 20:48:27 -0700 (PDT) Received: from mail-outbound-e14cf917.virgo.mandelberg.org (pool-74-104-157-60.bstnma.fios.verizon.net. [74.104.157.60]) by smtp-relay.gmail.com with ESMTPS id g20sm2990549vsp.5.2021.10.11.20.48.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Oct 2021 20:48:27 -0700 (PDT) X-Relaying-Domain: mandelberg.org DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=mandelberg.org; i=@mandelberg.org; q=dns/txt; s=mail-outbound-e14cf917-07914516; t=1634010507; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : from; bh=sfMRZEl4B8zgbY9D6rAXiMVFEY6nw/uGQ64G2bGG+aY=; b=4/TZpNL9UQxJSqcPvW03aoEC/DlnMLHfHgkT1/bhZPEtxEGMHtC+TzpLKjJLi0kiZ1/6Y UL+sVR/K4FtNcXSBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; i=@mandelberg.org; q=dns/txt; s=mail-outbound-e14cf917-b7c648a2; t=1634010507; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : from; bh=sfMRZEl4B8zgbY9D6rAXiMVFEY6nw/uGQ64G2bGG+aY=; b=Tg5HlV4c0J0t6H2v+l1mzm8Wes4rRJSmHnjEWRH0gt866mN83zDKpz3DNU1HjOym1ZlZF LtLxm5PKbWJ6mL+UrFU/Z/WpcXBlYbb+ap85B+t1LNDJy5Y7dpHCJHc7Jqh3Sn5iLLZ3sdr z9rkkXAp4a8IfaTw4vNLys4WlRWoff0Dt5+tQEnHtdjtbQRNq2oDMVxwI8+SVoaxrEXJl/0 KJtpE2hS4dig104BKc1sOWFaBuUv2s0vz/DfU77AbbLkdHc6hn5q4L0o9AK974O8r3obCLy 6xmsPmnnYxMEAn9B930Jxu1qhNC9oTw9kQNnqc06rl7kM9nPSCAaGOYI7TjA== Received: from [IPv6:fde5:2b79:35f0:2::14e] (solaria.virgo.mandelberg.org [IPv6:fde5:2b79:35f0:2::14e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by mail-outbound-e14cf917.virgo.mandelberg.org (Postfix) with ESMTPSA id 4HT1pz2Yxrz10Zt; Tue, 12 Oct 2021 03:48:27 +0000 (UTC) To: Benjamin Kaduk Cc: secdir@ietf.org, iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> <20211012033029.GZ4103@kduck.mit.edu> From: David Mandelberg Message-ID: <387cc9b6-bc04-581f-897d-64438838f560@mandelberg.org> Date: Mon, 11 Oct 2021 23:48:27 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211012033029.GZ4103@kduck.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2021 03:48:34 -0000 Op 11-10-2021 om 23:30 schreef Benjamin Kaduk: > Hi David, > > Thanks for the review! > > On Mon, Oct 11, 2021 at 10:12:10PM -0400, David Mandelberg 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. >> >> The summary of the review is Ready with nits. >> >> (nit) Section 2.3 describes MACs as "based on cryptographic hash >> functions using a secret key". If the intent is to limit this to MACs >> that use cryptographic hash functions, I'd suggest using the term HMAC >> instead of MAC. If not, I think there are other MAC algorithms that >> don't use hashes. > > This is a very good point to raise about the precise definition of MACs, > though I think HMAC is not going to be quite right either even for the > hash-based case. > > A MAC is inherently going to involve a secret key; otherwise it would just > be a checksum. But HMAC is not the only game in town for hash-based MACs > (e.g., KMAC), and cipher-based MACs like CMAC are also defined. I think we > will need the authors to help clarify whether the fully general MAC is the > appropriate definition or a more-specific subset is intended. Oh good point. I didn't realize there were MAC algorithms other than HMAC that used hashes, but that makes sense. Thinking about it more, does it even have to be a MAC? It's always verified by the same party than generated it, and it's opaque to everybody else, right? So MAC makes perfect sense today when MACs are generally much faster than asymmetric signatures (I think?), but couldn't it just as easily be an asymmetric signature if the only important property is that the party that generated it needs to be able to verify it? (I think it's fine to specify it as a MAC, I'm just curious if I correctly understood the properties it needs.) From nobody Tue Oct 12 02:00:35 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A773A123E; Tue, 12 Oct 2021 02:00:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: Cc: draft-zern-webp.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163402922463.7801.2056374070276333357@ietfa.amsl.com> Reply-To: Tero Kivinen Date: Tue, 12 Oct 2021 02:00:24 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-zern-webp-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2021 09:00:33 -0000 Reviewer: Tero Kivinen Review result: Has Issues 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 request webp image format media registration and its security considerations section do mention some of the security issues (buffer overruns and uninitialized data usage). Unfortunately graphics libraries have really bad track record for security, simple search lists about 200-300 CVEs for all widely used graphics formats (jpeg, png, gif), and even some for webp already (for which there is reference in security considerations section). Those issues include integer overflows, resource exhaustion of memory and other resources (file descriptors etc), extended resource usage (very long running time), out-of-bounds writes for both to heap and stack, null pointer references, very large image sizes, zero image sizes and zero width and/or height images, information leaks from the decoder (memory layout, obtaining potentially sensitive information), arbitrary memory writes, memory corruptions etc. As graphics libraries are used in so many places and used in ways where they can cause severe security issues both on clients (web browsers, email clients) and servers (for example when automatically converting uploaded images from one format to another format on servers) the security issues in them are widespread, i.e., not only limited to the image processing applications themselves. Adding the attack surface even more by adding yet another graphics format with new libraries will make situation even worse. Also the traditionally graphics libraries have not been written as being security sensitive, but in the modern systems they are as integral to the security than the crypto libraries etc. Adding bit more warnings about those issues to the security considerations section would be useful. From nobody Tue Oct 12 13:46:49 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F413A087C for ; Tue, 12 Oct 2021 13:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.098 X-Spam-Level: X-Spam-Status: No, score=-18.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 H0k2YKWqM3q8 for ; Tue, 12 Oct 2021 13:38:03 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 454183A0878 for ; Tue, 12 Oct 2021 13:38:03 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id u18so1956277lfd.12 for ; Tue, 12 Oct 2021 13:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ehidneH+myDuf7bWUcBqhYmOZ83MpiPdqDOEAEvH1lc=; b=qf2xyZirUhmW60V2pEy1/CqTDRjJAeMXUwY4xJTjn5mQpTDZRqkFRHOcOXZTvHDYnu bztlxmJLoL63PKbWsU9o4nr92HblA5x7J6CdvCz+hnFa9kXhh+oWah/Hwo2ejGdEXmxr 31DnSIZHgj3Q9eSk9OX+C16GwCyhdSXKhYXsMaJuke5sLJPRHbHgVXvcsTm9ayOL869m oCywOOWDoD3w/fM9kEFCwWbObfA9BmOc64NwtR4Z8xtmu/TmGJ9HU3QKTbrYQ4Cp/AuY VSQ66WE9LjtDMSGR9nm8Z+1lllIsmI9hcjkc/MlwMoIJLOjNQ+nCZ0HhkS/brxVGobRs W8ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ehidneH+myDuf7bWUcBqhYmOZ83MpiPdqDOEAEvH1lc=; b=JdD8UTtMx23s788vwgDDrxGWPi+2TqtBsea2jJE/i1KTRu/Xtfca++3lj+AC34hulL JPGlpMEWBupS8SYM14hCz2UltC7o/hT4al/kdC5Vi9CHEK5ZYhPRJNd0HSG29o1FnkiD sKOlsu4na46BVRVwW/h6NM1OYHWNI6kFWVsb/pQEC2d2Zc5VY8BtMMnGltuyDLCJChhl eisTYjM+ZjqL93b2S7acJ0lympoFhKFS7Ad+5jy3kqUwB+/K0Ghq2tt9ZCTIQKyz1Ils 3u9lpr/L8pjrddO5aMh+qwWjHwendeUZZgLuFw8TAQnG5BbZ6Iw1qzZS43X4o8W+Na8J nLdg== X-Gm-Message-State: AOAM5309rCGr2jNtwC1dlC+Y+RiDwc4objZcqXt0qr7ID+Ml5mz3/67s 7Tcn3oXSf19ffkFibX8Q4kxO/qd54DDntuoBS5Ynug== X-Google-Smtp-Source: ABdhPJwUC/l9WiB42iqxAu3FUCCEyiUVJ8Exd+0VC9UoQg5gJq5g5rHeqKfA7XU4Ys293bWbAR1vJvAxrqgfAhFPEL4= X-Received: by 2002:a05:6512:14d:: with SMTP id m13mr34712333lfo.205.1634071079204; Tue, 12 Oct 2021 13:37:59 -0700 (PDT) MIME-Version: 1.0 References: <163402922463.7801.2056374070276333357@ietfa.amsl.com> In-Reply-To: <163402922463.7801.2056374070276333357@ietfa.amsl.com> From: James Zern Date: Tue, 12 Oct 2021 13:37:48 -0700 Message-ID: To: Tero Kivinen Cc: secdir@ietf.org, draft-zern-webp.all@ietf.org, last-call@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Tue, 12 Oct 2021 13:46:47 -0700 Subject: Re: [secdir] Secdir last call review of draft-zern-webp-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2021 20:38:08 -0000 Hi Tero, On Tue, Oct 12, 2021 at 2:00 AM Tero Kivinen via Datatracker wrote: > > Reviewer: Tero Kivinen > Review result: Has Issues > > 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 request webp image format media registration and its security > considerations section do mention some of the security issues (buffer overruns > and uninitialized data usage). Unfortunately graphics libraries have really bad > track record for security, simple search lists about 200-300 CVEs for all > widely used graphics formats (jpeg, png, gif), and even some for webp already > (for which there is reference in security considerations section). > > Those issues include integer overflows, resource exhaustion of memory and other > resources (file descriptors etc), extended resource usage (very long running > time), out-of-bounds writes for both to heap and stack, null pointer > references, very large image sizes, zero image sizes and zero width and/or > height images, information leaks from the decoder (memory layout, obtaining > potentially sensitive information), arbitrary memory writes, memory corruptions > etc. > > As graphics libraries are used in so many places and used in ways where they > can cause severe security issues both on clients (web browsers, email clients) > and servers (for example when automatically converting uploaded images from one > format to another format on servers) the security issues in them are > widespread, i.e., not only limited to the image processing applications > themselves. > > Adding the attack surface even more by adding yet another graphics format with > new libraries will make situation even worse. Also the traditionally graphics > libraries have not been written as being security sensitive, but in the modern > systems they are as integral to the security than the crypto libraries etc. > > Adding bit more warnings about those issues to the security considerations > section would be useful. > Thanks for the review. As you mention it can be tough to have an exhaustive list, but I can incorporate your suggestions into another draft after the last period is complete. I posted version 4 during this process, but learned that the doc should remain mostly stable for the period so I'll keep any edits local for now. > From nobody Thu Oct 14 07:46:42 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFDD3A09EF; Thu, 14 Oct 2021 07:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.836 X-Spam-Level: X-Spam-Status: No, score=-0.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_SOFTFAIL=0.665] 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 Clwg0d0YV7bB; Thu, 14 Oct 2021 07:46:35 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E864A3A09CE; Thu, 14 Oct 2021 07:46:33 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:88a8:6c74:69c:b2f8]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 89D4B721BE012; Thu, 14 Oct 2021 16:46:27 +0200 (CEST) From: tuexen@fh-muenster.de Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9865A3B0-62D9-41F5-8B60-0E2364A99804"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Thu, 14 Oct 2021 16:46:27 +0200 In-Reply-To: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> Cc: secdir@ietf.org, iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org To: David Mandelberg References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 14:46:41 -0000 --Apple-Mail=_9865A3B0-62D9-41F5-8B60-0E2364A99804 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > \On 12. Oct 2021, at 04:12, David Mandelberg = wrote: >=20 > 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. Hi David, thank you very much for your review. Please see my comments in-line. Best regards Michael >=20 > The summary of the review is Ready with nits. >=20 > (nit) Section 2.3 describes MACs as "based on cryptographic hash = functions using a secret key". If the intent is to limit this to MACs = that use cryptographic hash functions, I'd suggest using the term HMAC = instead of MAC. If not, I think there are other MAC algorithms that = don't use hashes. I can change it to HMAC, if that is a better term. The description you = are citing ends with: SCTP uses this term with the same meaning as in [RFC2104]. The title of RFC 2104 is "HMAC: Keyed-Hashing for Message = Authentication". Just let me know. >=20 > (nit) The description of Chunk Length in Section 3.2 seems a bit = complicated. (Not a lot complicated, just a bit.) I'd expect at least = occasional security issues from incorrect implementations in programming = languages that don't enforce in-bounds memory access. I'm guessing it's = either too late to simplify the field, or there are good reasons for it = to be the way it is? Are there any lessons learned by existing = implementations that would be worth mentioning to help future = implementors avoid issues with out-of-bounds memory access here? ("No" = is a fine answer if this turns out to not have been a problem.) In RFC 2960 was an issue how to handle the padding of the last parameter = in a chunk. Should it be considered the padding of the parameter (and therefore included in = the length of the chunk) or considered the padding of the chunk (and therefore not included in = the length of the chunk). This was addressed RFC 4960 by: https://datatracker.ietf.org/doc/html/rfc4460#section-2.3 Besides of that I'm aware of (fixed) bugs in implementations, which were = caused by not checking the length field. However, the problem was that the check was = not done, not that it was not clear which values should be checked. So I guess this can not = be improved here. However, if you can suggest a wording which describes things better or = in a clearer way, I'm open to include that. >=20 > (nit) Section 5.1.5, bullet point 4 says 'If the elapsed time is = longer than the lifespan carried in the State Cookie, then ... the = endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error cause = to the peer endpoint.' That's different from the behavior if the MAC = fails in bullet point 2. Does that mean that endpoints are REQUIRED to = keep track of every secret they've ever used, so that they can = distinguish between failed MACs and expired cookies for very old = cookies? Should that be relaxed a bit to let implementations only store = moderately recent secrets? This is exactly how it is implemented in FreeBSD. There are two keys = (the current and the one before). If a COOKIE which is way too old, it would just be dropped. The current = lifetime of a secret is 60 minutes, and the maximum time you can report in the stale cookie is about 70 = minutes. So what about using:
  • Compute a MAC using the information carried in the State Cookie = and the secret key. The timestamp in the State Cookie MAY be used to determine which secret key to use. If secrets are kept only for a limited amount of time and the secret key = to use is not available anymore, the packet containing the COOKIE ECHO chunk = MUST be silently discarded. >=20 > (nit) Section 12.2.3 says "Regardless of where confidentiality is = provided, the Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] = SHOULD be used for key management." That makes sense for ESP, but is it = intended to apply to DTLS too? (DTLS is mentioned earlier in the same = section.) The reference to DTLS was added recently. You are right, the IKE = reference should only apply to ESP. I changed the text to read: Regardless of where confidentiality is provided, the Internet Key Exchange Protocol version 2 (IKEv2) SHOULD be = used for key management of ESP. >=20 > P.S. This was a very long document, so I ended up just skimming a = bunch of the parts that I guessed were less likely to be relevant to = security. Let me know if there are any particular sections I should take = a closer look at. --Apple-Mail=_9865A3B0-62D9-41F5-8B60-0E2364A99804 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTEw MTQxNDQ2MjdaMC8GCSqGSIb3DQEJBDEiBCBZlQVnQR2X/qpgRDl0aqL1vE5KeDpRFIBH/XtptZ/7 TzCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQELBQAEggEAIzqCCkEUGVc3oNWhEivnwFeMwCvu ICQwkJYwPq2qxsGJVzyN75WA/B5hm0nYR7Y1R5OZHiu8a2PUMcdltwSSeqPo5bEc5whflM2eAL8+ zxNH7wbkJNFQtHtsfX9xq1GixwcXVwd8an7W0a6W1F7kmJ61e0C+NOO+thQ2Vz7KMCsCP4QbKi8D 0gIX3GB5kjaFsNWi3Ea3RauQmP3UhV9UqvObplIuL202pMiCsoeUv2HXJhHSdaAIJj8AvGxHqsBC h8t7OG7K7fdE9d7ZoZBLLBmF9rlwATh4usZrAmPxOifEySueB4m1wtgTAK1ItIuCDACJRyN1P5hH /aNyiJR4mwAAAAAAAA== --Apple-Mail=_9865A3B0-62D9-41F5-8B60-0E2364A99804-- From nobody Thu Oct 14 07:53:32 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5BE3A0A0A; Thu, 14 Oct 2021 07:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.481 X-Spam-Level: X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 ku9Rzm4X3RnR; Thu, 14 Oct 2021 07:53:03 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E123A0AAC; Thu, 14 Oct 2021 07:53:02 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:88a8:6c74:69c:b2f8]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id C3A38721BE012; Thu, 14 Oct 2021 16:52:56 +0200 (CEST) From: tuexen@fh-muenster.de Message-Id: <7F84246C-3A71-4BCA-8DC2-FF0105DA30CD@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_10F09FDB-D123-4999-8B8B-C997F93C9C14"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Thu, 14 Oct 2021 16:52:56 +0200 In-Reply-To: <20211012033029.GZ4103@kduck.mit.edu> Cc: David Mandelberg , secdir@ietf.org, iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org To: Benjamin Kaduk References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> <20211012033029.GZ4103@kduck.mit.edu> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 14:53:09 -0000 --Apple-Mail=_10F09FDB-D123-4999-8B8B-C997F93C9C14 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On 12. Oct 2021, at 05:30, Benjamin Kaduk wrote: > > Hi David, > > Thanks for the review! > > On Mon, Oct 11, 2021 at 10:12:10PM -0400, David Mandelberg 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. >> >> The summary of the review is Ready with nits. >> >> (nit) Section 2.3 describes MACs as "based on cryptographic hash >> functions using a secret key". If the intent is to limit this to MACs >> that use cryptographic hash functions, I'd suggest using the term HMAC >> instead of MAC. If not, I think there are other MAC algorithms that >> don't use hashes. > > This is a very good point to raise about the precise definition of MACs, > though I think HMAC is not going to be quite right either even for the > hash-based case. > > A MAC is inherently going to involve a secret key; otherwise it would just > be a checksum. But HMAC is not the only game in town for hash-based MACs > (e.g., KMAC), and cipher-based MACs like CMAC are also defined. I think we > will need the authors to help clarify whether the fully general MAC is the > appropriate definition or a more-specific subset is intended. Hi Benjamin, the usecase is: An endpoint has some information (the cookie) it sends to its peer. The peer will send it back. The endpoint must be able to check that the peer did not modify the cookie. There is no requirement on confidentiality. In FreeBSD, we use am HMAC for it. Best regards Michael > > -Ben --Apple-Mail=_10F09FDB-D123-4999-8B8B-C997F93C9C14 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTEw MTQxNDUyNTZaMC8GCSqGSIb3DQEJBDEiBCA60/+sIPhXkZgrSsTF9eD44YjybtMMP2uQhb5nS51Y gTCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQELBQAEggEApXYPPJ5XRT7LTGtrn2PBvJkfTfR9 hofJd2n7k9xmz/vvaQklZ0OWn+qOJQPaexhOC8i9L3FFlHWSJ9K8ypfkfNxW824e+2pVC2az7JWo IEBTu5Om48iqXLXzLgVJwPaXBYHna6o6j3B90fBsAYp4XizGWGhfAWu2z9icAalTf4mjqNWtcWSM Fel2q9gD7aiqwlbHmvmMLnJ5A6JfSQEZpkV1IB/ERyzzSD+t338lOzyWT8lRH99pioLM/HmwMs3h seo/qkRL444jI1d7AOv+1hdZkujnButITgw81kGlCdrFGT0xCfaazi17DY9BWCXNQVEbqt1X0DTu 4GU35zE2yQAAAAAAAA== --Apple-Mail=_10F09FDB-D123-4999-8B8B-C997F93C9C14-- From nobody Thu Oct 14 10:57:26 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC243A17AD for ; Thu, 14 Oct 2021 10:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=mandelberg.org header.b=iYahcFGX; dkim=pass (2048-bit key) header.d=mandelberg.org header.b=rB4vAgS1 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 UQ0NQXsNKlkQ for ; Thu, 14 Oct 2021 10:57:18 -0700 (PDT) Received: from mail-oi1-x264.google.com (mail-oi1-x264.google.com [IPv6:2607:f8b0:4864:20::264]) (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 4FB583A17AA for ; Thu, 14 Oct 2021 10:57:18 -0700 (PDT) Received: by mail-oi1-x264.google.com with SMTP id e63so9489471oif.8 for ; Thu, 14 Oct 2021 10:57:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:dkim-signature:dkim-signature:subject:to:cc :references:from:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=dZ6UYMF4qxq8B5kecVjkGyH5Jwc/xy6CZhJs1yDqve4=; b=14ehh4HGpP/Icva7IS5C0fEeRcTOz3ovWFvl44TMIlHzZTbPkM4cCYwn2C++OfM6Z7 xvZJnpetHHMc17hAYl9th++CsrjlWRb9RaMrs4wGY0N8MpiIDlBkG/9GEDHndKsrm8N5 H65XUsZv/d8isWQbBAH00mO6HJSHG9980VGZ0Qa/y76NcP0GPu8Q+Eae6rT/Vs48Viwt ExxYXY/r25GYNyFZ5eeAzEAD2dQ1Pj1mQoD6yCdz0P3YYC8LzGBjdEhBXTNXzWEb57Gw n8h3VPIik205yj8GP+Ma/RGw/ToXPnTaWR44iuJxDtAfQkXqcIc22H5XEvJkNEj/4v1M XZbg== X-Gm-Message-State: AOAM533BmbetvJ5EhuBE3ildyR2l0+rloWar7wIO6uRnM3uzduETXvLa Log83uvyAgP01Jpz1brSlO5I7lv7dClgA1GgD1FLyJN48cR5sg== X-Google-Smtp-Source: ABdhPJy1z2J6ijOnYi2m3AUb036i/2iKr94f+vQ2takAxbBfWGAAnWouq3UJqzNVLksl28Y7biGFIbveJ5XY X-Received: by 2002:a54:4381:: with SMTP id u1mr5140002oiv.49.1634234237090; Thu, 14 Oct 2021 10:57:17 -0700 (PDT) Received: from mail-outbound-e14cf917.virgo.mandelberg.org (pool-74-104-157-60.bstnma.fios.verizon.net. [74.104.157.60]) by smtp-relay.gmail.com with ESMTPS id v13sm1058307oot.10.2021.10.14.10.57.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Oct 2021 10:57:17 -0700 (PDT) X-Relaying-Domain: mandelberg.org DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=mandelberg.org; i=@mandelberg.org; q=dns/txt; s=mail-outbound-e14cf917-07914516; t=1634234236; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : from; bh=gtEuz3AEO/xScVqvQ17cD3CK1IxAciWF4KGiLFmUIU4=; b=iYahcFGXNrMNszssTYGR0hf5R4DUBVu3rjudW9Kbk97h/vbkJHK1QY9BiDZROtM3/LgLS rHg3phrlD1yWd5AAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; i=@mandelberg.org; q=dns/txt; s=mail-outbound-e14cf917-b7c648a2; t=1634234236; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : from; bh=gtEuz3AEO/xScVqvQ17cD3CK1IxAciWF4KGiLFmUIU4=; b=rB4vAgS18skQqHkgzdQxYNTEXunWtp+pJtfrf1oolhonKqZgKcbkkrOva7XhHgFT3njfl 9bU5rVk2qsuz8uidFAj7wZlE3NTsWe/h2lhIRZzJEjEc5mxIWAn5Bo5t6kF94W/lKhry3Ph kFlHxEMKcumfi5IegLxrD4CnGK1QN6IO1+N/V4AbN2p8wUcKZpoEwOWn0oju5srtN5zuzBq 50YNxOc3l5SEA2/EwmRREVGi41fKIjeYu51O+yOC9tKNKOC/oOr+Z/erA5smmcNNqFKi8SM 5I24iiYJcK9rH0eKAPm6YxVjAfYjVKX7mj68BgtCAAiYmOXMLaNDf6bbIugA== Received: from [IPv6:fde5:2b79:35f0:2::14e] (solaria.virgo.mandelberg.org [IPv6:fde5:2b79:35f0:2::14e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by mail-outbound-e14cf917.virgo.mandelberg.org (Postfix) with ESMTPSA id 4HVcYS3N8qz10Zs; Thu, 14 Oct 2021 17:57:16 +0000 (UTC) To: tuexen@fh-muenster.de Cc: secdir@ietf.org, iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> From: David Mandelberg Message-ID: Date: Thu, 14 Oct 2021 13:57:16 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 17:57:24 -0000 Op 14-10-2021 om 10:46 schreef tuexen@fh-muenster.de: >> \On 12. Oct 2021, at 04:12, David Mandelberg 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. > Hi David, > > thank you very much for your review. Please see my comments in-line. > > Best regards > Michael >> >> The summary of the review is Ready with nits. >> >> (nit) Section 2.3 describes MACs as "based on cryptographic hash functions using a secret key". If the intent is to limit this to MACs that use cryptographic hash functions, I'd suggest using the term HMAC instead of MAC. If not, I think there are other MAC algorithms that don't use hashes. > I can change it to HMAC, if that is a better term. The description you are citing ends with: > SCTP uses this term with the same meaning as in [RFC2104]. > The title of RFC 2104 is "HMAC: Keyed-Hashing for Message Authentication". > Just let me know. From a security perspective, there are multiple good options for MAC algorithms to use here, including some HMAC algorithms. (I don't know enough about MAC algorithms to be too much more specific.) From a standards perspective, I think the doc should be clear about what the requirements actually are. This seems like an unusual case, because there are no interoperability concerns as far as I can tell. (Except maybe length? Are there constraints on the length of the field?) I don't know what the right thing to do here is, but I'd lean towards 1) documenting the requirements for interoperability, 2) documenting the requirements for security, and 3) providing an example algorithm that implementations should use unless they have a reason to pick something different. Do other people think that's a good way to go? Or should it be kept simpler and just recommend something specific? If it helps, here's some draft text of what I'm thinking: The State Cookie MUST include information (e.g., a MAC or digital signature) that the sender of the INIT ACK chunk can later use to cryptographically authenticate the State Cookie. It MUST NOT cause the size of the State Cookie to exceed X bytes in total, and it SHOULD provide at least Y bits of security. For example, the State Cookie's authenticity protection could use Z. I'm guessing Y = 128 is reasonable. For Z, I'm guessing HMAC-SHA-256 with some specific key length (256 bits?) but like I said above, I don't know enough about MAC algorithms to provide good guidance here. None of that really solves the terminology problem though. "State Cookie's authenticity protection" is a bit verbose. Given the performance advantages of MACs over digital signatures, maybe use the term MAC throughout, with a note in one place that a digital signature could also be used if an implementation has a reason to? >> (nit) The description of Chunk Length in Section 3.2 seems a bit complicated. (Not a lot complicated, just a bit.) I'd expect at least occasional security issues from incorrect implementations in programming languages that don't enforce in-bounds memory access. I'm guessing it's either too late to simplify the field, or there are good reasons for it to be the way it is? Are there any lessons learned by existing implementations that would be worth mentioning to help future implementors avoid issues with out-of-bounds memory access here? ("No" is a fine answer if this turns out to not have been a problem.) > In RFC 2960 was an issue how to handle the padding of the last parameter in a chunk. Should > it be considered the padding of the parameter (and therefore included in the length of the chunk) > or considered the padding of the chunk (and therefore not included in the length of the chunk). > > This was addressed RFC 4960 by: > https://datatracker.ietf.org/doc/html/rfc4460#section-2.3 > > Besides of that I'm aware of (fixed) bugs in implementations, which were caused by not > checking the length field. However, the problem was that the check was not done, not that > it was not clear which values should be checked. So I guess this can not be improved here. > > However, if you can suggest a wording which describes things better or in a clearer way, > I'm open to include that. Nope, feel free to keep it as is. And thanks for the background. >> (nit) Section 5.1.5, bullet point 4 says 'If the elapsed time is longer than the lifespan carried in the State Cookie, then ... the endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer endpoint.' That's different from the behavior if the MAC fails in bullet point 2. Does that mean that endpoints are REQUIRED to keep track of every secret they've ever used, so that they can distinguish between failed MACs and expired cookies for very old cookies? Should that be relaxed a bit to let implementations only store moderately recent secrets? > This is exactly how it is implemented in FreeBSD. There are two keys (the current and the one before). > If a COOKIE which is way too old, it would just be dropped. The current lifetime of a secret is 60 minutes, > and the maximum time you can report in the stale cookie is about 70 minutes. > > So what about using: > >
  • Compute a MAC using the information carried in the State Cookie and > the secret key. > The timestamp in the State Cookie MAY be used to determine which secret > key to use. > If secrets are kept only for a limited amount of time and the secret key to use > is not available anymore, the packet containing the COOKIE ECHO chunk MUST be > silently discarded. Sounds good. >> (nit) Section 12.2.3 says "Regardless of where confidentiality is provided, the Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] SHOULD be used for key management." That makes sense for ESP, but is it intended to apply to DTLS too? (DTLS is mentioned earlier in the same section.) > The reference to DTLS was added recently. You are right, the IKE reference should only apply to ESP. > I changed the text to read: > Regardless of where confidentiality is provided, the Internet Key > Exchange Protocol version 2 (IKEv2) SHOULD be used for > key management of ESP. Sounds good. >> >> P.S. This was a very long document, so I ended up just skimming a bunch of the parts that I guessed were less likely to be relevant to security. Let me know if there are any particular sections I should take a closer look at. > From nobody Thu Oct 14 12:31:40 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA6E3A17C7; Thu, 14 Oct 2021 12:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.836 X-Spam-Level: X-Spam-Status: No, score=-0.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_SOFTFAIL=0.665] 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 O3I2Qb0BKyai; Thu, 14 Oct 2021 12:31:31 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5D193A17D1; Thu, 14 Oct 2021 12:31:29 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:88a8:6c74:69c:b2f8]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 3D9467220B804; Thu, 14 Oct 2021 21:31:24 +0200 (CEST) From: tuexen@fh-muenster.de Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_E8080D07-AB87-49BC-968A-B50478AFC542"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Thu, 14 Oct 2021 21:31:23 +0200 In-Reply-To: Cc: secdir@ietf.org, iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org To: David Mandelberg References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 19:31:38 -0000 --Apple-Mail=_E8080D07-AB87-49BC-968A-B50478AFC542 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 14. Oct 2021, at 19:57, David Mandelberg = wrote: >=20 > Op 14-10-2021 om 10:46 schreef tuexen@fh-muenster.de: >>> \On 12. Oct 2021, at 04:12, David Mandelberg = wrote: >>>=20 >>> 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. >> Hi David, >> thank you very much for your review. Please see my comments in-line. >> Best regards >> Michael >>>=20 >>> The summary of the review is Ready with nits. >>>=20 >>> (nit) Section 2.3 describes MACs as "based on cryptographic hash = functions using a secret key". If the intent is to limit this to MACs = that use cryptographic hash functions, I'd suggest using the term HMAC = instead of MAC. If not, I think there are other MAC algorithms that = don't use hashes. >> I can change it to HMAC, if that is a better term. The description = you are citing ends with: >> SCTP uses this term with the same meaning as in [RFC2104]. >> The title of RFC 2104 is "HMAC: Keyed-Hashing for Message = Authentication". >> Just let me know. >=20 > =46rom a security perspective, there are multiple good options for MAC = algorithms to use here, including some HMAC algorithms. (I don't know = enough about MAC algorithms to be too much more specific.) >=20 > =46rom a standards perspective, I think the doc should be clear about = what the requirements actually are. This seems like an unusual case, = because there are no interoperability concerns as far as I can tell. = (Except maybe length? Are there constraints on the length of the field?) = I don't know what the right thing to do here is, but I'd lean towards 1) = documenting the requirements for interoperability, 2) documenting the = requirements for security, and 3) providing an example algorithm that = implementations should use unless they have a reason to pick something = different. Do other people think that's a good way to go? Or should it = be kept simpler and just recommend something specific? >=20 > If it helps, here's some draft text of what I'm thinking: You are suggesting to add this to section 5.1.3, I guess. So are you = suggesting to remove the MAC entry from Section 2.3? >=20 > The State Cookie MUST include information (e.g., a MAC or digital = signature) that the sender of the INIT ACK chunk can later use to = cryptographically authenticate the State Cookie. It MUST NOT cause the = size of the State Cookie to exceed X bytes in total, and it SHOULD = provide at least Y bits of security. For example, the State Cookie's = authenticity protection could use Z. Well, we are not that specific about size, especially regarding Y. We = only mention: An implementation SHOULD make the cookie as small as possible to ensure = interoperability. This is basically about trying that the packet containing the INIT-ACK = does not need to be fragmented at the IP layer. If you think, I can add a statement about the length of the key being = used in the operation. >=20 > I'm guessing Y =3D 128 is reasonable. For Z, I'm guessing HMAC-SHA-256 = with some specific key length (256 bits?) but like I said above, I don't = know enough about MAC algorithms to provide good guidance here. We actually left that open. Since you compute the cookie when responding = to an INIT chunk, it is also important that you don't spend too many cycles on generating it. How you = balance the level of protection against the cookie modification and protection against the = CPU load during an INIT flood depends on the system, the application, and is left open. The cookie mechanism is used on the server side to avoid keeping state = before the server has validated that it communicates with the IP address it is thinking it = communicates with. So I'm not too concerned about this. But I follow any advice you are = giving... >=20 > None of that really solves the terminology problem though. "State = Cookie's authenticity protection" is a bit verbose. Given the = performance advantages of MACs over digital signatures, maybe use the = term MAC throughout, with a note in one place that a digital signature = could also be used if an implementation has a reason to? >=20 >>> (nit) The description of Chunk Length in Section 3.2 seems a bit = complicated. (Not a lot complicated, just a bit.) I'd expect at least = occasional security issues from incorrect implementations in programming = languages that don't enforce in-bounds memory access. I'm guessing it's = either too late to simplify the field, or there are good reasons for it = to be the way it is? Are there any lessons learned by existing = implementations that would be worth mentioning to help future = implementors avoid issues with out-of-bounds memory access here? ("No" = is a fine answer if this turns out to not have been a problem.) >> In RFC 2960 was an issue how to handle the padding of the last = parameter in a chunk. Should >> it be considered the padding of the parameter (and therefore included = in the length of the chunk) >> or considered the padding of the chunk (and therefore not included in = the length of the chunk). >> This was addressed RFC 4960 by: >> https://datatracker.ietf.org/doc/html/rfc4460#section-2.3 >> Besides of that I'm aware of (fixed) bugs in implementations, which = were caused by not >> checking the length field. However, the problem was that the check = was not done, not that >> it was not clear which values should be checked. So I guess this can = not be improved here. >> However, if you can suggest a wording which describes things better = or in a clearer way, >> I'm open to include that. >=20 > Nope, feel free to keep it as is. And thanks for the background. >>> (nit) Section 5.1.5, bullet point 4 says 'If the elapsed time is = longer than the lifespan carried in the State Cookie, then ... the = endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error cause = to the peer endpoint.' That's different from the behavior if the MAC = fails in bullet point 2. Does that mean that endpoints are REQUIRED to = keep track of every secret they've ever used, so that they can = distinguish between failed MACs and expired cookies for very old = cookies? Should that be relaxed a bit to let implementations only store = moderately recent secrets? >> This is exactly how it is implemented in FreeBSD. There are two keys = (the current and the one before). >> If a COOKIE which is way too old, it would just be dropped. The = current lifetime of a secret is 60 minutes, >> and the maximum time you can report in the stale cookie is about 70 = minutes. >> So what about using: >>
  • Compute a MAC using the information carried in the State = Cookie and >> the secret key. >> The timestamp in the State Cookie MAY be used to determine which = secret >> key to use. >> If secrets are kept only for a limited amount of time and the secret = key to use >> is not available anymore, the packet containing the COOKIE ECHO chunk = MUST be >> silently discarded. >=20 > Sounds good. >=20 >>> (nit) Section 12.2.3 says "Regardless of where confidentiality is = provided, the Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] = SHOULD be used for key management." That makes sense for ESP, but is it = intended to apply to DTLS too? (DTLS is mentioned earlier in the same = section.) >> The reference to DTLS was added recently. You are right, the IKE = reference should only apply to ESP. >> I changed the text to read: >> Regardless of where confidentiality is provided, the Internet Key >> Exchange Protocol version 2 (IKEv2) SHOULD = be used for >> key management of ESP. >=20 > Sounds good. >=20 >>>=20 >>> P.S. This was a very long document, so I ended up just skimming a = bunch of the parts that I guessed were less likely to be relevant to = security. Let me know if there are any particular sections I should take = a closer look at. --Apple-Mail=_E8080D07-AB87-49BC-968A-B50478AFC542 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTEw MTQxOTMxMjNaMC8GCSqGSIb3DQEJBDEiBCCErXOeLxZ2lIjRozKskDdJVlgfMeXxh6Z/7BQ5BdLs PDCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQELBQAEggEAgamC+qLUURMK6zkJUVI+l6zrf8Gr /+PK6wxxuvFERQRa7ORHpexH89/ezGxk4okHyzHuQ6NPhX80fdRf+AqoI85ehIs0lw5/SgpNpr0S ReTToRJ6GBcyJQWUbOiNUZZ/9qY84noWiFW2htsYROkOziro/Hm1hac3TZz3Q3Rp8xcAWExVFmfy K7SvYZLFKolWERjbcx9erOWH4m3+ump3k2zZy5eBRYsr/ZeIFK4VlEfA0M+o6iv6G6brVf2hdE/S v5KKq99j7qOhDSElUNtvjaql6aKPPICWnYWdMzq/wZtZRY/WP0Je1FzE7D649ozNew2k9YqV23Bt QXth8EEQ+gAAAAAAAA== --Apple-Mail=_E8080D07-AB87-49BC-968A-B50478AFC542-- From nobody Thu Oct 14 13:03:03 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3883C3A0B06; Thu, 14 Oct 2021 13:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 TCvs1W4J4ijP; Thu, 14 Oct 2021 13:02:38 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 C85B53A0954; Thu, 14 Oct 2021 13:02:37 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id r22so2864541uat.11; Thu, 14 Oct 2021 13:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FY+Iknm0W6pPcpFcc8DvD1vqn4QhXaMCiI7Q71f6iLw=; b=Kn0pTbrCJLjwlWl3QpcceOKHFa8Q51me4nSb0m70QfrdkNF61gGrsEpxWo24L6zLOg e0FQEKoP89yN2j8En+SUrDHu0Q7TuUPi+U4QpD2PA2xQwF/0PUYSWJqXXhzdjbK1eLln d7BpukFjiPgvadI7eErGCu5hgJtApYdkxja0XqST9nyZDV+ORFz/3f0QfYfd6NpV/Scs vtHa/z4a/yo2JkLSZ6lXhYAMKfSDo5co9z96GN1W3N/8XpXQF0o706XC2eHoJ96WXzYA Zx9ntr9mp7IfXk35RHlIT2YM8uRt/yOG8KhEpstgGANpBgKjwp//+WFvbTgHOuA8n1Yn iTgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FY+Iknm0W6pPcpFcc8DvD1vqn4QhXaMCiI7Q71f6iLw=; b=s+XFXCM5ckkmW6Zr8ny7iEKatyUuyk78uNjkoWiRpEUcwWCeWO/dIDRUCvJWTEis5P 6B5EeQ1ifpGEpMG254nuBT5XHM+sMA5wv6AEc9IuF4lt/hT/Y6BH1Vc7jq/d1onijYf+ z9NBCr8EiSrcxltwZPoWO+nZGv089PlKTagfFDT1/1vO45F8BxYldCGv/4qqwZHVLT24 qeWWirACDlvaYsiNxF6cbPsxSJwuVr6n8MZb0zS89KnDSu9tk14EIviBRSt7Rln7RGlM 8clreEIz/GtzYWIbzTO4OxMQN8dhQErSd20WS19fQUeV7DmOq8Pjd1tmprWHk/d2LC1F ou8g== X-Gm-Message-State: AOAM5325OboD53UDKSZZEwzc3ZSGIxkbOmsTwbLR+Yj1+bxjqpoWQpt4 IMUPC/YfbhjgXjU4c6NRBYqB83ojV8l9jtXxcFgN/T7o X-Google-Smtp-Source: ABdhPJzLPwjvVGMLhgK51ZwxA+aWDqDW3eN9FOEsBpZpO24vg4Cnj5gYi+d9IlZX9D0kLrB/mLtvWM0nEbqY3XKLnCU= X-Received: by 2002:ab0:5542:: with SMTP id u2mr9023009uaa.62.1634241755854; Thu, 14 Oct 2021 13:02:35 -0700 (PDT) MIME-Version: 1.0 References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> In-Reply-To: From: Martin Duke Date: Thu, 14 Oct 2021 13:02:24 -0700 Message-ID: To: Michael Tuexen Cc: David Mandelberg , secdir@ietf.org, The IESG , draft-ietf-tsvwg-rfc4960-bis.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000055ba4b05ce558f45" Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 20:02:44 -0000 --00000000000055ba4b05ce558f45 Content-Type: text/plain; charset="UTF-8" Admin note: is there a reason this review isn't in the datatracker? On Thu, Oct 14, 2021 at 12:31 PM wrote: > > On 14. Oct 2021, at 19:57, David Mandelberg > wrote: > > > > Op 14-10-2021 om 10:46 schreef tuexen@fh-muenster.de: > >>> \On 12. Oct 2021, at 04:12, David Mandelberg > 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. > >> Hi David, > >> thank you very much for your review. Please see my comments in-line. > >> Best regards > >> Michael > >>> > >>> The summary of the review is Ready with nits. > >>> > >>> (nit) Section 2.3 describes MACs as "based on cryptographic hash > functions using a secret key". If the intent is to limit this to MACs that > use cryptographic hash functions, I'd suggest using the term HMAC instead > of MAC. If not, I think there are other MAC algorithms that don't use > hashes. > >> I can change it to HMAC, if that is a better term. The description you > are citing ends with: > >> SCTP uses this term with the same meaning as in [RFC2104]. > >> The title of RFC 2104 is "HMAC: Keyed-Hashing for Message > Authentication". > >> Just let me know. > > > > From a security perspective, there are multiple good options for MAC > algorithms to use here, including some HMAC algorithms. (I don't know > enough about MAC algorithms to be too much more specific.) > > > > From a standards perspective, I think the doc should be clear about what > the requirements actually are. This seems like an unusual case, because > there are no interoperability concerns as far as I can tell. (Except maybe > length? Are there constraints on the length of the field?) I don't know > what the right thing to do here is, but I'd lean towards 1) documenting the > requirements for interoperability, 2) documenting the requirements for > security, and 3) providing an example algorithm that implementations should > use unless they have a reason to pick something different. Do other people > think that's a good way to go? Or should it be kept simpler and just > recommend something specific? > > > > If it helps, here's some draft text of what I'm thinking: > You are suggesting to add this to section 5.1.3, I guess. So are you > suggesting to remove the MAC entry from Section 2.3? > > > > The State Cookie MUST include information (e.g., a MAC or digital > signature) that the sender of the INIT ACK chunk can later use to > cryptographically authenticate the State Cookie. It MUST NOT cause the size > of the State Cookie to exceed X bytes in total, and it SHOULD provide at > least Y bits of security. For example, the State Cookie's authenticity > protection could use Z. > Well, we are not that specific about size, especially regarding Y. We only > mention: > > An implementation SHOULD make the cookie as small as possible to ensure > interoperability. > > This is basically about trying that the packet containing the INIT-ACK > does not need to be fragmented > at the IP layer. > > If you think, I can add a statement about the length of the key being used > in the operation. > > > > I'm guessing Y = 128 is reasonable. For Z, I'm guessing HMAC-SHA-256 > with some specific key length (256 bits?) but like I said above, I don't > know enough about MAC algorithms to provide good guidance here. > We actually left that open. Since you compute the cookie when responding > to an INIT chunk, it is also > important that you don't spend too many cycles on generating it. How you > balance the level of > protection against the cookie modification and protection against the CPU > load during an INIT flood > depends on the system, the application, and is left open. > > The cookie mechanism is used on the server side to avoid keeping state > before the server > has validated that it communicates with the IP address it is thinking it > communicates with. > > So I'm not too concerned about this. But I follow any advice you are > giving... > > > > None of that really solves the terminology problem though. "State > Cookie's authenticity protection" is a bit verbose. Given the performance > advantages of MACs over digital signatures, maybe use the term MAC > throughout, with a note in one place that a digital signature could also be > used if an implementation has a reason to? > > > >>> (nit) The description of Chunk Length in Section 3.2 seems a bit > complicated. (Not a lot complicated, just a bit.) I'd expect at least > occasional security issues from incorrect implementations in programming > languages that don't enforce in-bounds memory access. I'm guessing it's > either too late to simplify the field, or there are good reasons for it to > be the way it is? Are there any lessons learned by existing implementations > that would be worth mentioning to help future implementors avoid issues > with out-of-bounds memory access here? ("No" is a fine answer if this turns > out to not have been a problem.) > >> In RFC 2960 was an issue how to handle the padding of the last > parameter in a chunk. Should > >> it be considered the padding of the parameter (and therefore included > in the length of the chunk) > >> or considered the padding of the chunk (and therefore not included in > the length of the chunk). > >> This was addressed RFC 4960 by: > >> https://datatracker.ietf.org/doc/html/rfc4460#section-2.3 > >> Besides of that I'm aware of (fixed) bugs in implementations, which > were caused by not > >> checking the length field. However, the problem was that the check was > not done, not that > >> it was not clear which values should be checked. So I guess this can > not be improved here. > >> However, if you can suggest a wording which describes things better or > in a clearer way, > >> I'm open to include that. > > > > Nope, feel free to keep it as is. And thanks for the background. > >>> (nit) Section 5.1.5, bullet point 4 says 'If the elapsed time is > longer than the lifespan carried in the State Cookie, then ... the endpoint > MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer > endpoint.' That's different from the behavior if the MAC fails in bullet > point 2. Does that mean that endpoints are REQUIRED to keep track of every > secret they've ever used, so that they can distinguish between failed MACs > and expired cookies for very old cookies? Should that be relaxed a bit to > let implementations only store moderately recent secrets? > >> This is exactly how it is implemented in FreeBSD. There are two keys > (the current and the one before). > >> If a COOKIE which is way too old, it would just be dropped. The current > lifetime of a secret is 60 minutes, > >> and the maximum time you can report in the stale cookie is about 70 > minutes. > >> So what about using: > >>
  • Compute a MAC using the information carried in the State Cookie > and > >> the secret key. > >> The timestamp in the State Cookie MAY be used to determine which secret > >> key to use. > >> If secrets are kept only for a limited amount of time and the secret > key to use > >> is not available anymore, the packet containing the COOKIE ECHO chunk > MUST be > >> silently discarded. > > > > Sounds good. > > > >>> (nit) Section 12.2.3 says "Regardless of where confidentiality is > provided, the Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] > SHOULD be used for key management." That makes sense for ESP, but is it > intended to apply to DTLS too? (DTLS is mentioned earlier in the same > section.) > >> The reference to DTLS was added recently. You are right, the IKE > reference should only apply to ESP. > >> I changed the text to read: > >> Regardless of where confidentiality is provided, the Internet Key > >> Exchange Protocol version 2 (IKEv2) SHOULD be > used for > >> key management of ESP. > > > > Sounds good. > > > >>> > >>> P.S. This was a very long document, so I ended up just skimming a > bunch of the parts that I guessed were less likely to be relevant to > security. Let me know if there are any particular sections I should take a > closer look at. > > --00000000000055ba4b05ce558f45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Admin note: is there a reason this review isn't in the= datatracker?

    On Thu, Oct 14, 2021 at 12:31 PM <tuexen@fh-muenster.de> wrote:
    > On 14. Oct 2021, at 19:57, Da= vid Mandelberg <david@mandelberg.org> wrote:
    >
    > Op 14-10-2021 om 10:46 schreef tuexen@fh-muenster.de:
    >>> \On 12. Oct 2021, at 04:12, David Mandelberg <david@mandelberg.org> w= rote:
    >>>
    >>> I have reviewed this document as part of the security director= ate's
    >>> ongoing effort to review all IETF documents being processed by= the
    >>> IESG.=C2=A0 These comments were written primarily for the bene= fit of the
    >>> security area directors.=C2=A0 Document editors and WG chairs = should treat
    >>> these comments just like any other last call comments.
    >> Hi David,
    >> thank you very much for your review. Please see my comments in-lin= e.
    >> Best regards
    >> Michael
    >>>
    >>> The summary of the review is Ready with nits.
    >>>
    >>> (nit) Section 2.3 describes MACs as "based on cryptograph= ic hash functions using a secret key". If the intent is to limit this = to MACs that use cryptographic hash functions, I'd suggest using the te= rm HMAC instead of MAC. If not, I think there are other MAC algorithms that= don't use hashes.
    >> I can change it to HMAC, if that is a better term. The description= you are citing ends with:
    >> SCTP uses this term with the same meaning as in [RFC2104].
    >> The title of RFC 2104 is "HMAC: Keyed-Hashing for Message Aut= hentication".
    >> Just let me know.
    >
    > From a security perspective, there are multiple good options for MAC a= lgorithms to use here, including some HMAC algorithms. (I don't know en= ough about MAC algorithms to be too much more specific.)
    >
    > From a standards perspective, I think the doc should be clear about wh= at the requirements actually are. This seems like an unusual case, because = there are no interoperability concerns as far as I can tell. (Except maybe = length? Are there constraints on the length of the field?) I don't know= what the right thing to do here is, but I'd lean towards 1) documentin= g the requirements for interoperability, 2) documenting the requirements fo= r security, and 3) providing an example algorithm that implementations shou= ld use unless they have a reason to pick something different. Do other peop= le think that's a good way to go? Or should it be kept simpler and just= recommend something specific?
    >
    > If it helps, here's some draft text of what I'm thinking:
    You are suggesting to add this to section 5.1.3, I guess. So are you sugges= ting to remove the MAC entry from Section 2.3?
    >
    > The State Cookie MUST include information (e.g., a MAC or digital sign= ature) that the sender of the INIT ACK chunk can later use to cryptographic= ally authenticate the State Cookie. It MUST NOT cause the size of the State= Cookie to exceed X bytes in total, and it SHOULD provide at least Y bits o= f security. For example, the State Cookie's authenticity protection cou= ld use Z.
    Well, we are not that specific about size, especially regarding Y. We only = mention:

    An implementation SHOULD make the cookie as small as possible to ensure int= eroperability.

    This is basically about trying that the packet containing the INIT-ACK does= not need to be fragmented
    at the IP layer.

    If you think, I can add a statement about the length of the key being used = in the operation.
    >
    > I'm guessing Y =3D 128 is reasonable. For Z, I'm guessing HMAC= -SHA-256 with some specific key length (256 bits?) but like I said above, I= don't know enough about MAC algorithms to provide good guidance here.<= br> We actually left that open. Since you compute the cookie when responding to= an INIT chunk, it is also
    important that you don't spend too many cycles on generating it. How yo= u balance the level of
    protection against the cookie modification and protection against the CPU l= oad during an INIT flood
    depends on the system, the application, and is left open.

    The cookie mechanism is used on the server side to avoid keeping state befo= re the server
    has validated that it communicates with the IP address it is thinking it co= mmunicates with.

    So I'm not too concerned about this. But I follow any advice you are gi= ving...
    >
    > None of that really solves the terminology problem though. "State= Cookie's authenticity protection" is a bit verbose. Given the per= formance advantages of MACs over digital signatures, maybe use the term MAC= throughout, with a note in one place that a digital signature could also b= e used if an implementation has a reason to?
    >
    >>> (nit) The description of Chunk Length in Section 3.2 seems a b= it complicated. (Not a lot complicated, just a bit.) I'd expect at leas= t occasional security issues from incorrect implementations in programming = languages that don't enforce in-bounds memory access. I'm guessing = it's either too late to simplify the field, or there are good reasons f= or it to be the way it is? Are there any lessons learned by existing implem= entations that would be worth mentioning to help future implementors avoid = issues with out-of-bounds memory access here? ("No" is a fine ans= wer if this turns out to not have been a problem.)
    >> In RFC 2960 was an issue how to handle the padding of the last par= ameter in a chunk. Should
    >> it be considered the padding of the parameter (and therefore inclu= ded in the length of the chunk)
    >> or considered the padding of the chunk (and therefore not included= in the length of the chunk).
    >> This was addressed RFC 4960 by:
    >> https://datatracker.ietf.org/doc/h= tml/rfc4460#section-2.3
    >> Besides of that I'm aware of (fixed) bugs in implementations, = which were caused by not
    >> checking the length field. However, the problem was that the check= was not done, not that
    >> it was not clear which values should be checked. So I guess this c= an not be improved here.
    >> However, if you can suggest a wording which describes things bette= r or in a clearer way,
    >> I'm open to include that.
    >
    > Nope, feel free to keep it as is. And thanks for the background.
    >>> (nit) Section 5.1.5, bullet point 4 says 'If the elapsed t= ime is longer than the lifespan carried in the State Cookie, then ... the e= ndpoint MUST transmit an ERROR chunk with a "Stale Cookie" error = cause to the peer endpoint.' That's different from the behavior if = the MAC fails in bullet point 2. Does that mean that endpoints are REQUIRED= to keep track of every secret they've ever used, so that they can dist= inguish between failed MACs and expired cookies for very old cookies? Shoul= d that be relaxed a bit to let implementations only store moderately recent= secrets?
    >> This is exactly how it is implemented in FreeBSD. There are two ke= ys (the current and the one before).
    >> If a COOKIE which is way too old, it would just be dropped. The cu= rrent lifetime of a secret is 60 minutes,
    >> and the maximum time you can report in the stale cookie is about 7= 0 minutes.
    >> So what about using:
    >> <li><t>Compute a MAC using the information carried in = the State Cookie and
    >> the secret key.
    >> The timestamp in the State Cookie MAY be used to determine which s= ecret
    >> key to use.
    >> If secrets are kept only for a limited amount of time and the secr= et key to use
    >> is not available anymore, the packet containing the COOKIE ECHO ch= unk MUST be
    >> silently discarded.
    >
    > Sounds good.
    >
    >>> (nit) Section 12.2.3 says "Regardless of where confidenti= ality is provided, the Internet Key Exchange Protocol version 2 (IKEv2) [RF= C7296] SHOULD be used for key management." That makes sense for ESP, b= ut is it intended to apply to DTLS too? (DTLS is mentioned earlier in the s= ame section.)
    >> The reference to DTLS was added recently. You are right, the IKE r= eference should only apply to ESP.
    >> I changed the text to read:
    >> <t>Regardless of where confidentiality is provided, the Inte= rnet Key
    >> Exchange Protocol version 2 (IKEv2) <xref target=3D'RFC7296= '/> SHOULD be used for
    >> key management of ESP.</t>
    >
    > Sounds good.
    >
    >>>
    >>> P.S. This was a very long document, so I ended up just skimmin= g a bunch of the parts that I guessed were less likely to be relevant to se= curity. Let me know if there are any particular sections I should take a cl= oser look at.

    --00000000000055ba4b05ce558f45-- From nobody Thu Oct 14 13:05:40 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1633A17D6; Thu, 14 Oct 2021 13:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 HB84ipPGc_pD; Thu, 14 Oct 2021 13:05:36 -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 F1B633A17CA; Thu, 14 Oct 2021 13:05:35 -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 19EK5NwA005156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Oct 2021 16:05:28 -0400 Date: Thu, 14 Oct 2021 13:05:22 -0700 From: Benjamin Kaduk To: Martin Duke Cc: Michael Tuexen , secdir@ietf.org, The IESG , draft-ietf-tsvwg-rfc4960-bis.all@ietf.org, David Mandelberg Message-ID: <20211014200522.GI4103@kduck.mit.edu> References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 20:05:38 -0000 On Thu, Oct 14, 2021 at 01:02:24PM -0700, Martin Duke wrote: > Admin note: is there a reason this review isn't in the datatracker? I assume the original review was manually sent as an email. I think that Tero will notice it and update the datatracker review entry in the next day or so when he updates the assignments. -Ben From nobody Thu Oct 14 13:37:46 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD39D3A1843 for ; Thu, 14 Oct 2021 13:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=mandelberg.org header.b=BPERMfME; dkim=pass (2048-bit key) header.d=mandelberg.org header.b=XUEnLD+H 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 vgqgdYMpAyWc for ; Thu, 14 Oct 2021 13:37:39 -0700 (PDT) Received: from mail-pg1-x563.google.com (mail-pg1-x563.google.com [IPv6:2607:f8b0:4864:20::563]) (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 72E973A18F2 for ; Thu, 14 Oct 2021 13:37:11 -0700 (PDT) Received: by mail-pg1-x563.google.com with SMTP id 133so6608604pgb.1 for ; Thu, 14 Oct 2021 13:37:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:dkim-signature:dkim-signature:subject:to:cc :references:from:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=E+Bt1eC265y8GXnOdYavmz44Qv1PQwjgu8yo/b8vbpM=; b=e6YJe11nzam9dY5TB6pwHbATVIEoPb5LMkaC6rCfOeU9nsnZjYSM2oKyd7JRuC5t9+ Cg0lsVBpDqLdBh+u+vhci8Ua5FFf4Rc9ULbn+mOMj9vOyd8laHwkaBYQ35RD6paxJisF hEUb66RJJuARSyBsWA6RLS87dtZLDvVMzSJG//piORqBiMhsfewXRRRSLckmXDNGx5Z3 /Gzp5Qfz1ZiLkakCT56c/Dx71M97zjv04FbL0SwDKxCm2DE5Zft6fF3oQVjQX1oFVomD 25ddB+pjwzft7l0fKAkj+qqIc4mQnNF5wDwGSfsSTBo5CEPrgePw9W+kw3Nuerlx5Rtr 4oQw== X-Gm-Message-State: AOAM532OWE00AMf05fFkYenJ/mtHzu+dGKCrVA6rfg35Jts7rA1g5CP0 aqp3LGHdZa4u6fQgNKHEgfcHcdEVj7iOjUZm4tSojyS3aW83bA== X-Google-Smtp-Source: ABdhPJzZf7FCju3+cGSNEdJnyCVtaUEEwTfNR0vnbGnCYOoWHIDS+C9PTgJpzmSWJULx/wuiL5sHDNCLcHu5 X-Received: by 2002:a05:6a00:26dd:b0:44d:2531:9f46 with SMTP id p29-20020a056a0026dd00b0044d25319f46mr7649889pfw.46.1634243830586; Thu, 14 Oct 2021 13:37:10 -0700 (PDT) Received: from mail-outbound-e14cf917.virgo.mandelberg.org (pool-74-104-157-60.bstnma.fios.verizon.net. [74.104.157.60]) by smtp-relay.gmail.com with ESMTPS id on14sm101201pjb.0.2021.10.14.13.37.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Oct 2021 13:37:10 -0700 (PDT) X-Relaying-Domain: mandelberg.org DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=mandelberg.org; i=@mandelberg.org; q=dns/txt; s=mail-outbound-e14cf917-07914516; t=1634243829; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : from; bh=ab71gaNHgH11v8aSnKyn65UbFwb0tF+NH/MLAJHxN50=; b=BPERMfME7Z0ymrsUWlAslRpuaWVhdUDAc+jrfkK1fINdKfrD/7e4GB9L0uJzfQx7LMS6I F7DOyPXEJVLP0jRAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; i=@mandelberg.org; q=dns/txt; s=mail-outbound-e14cf917-b7c648a2; t=1634243829; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : from; bh=ab71gaNHgH11v8aSnKyn65UbFwb0tF+NH/MLAJHxN50=; b=XUEnLD+HSVBHuY+S2Jac1Z2TTKuQ+OOeLKLm5K+Wiv8YTVjyW/DWMlQYQu/3tI572sliC Z2k/umpW0PtcD2sNlgOJHM0c+8wRhu1Z8EdonMfLiY2VNv8rLepGFUXj3jbCHuWg/ENeXW/ vLRBlGak2oqJn69siSeWHJZn5biu+T7nXNbrrM64vLHCwE3EbjmlQpjBGfD7i7LWBxHCdCE /gz7kqx6St03SP11N3WhdFIihu8wJ5Sz9iNgf7BFOAuKXaXEDt68nPYRija/ALCU5c6l/qH 2zP/9iXOEuoLwmPQjTwucHpFDf04vuAeSqJBdMCww1jNGM+p/EaLlLQnDDkA== Received: from [IPv6:fde5:2b79:35f0:2::14e] (solaria.virgo.mandelberg.org [IPv6:fde5:2b79:35f0:2::14e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-384)) (No client certificate requested) by mail-outbound-e14cf917.virgo.mandelberg.org (Postfix) with ESMTPSA id 4HVh5x2sLXz10Zs; Thu, 14 Oct 2021 20:37:09 +0000 (UTC) To: Benjamin Kaduk , Martin Duke Cc: Michael Tuexen , secdir@ietf.org, The IESG , draft-ietf-tsvwg-rfc4960-bis.all@ietf.org References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> <20211014200522.GI4103@kduck.mit.edu> From: David Mandelberg Message-ID: Date: Thu, 14 Oct 2021 16:37:09 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211014200522.GI4103@kduck.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 20:37:44 -0000 Op 14-10-2021 om 16:05 schreef Benjamin Kaduk: > On Thu, Oct 14, 2021 at 01:02:24PM -0700, Martin Duke wrote: >> Admin note: is there a reason this review isn't in the datatracker? > > I assume the original review was manually sent as an email. Yup. Should I start using the datatracker at some point? > I think that Tero will notice it and update the datatracker review entry in > the next day or so when he updates the assignments. > > -Ben > From nobody Thu Oct 14 13:55:21 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869D83A17FF for ; Thu, 14 Oct 2021 13:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=mandelberg.org header.b=yFoUYZ4X; dkim=pass (2048-bit key) header.d=mandelberg.org header.b=VOHeZZSa 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 gt922yC5okdu for ; Thu, 14 Oct 2021 13:55:11 -0700 (PDT) Received: from mail-qk1-x761.google.com (mail-qk1-x761.google.com [IPv6:2607:f8b0:4864:20::761]) (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 A47C83A17FD for ; Thu, 14 Oct 2021 13:55:11 -0700 (PDT) Received: by mail-qk1-x761.google.com with SMTP id j12so535991qkk.5 for ; Thu, 14 Oct 2021 13:55:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:dkim-signature:dkim-signature:subject:to:cc :references:from:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=19yjAkLvFJUpoRAXJ+SdtIHP/yXBWCyGrwg1Co5kOOo=; b=l6sXW4/19OXTlA8PnwCAXMFE5ab+IVEU58hdqdQXs+cUoDlkKfJKqqaHI9AKs/JSXE gJ14JW8LAkED5Gh4+fUMYG1AczJgwiXC2omRlnzy8V3CShn5IVwNJ51WilOwVQc264AS 48Osws18s+9kiiZTXIG6mTGcewo34NSG2kzZU+T2wqGg6d5Fn0SSFrHyDBLCdr1rq+3V xlHuxtDZpCyCFW6sCK5WQXqaao5kwmUEQT4/cq4EwzGyH7LXT4ACVTJ/rQeSlX2mhjur /Twcxvbvfw3/dxWahwupVR8s2c43eTA66fZJFfr6IU1hS9/y9teiUDh+qTGwhtH1l//3 Lp7g== X-Gm-Message-State: AOAM533Y2u5U02n/TO/P+UojY9Sn4NjV66PJ8WYIJno9Yn9u9mRe++hP M1D488kj9fOEseJ6ZHHedjuLTBquV/X83Xws65ilQkR0KmlKdA== X-Google-Smtp-Source: ABdhPJyLhqGEazHXReAJXw6Blie9p/r8qcqE+W1ULuemr5UPxha9QIh/uwromSiTA2lmL4c/GFePUDojjyDV X-Received: by 2002:a05:620a:24ce:: with SMTP id m14mr6108166qkn.212.1634244909986; Thu, 14 Oct 2021 13:55:09 -0700 (PDT) Received: from mail-outbound-e14cf917.virgo.mandelberg.org (pool-74-104-157-60.bstnma.fios.verizon.net. [74.104.157.60]) by smtp-relay.gmail.com with ESMTPS id 187sm1952502qkk.7.2021.10.14.13.55.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Oct 2021 13:55:09 -0700 (PDT) X-Relaying-Domain: mandelberg.org DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=mandelberg.org; i=@mandelberg.org; q=dns/txt; s=mail-outbound-e14cf917-07914516; t=1634244909; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : from; bh=Zb+JtTPpGwX9pxwKerbB7R6TttLHHzvriJmlwhxEVE4=; b=yFoUYZ4XGAXoHjbW2pTxhCeP8xEVpY0NB13Iy9QcgsiMU5x3zpr8XXnGZkl+jVThg18sf FaRiWFdwJ3LrtNnAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; i=@mandelberg.org; q=dns/txt; s=mail-outbound-e14cf917-b7c648a2; t=1634244909; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : from; bh=Zb+JtTPpGwX9pxwKerbB7R6TttLHHzvriJmlwhxEVE4=; b=VOHeZZSaEM/uqvvK3LAMd3VpXeqMTX16abVZqrL+iEq1HMxZ0bWUpTItYjY+/C5Y8hewb +0ZH8oK1CCuOoH8NhINZU9nbat35/rM+G8S7eTInZSFtjn70UobW6hWjDeg+KhPpQaa4yLf ZSZ2ZMHHmHnJzdNNbp1yMZ0WtPnYD9js1yUl3vatGdlzUiw0Bc29Vm+679tZB0dyMxg4lLQ rv2MHXGe+k8eAwTfqzq5s3lw7Gcm6Zg6KyOMQsSXG7sH3eiSt6FWFA020XAwM9z6Faun+WY /5qaOj04mSw/LlFMlNF6IcqJ3y8Y/yQt8YqV5HvE9Z7Xc1FrZX9wgJwsMJpw== Received: from [IPv6:fde5:2b79:35f0:2::14e] (solaria.virgo.mandelberg.org [IPv6:fde5:2b79:35f0:2::14e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-384)) (No client certificate requested) by mail-outbound-e14cf917.virgo.mandelberg.org (Postfix) with ESMTPSA id 4HVhVj3vPwz10Zs; Thu, 14 Oct 2021 20:55:09 +0000 (UTC) To: tuexen@fh-muenster.de Cc: secdir@ietf.org, iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> From: David Mandelberg Message-ID: <2bac74f5-e134-d50c-a640-4a87fdbc5790@mandelberg.org> Date: Thu, 14 Oct 2021 16:55:09 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 20:55:18 -0000 Op 14-10-2021 om 15:31 schreef tuexen@fh-muenster.de: >> On 14. Oct 2021, at 19:57, David Mandelberg wrote: >> From a security perspective, there are multiple good options for MAC algorithms to use here, including some HMAC algorithms. (I don't know enough about MAC algorithms to be too much more specific.) >> >> From a standards perspective, I think the doc should be clear about what the requirements actually are. This seems like an unusual case, because there are no interoperability concerns as far as I can tell. (Except maybe length? Are there constraints on the length of the field?) I don't know what the right thing to do here is, but I'd lean towards 1) documenting the requirements for interoperability, 2) documenting the requirements for security, and 3) providing an example algorithm that implementations should use unless they have a reason to pick something different. Do other people think that's a good way to go? Or should it be kept simpler and just recommend something specific? >> >> If it helps, here's some draft text of what I'm thinking: > You are suggesting to add this to section 5.1.3, I guess. So are you suggesting to remove the MAC entry from Section 2.3? Yes, if you think that makes sense. >> The State Cookie MUST include information (e.g., a MAC or digital signature) that the sender of the INIT ACK chunk can later use to cryptographically authenticate the State Cookie. It MUST NOT cause the size of the State Cookie to exceed X bytes in total, and it SHOULD provide at least Y bits of security. For example, the State Cookie's authenticity protection could use Z. > Well, we are not that specific about size, especially regarding Y. We only mention: > > An implementation SHOULD make the cookie as small as possible to ensure interoperability. Oops, I missed that. No need to add more about the State Cookie size then, as far as I'm concerned. > This is basically about trying that the packet containing the INIT-ACK does not need to be fragmented > at the IP layer. > > If you think, I can add a statement about the length of the key being used in the operation. I think telling people to use cryptography without giving any guidance about what algorithms or parameters to use could potentially lead to implementations accidentally picking insecure options. So I think it would be nice to see some guidance there, even if it's non-normative. >> I'm guessing Y = 128 is reasonable. For Z, I'm guessing HMAC-SHA-256 with some specific key length (256 bits?) but like I said above, I don't know enough about MAC algorithms to provide good guidance here. > We actually left that open. Since you compute the cookie when responding to an INIT chunk, it is also > important that you don't spend too many cycles on generating it. How you balance the level of > protection against the cookie modification and protection against the CPU load during an INIT flood > depends on the system, the application, and is left open. Oh that's a good point. Was that in the doc and I missed it? If not, it might be nice to mention as guidance for implementors on how to pick the right algorithm and parameters. Though I'd probably still lean towards also including a reasonable example, for implementors to use by default if they're unsure of what to pick. > The cookie mechanism is used on the server side to avoid keeping state before the server > has validated that it communicates with the IP address it is thinking it communicates with. > > So I'm not too concerned about this. But I follow any advice you are giving... I'm not too concerned about it either :) I think some clarification and an example (as discussed above) would be good, but I don't feel strongly about any of the specifics. (Just maybe don't recommend HMAC-MD5 truncated to 32 bits.) From nobody Mon Oct 18 02:21:21 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 862493A0B5B for ; Mon, 18 Oct 2021 02:21:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <163454887701.22358.4562214508036936439@ietfa.amsl.com> Date: Mon, 18 Oct 2021 02:21:17 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2021 09:21:18 -0000 Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview For telechat 2021-10-21 Reviewer LC end Draft Shaun Cooley 2021-10-18 draft-ietf-jmap-smime Phillip Hallam-Baker 2021-10-12 draft-ietf-cbor-cddl-control Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy Dacheng Zhang 2021-09-07 draft-ietf-bess-evpn-bum-procedure-updates Last calls: Reviewer LC end Draft John Bradley 2021-09-06 draft-ietf-core-senml-data-ct Shaun Cooley 2021-10-18 draft-ietf-jmap-smime Daniel Franke 2021-09-22 draft-ietf-cbor-network-addresses Phillip Hallam-Baker 2021-10-12 draft-ietf-cbor-cddl-control Scott Kelly 2021-10-27 draft-ietf-regext-rfc7484bis Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 Catherine Meadows 2021-10-28 draft-ietf-calext-ical-relations Alexey Melnikov 2021-10-27 draft-ietf-opsawg-ntf Daniel Migault 2021-10-26 draft-ietf-idr-bgp-ext-com-registry Adam Montville 2021-10-26 draft-ietf-rum-rue Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Samuel Weiler 2021-08-25 draft-ietf-alto-path-vector Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2021-08-30 draft-ietf-alto-cdni-request-routing-alto Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Liang Xia 2021-03-17 draft-ietf-core-sid Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy Dacheng Zhang 2021-09-07 draft-ietf-bess-evpn-bum-procedure-updates Early review requests: Reviewer Due Draft Stephen Farrell 2021-09-15 draft-ietf-ippm-ioam-direct-export Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Kathleen Moriarty 2021-10-25 draft-ietf-dots-multihoming Tina Tsou 2021-08-25 draft-ietf-opsawg-sbom-access Sean Turner 2021-08-18 draft-ietf-taps-interface Loganaden Velvindron 2021-08-18 draft-ietf-taps-arch Next in the reviewer rotation: Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tim Polk Vincent Roca Kyle Rose From nobody Mon Oct 18 09:21:03 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780FC3A098B; Mon, 18 Oct 2021 09:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, 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=iki.fi 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 EXs5lr-FYf6a; Mon, 18 Oct 2021 09:20:56 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5C53A14AB; Mon, 18 Oct 2021 09:20:55 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id CADD51B00131; Mon, 18 Oct 2021 19:20:51 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1634574052; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=z/0R0W4uj+GRlEu4eINVVmMEVuyAG36YySKmXI74igU=; b=v/DykTXA1if+5qBwAa0ZlHx7cpGZf+4NSJSUwC9ofJpO5jRQmRquwr37T6zxPpBzA/4w9o X9ERGhcFo9ZiDapaDLY8NhH9ve7MJh7ISxtY5ZE1eGGea5hbO7VLxlsPaUDczP7NKrUYH0 dkIJ/eQF+8OIsaNzP25ckS+qBihHJwnLYeEl2TKOMt8K6bthpVr12EpaoAT78ma8qn+WP3 saqeEqOjP5SQRh9NNUmpgHKP8T2rHpdMPlrO83i8j7ujkzHF/OtJ0r2c26L3ZU9rIAT8tK FbaDMni8xEnsI1wEc1bdlKxs5zxzPEsa/JaHgLBSRC10dEIsTPYnG/flglRcdA== Received: by fireball.acr.fi (Postfix, from userid 15204) id 5245E25C12DB; Mon, 18 Oct 2021 19:20:51 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24941.40675.108669.59481@fireball.acr.fi> Date: Mon, 18 Oct 2021 19:20:51 +0300 From: Tero Kivinen To: Martin Duke Cc: Michael Tuexen , secdir@ietf.org, The IESG , draft-ietf-tsvwg-rfc4960-bis.all@ietf.org, David Mandelberg In-Reply-To: References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1634574052; a=rsa-sha256; cv=none; b=SEu3htgeKgmsdOEKvC0VBiJtLxaF1yJebf2VPFaDrYtj8H8rFlBAJJBKcXQbP4+oIpcySe VOMfhMaWRw+TyhjXF4bb3H6w8Ap0vIjFsmnURiUn/44hrznphqlmYS5a0cm64qF3S+i02I je8NCbNaGh4SQYkfOmwxNHOBKWL2P736IZlPhXUx69gByQiyYifrCd6hORjnfDx9iCi403 tQdiTyjOKKyH85I86Ac9gkdYC+J4ZSiQNe1cy7Va12Cy0Qqhr5KkA/+3sXa59VN4XFPsQg zJpHceAywv+HCZ2WyGeqWzkr2HtMvsIrAHFDGNXrx2HkNcpG7Pq2riL4xV+Alw== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1634574052; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=z/0R0W4uj+GRlEu4eINVVmMEVuyAG36YySKmXI74igU=; b=lI3A4Tk0nPKgklzXvXRYl0ZOnV7kX3HtnKwwLsVqq5mYUi4DTgl+P90zGNttesdlIqwHkG b54M0zJVDcLhH3W6ZpG7Bi8589a6W/tttf+w1UgSbDkzpyes8rO5iW6ifeKlUIhbdJMDIi 998K8kAahlQ9q7+HDF26Q8hIl6zpAqeVVJho/zUlGAHBy71gqg1z7N9eKZnCj3iRaBUKdP wiE1aC/Bf3cS8aYQOQ9zzYRJe5fjuHs9Bn3zBHKTWquvDn0tnD/G3DOBM+LiW2w7v0x8zF tVelScuoInckteKIYn87C6JSNtnpQbdbUW4NurT1MM0au1+0Ked9jvwpbKcBcg== Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2021 16:21:00 -0000 Martin Duke writes: > Admin note: is there a reason this review isn't in the datatracker? It was sent directly to list, meaning the reviewer did not use the datatracker to complete the review request. This means that secdir secretary (me) needs to manually close the review request, and provide link to the review. I normally do that every Thursday when I do new round of review requests, but last week there was M3AAWG meeting and other things going on so I didn't have time to do secdir reviews until today. Now the link should be in the datatracker. Unfortunately there were too many responses in the email thread and the datatracker only shows me last 10 messages with that subject, so I could not pick the actual review email in the datatracker form. This meant that I needed to manually find the review link from the list, and fill that in to the datatracker, and it case the datatracker does not fetch the email text from the url, thus the email text is not is not included in the datatracker. This means you need to click on the link of the review text to be able to see the actual email. -- kivinen@iki.fi From nobody Mon Oct 18 10:02:33 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A70C3A15F8; Mon, 18 Oct 2021 10:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-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=iki.fi 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 UbJJuTzVwdb2; Mon, 18 Oct 2021 10:02:22 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (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 779C03A15F3; Mon, 18 Oct 2021 10:02:20 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by meesny.iki.fi (Postfix) with ESMTPSA id C269620335; Mon, 18 Oct 2021 20:02:16 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1634576536; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DQpxwpM9WUP04liE5vYM2SXwg96raGQns5XfBduXOQ4=; b=Nt+6C/MSgFCWnNWrVdvLjMWS7q6Hh4zIsX5rX8+vZR9qDzHw+xK1wy5cKvTXPLxU+F8tVe WuA3MZQJDl4Hscwre8X9wKWEKfw5TfnAYg1s1+1fJ0Uaef/idP+G4v+7e4B4WTXDUxrayZ A2j7EdElVU10pQY0s8HgvHWJXlb/35k= Received: by fireball.acr.fi (Postfix, from userid 15204) id 5A7B625C12DB; Mon, 18 Oct 2021 20:02:16 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24941.43160.312498.778487@fireball.acr.fi> Date: Mon, 18 Oct 2021 20:02:16 +0300 From: Tero Kivinen To: David Mandelberg Cc: tuexen@fh-muenster.de, iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org, secdir@ietf.org In-Reply-To: <2bac74f5-e134-d50c-a640-4a87fdbc5790@mandelberg.org> References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> <2bac74f5-e134-d50c-a640-4a87fdbc5790@mandelberg.org> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 35 min X-Total-Time: 39 min ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1634576536; a=rsa-sha256; cv=none; b=hafmBdJ4tGFf44mvP+5odnOA2XMeUMvwCfBl7V27bQu/9FwGXl3EchL3C/95Aq/MDTpOHp NewlFB4L8qsUtOCDw8Hp7MYUjGxADasSbYoouQAKKN1HekA9m6hRId2ANlSnKklj3gS6jT gTCcZMZ3MeMLt8hGlCyYlHVDC/oU92w= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1634576536; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DQpxwpM9WUP04liE5vYM2SXwg96raGQns5XfBduXOQ4=; b=MZuwarAR8ZcCBDTeGXd3U2n4ZYl4/aOaMB9Sl+81hbCzTXmGGYmzSoRr3NqEVzFLTHr0m0 4wTwaDbVa940EtsfNb4knpx8kho11QglTLGP4Tv8MFkVz+7m/GTHIkeovrMvciow3oVJ2n ygMjQR2XBOFovSRUs3juPwpw/hUwtSo= Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2021 17:02:26 -0000 David Mandelberg writes: > I think telling people to use cryptography without giving any guidance > about what algorithms or parameters to use could potentially lead to > implementations accidentally picking insecure options. So I think it > would be nice to see some guidance there, even if it's non-normative. I first assumed this cookie is similar than what for example IKEv2 uses, i.e. generated and verified by one and reflected by the other end to verify that the other end did see the previous message. When I checked the draft I noticed it is not at all similar than what is used by IKEv2 or Photuris, because the Cookie contains both the "minimal subset of information" and the MAC. To see how IKEv2 specifies this see section 2.6 of RFC7296 and the description about the COOKIE notification, but here is relevant text from there (note this example uses just simple hash with secret, which is not that safe as a MAC, but should be enough for this kind of purposes what IKEv2 does): ---------------------------------------------------------------------- 2.6. IKE SA SPIs and Cookies ... An IKE implementation can implement its responder cookie generation in such a way as to not require any saved state to recognize its valid cookie when the second IKE_SA_INIT message arrives. The exact algorithms and syntax used to generate cookies do not affect interoperability and hence are not specified here. The following is an example of how an endpoint could use cookies to implement limited DoS protection. A good way to do this is to set the responder cookie to be: Cookie = | Hash(Ni | IPi | SPIi | ) where is a randomly generated secret known only to the responder and periodically changed and | indicates concatenation. should be changed whenever is regenerated. The cookie can be recomputed when the IKE_SA_INIT arrives the second time and compared to the cookie in the received message. If it matches, the responder knows that the cookie was generated since the last change to and that IPi must be the same as the source address it saw the first time. Incorporating SPIi into the calculation ensures that if multiple IKE SAs are being set up in parallel they will all get different cookies (assuming the initiator chooses unique SPIi's). Incorporating Ni in the hash ensures that an attacker who sees only message 2 can't successfully forge a message 3. Also, incorporating SPIi in the hash prevents an attacker from fetching one cookie from the other end, and then initiating many IKE_SA_INIT exchanges all with different initiator SPIs (and perhaps port numbers) so that the responder thinks that there are a lot of machines behind one NAT box that are all trying to connect. If a new value for is chosen while there are connections in the process of being initialized, an IKE_SA_INIT might be returned with other than the current . The responder in that case MAY reject the message by sending another response with a new cookie or it MAY keep the old value of around for a short time and accept cookies computed from either one. The responder should not accept cookies indefinitely after is changed, since that would defeat part of the DoS protection. The responder should change the value of frequently, especially if under attack. When one party receives an IKE_SA_INIT request containing a cookie whose contents do not match the value expected, that party MUST ignore the cookie and process the message as if no cookie had been included; usually this means sending a response containing a new cookie. The initiator should limit the number of cookie exchanges it tries before giving up, possibly using exponential back-off. An attacker can forge multiple cookie responses to the initiator's IKE_SA_INIT message, and each of those forged cookie replies will cause two packets to be sent: one packet from the initiator to the responder (which will reject those cookies), and one response from responder to initiator that includes the correct cookie. A note on terminology: the term "cookies" originates with Karn and Simpson [PHOTURIS] in Photuris, an early proposal for key management with IPsec, and it has persisted. The Internet Security Association and Key Management Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight-octet fields called "cookies", and that syntax is used by both IKEv1 and IKEv2, although in IKEv2 they are referred to as the "IKE SPI" and there is a new separate field in a Notify payload holding the cookie. ---------------------------------------------------------------------- As in this draft cookie is not only a cookie, as it also needs to include the data needed to reconstruct the state this puts much more emphasis on the properties of the MAC. In IKEv2 cookie is simply a MAC of things that is already somewhere else in the incoming packet (which are cryptographically proteced later anyways). I.e., the cookie is just used to verify that initiator has already done one round trip to the server before we create state based on the data that is in the first packet. Now as the cookie here contains more than just MAC part, it makes cookie to have more security issues. Now the cookie needs to have more of internal structure and recipient needs to parse it properly. This also means that if attacker is able to modify the cookie in such way that it still passes the checks it might be able to mount more serious attacks. In IKEv2 case that is not possible, as cookie is just HASH of data elsewhere on the packet, thus there is no structure to mess up. I.e., in IKEv2 it would be possible to use very short MAC, as even with one octet MAC that will limit the resource consumption to 1/256th of the non cookie case, but one octet MAC is not going to be good enough to protect the subset of information needed to re-create the TCB. In addition to that your cookie generation might even leak out some internal data from the server if implemnetor really creates a TCB and then includes too much data from the TCB to cookie (i.e., if someone just created TCB, didn't bother to create minimal subset of information, but simply decided that TCB is small enough that it can be used as such, and then TCB might include some pointers to other structures that are internal to the kernel). Because of this I do recommend using the proper cryptographic message authentication code (MAC) and not a thing that IKEv2 and Photurus used, i.e. simple hash with secret at the end (which would most likely still be safe for this use, but proper MAC is better). Also you do want to say something that the MAC part of that cookie, needs to have certain length to protect against forgery attempts, you are not using cookie to just protect against denial of service. -- kivinen@iki.fi From nobody Tue Oct 19 09:37:25 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1888D3A0CB1; Tue, 19 Oct 2021 09:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 HXE_Z2sRpf2K; Tue, 19 Oct 2021 09:37:02 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2131.outbound.protection.outlook.com [40.107.21.131]) (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 D65BD3A0D6A; Tue, 19 Oct 2021 09:37:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PTGd6DAUtYFIiGNdlTL0jGJNN9Qogp8Ex+51YQqg15S8Rntr3H70oOeqsd5+eBEjcL8bfdBOGefwpCRWysQ98y++A4nvoKEZBgxOg6ZToxXOjyByc4ZTK0eErsFP/zVnPDPxA9wuFlftsYSpUcnb/0HACwkJB8FTM1Gjnr7i5lT4vmuzyAiov3e2Y1LnXt5f5xfsuV91JB2iUJ3qgQ2uhUVBjaus/a3mqlYS8qkhv0Y/cH9ynEhapURflYnmPNYR38cIYru03KJTQpnz51PJ4I3UZJERsUf9jolqwr0ct3iL0ZKkkcJmOJXRVIYFXDlZwzNMzoOoc7gjWMswMNK+Hg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nyqDC05yQ+RSdoOjsTQWsdnrCLj4H2EcS94TRwSNvys=; b=OQWK9Q0+Nz/MTa52wsHR97zj/5yCbLhrg4Es59o2DgTsk0e31x2EQY37Edhf3IDGIyR2OQZsbzWz+ojXmsqiLiD/rJKurUfVm2hgageLrLgD75GH+K1soUJ66h+VT3EKSPjDWBmrWQepfW9I4vniUdADCkg9te3+nwXR9rUnGCda34A7NcOj075lmuPK5dJ0+lss0FkZBbfvo8hxUA4zjbBSj27QCTBBhzfporfNkJTorYOUsb+RDZ6F3iScOkzfGPZwrjyMB0Dq599IPRMpZeQix5BvviOMA3koMVmHLB+tSgDS+t5/2yS5aY5UWD4qctSpdQ5tGzTzeQkotuCJ4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nyqDC05yQ+RSdoOjsTQWsdnrCLj4H2EcS94TRwSNvys=; b=B908Y8EHa9irXFAqnc6C1higz+ZtQS9ZbWklMyQ0Rj0Lg+zdUGLynNET/rcki5/qcwDTBsj6nOIOWK8jhoiylInUdcgcOPo5tK3TkrHo+5JG7s5q6lkI72JaYpZkhTpINtooO+1zlP+7NIjewjoqmcK7+Sv7SFL45yLzeXyzIso= Received: from PR3PR07MB7018.eurprd07.prod.outlook.com (2603:10a6:102:7d::13) by PR1PR07MB5114.eurprd07.prod.outlook.com (2603:10a6:102:6::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.11; Tue, 19 Oct 2021 16:36:59 +0000 Received: from PR3PR07MB7018.eurprd07.prod.outlook.com ([fe80::905b:f94d:2807:c70]) by PR3PR07MB7018.eurprd07.prod.outlook.com ([fe80::905b:f94d:2807:c70%6]) with mapi id 15.20.4628.015; Tue, 19 Oct 2021 16:36:58 +0000 From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" To: Paul Wouters , "secdir@ietf.org" CC: "alto@ietf.org" , "draft-ietf-alto-unified-props-new.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-alto-unified-props-new-18 Thread-Index: AQHXqnnk7JtJLI4x6UiiL1aHEjfKt6vatqJg Date: Tue, 19 Oct 2021 16:36:58 +0000 Message-ID: References: <163174184742.9427.9373192733692803905@ietfa.amsl.com> In-Reply-To: <163174184742.9427.9373192733692803905@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia-bell-labs.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7b74d386-5498-44ec-74ff-08d9931eabc7 x-ms-traffictypediagnostic: PR1PR07MB5114: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PcW2HzxDpIoyfM2PMzoWSXip/PWl7vvI7/h0jFuKm0x5ZMkGuVTYsYkeejoOt34H2qdh33SnTK054OR8NeP3Tvxfeu8gEy/fejzKeKfZDDia6aIp4E0rujDcHRf4qbNDz0DytlYRbsnbmQ3OuUWUPw9cyn/WXYWygR3axBCqkQOJEj2P/E/vLQeRyTUEdhu1ZZCsHVj7kcIrjEk6EVoAI2ijPCACtoEbMRa9SQ6xgdONyidqDfEcUiswdqvT2v+jtDkIfJXfFJ15zWvb6MDwRUflTnuofDvhON5V8LH2/RFFCGNzh3V1yOTOo4eM1aDLjevemWrYKzQXTg9dnHNApnyLmKTl1fqDudWE7YudC37zTJSy/FxEzcL3RTPxIi4v5/YTpXR8V/3b9hpGA03RN/RyJZ5lgdrcbsjoyRFBMHZMi0ErBl50PTiTJL/0KYFynJMGsDpWHbZXvQRAf4FPeenXvNOgBVIuMx9MlglVwKOA3WakFNdswKIm1W5B4tkUOiAvnwIfHzbTa83Rsa8TEMgF4OL+ANTIwhhc489a8lo1yxie6w6qdvKnVq3y1D1UlnIUzykwzPFY1ZaqhMqogw9M6vMs5WSkbwe9BrFJuYbDUcUbViwisSf1O+me6UY/w7C0XdPuAhCzx2VpqGtA6mMJIb/2tVo/afEYuztHGWJ2ExQQelmPGT5evVnUHfYRtE8B978yHoaMFqIg36gCkQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3PR07MB7018.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66556008)(66476007)(7696005)(66446008)(64756008)(110136005)(38070700005)(66946007)(2906002)(508600001)(55016002)(122000001)(316002)(82960400001)(52536014)(38100700002)(8676002)(4326008)(76116006)(8936002)(6506007)(9686003)(83380400001)(5660300002)(86362001)(33656002)(186003)(71200400001)(54906003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?YjVRUzU5RkFJTUY2UlBHSFV6bzRocFczTTF4U3RIT1pBRTh0YU15M1VQcDYv?= =?utf-8?B?WFlqaGNkVSswT3R6WTVEd2JIT1J0c1J5VEZFazF1YXRHYWV0UHRtbEswSHMy?= =?utf-8?B?TUZEVkgvT1pnWWpqeE41Z3BKRHVUVTA2OERkTVMrOTBCMzhuOW13RWhHZENR?= =?utf-8?B?UGtRSjJ2Wk5maVNuQlNzTjJLL2w0cSt1UUN4MGxnRkdRRnY3cEJCS2N4NGNk?= =?utf-8?B?TGliU1NPYzFlcGY2Uzk5bXo5RE9DQTFuQWxDRE4zbXIvZFFpSTRza1pqMjY0?= =?utf-8?B?OElVYzlWblBDYWg0VS81L25wcWYvY0VjTlFscm9vTUpEM0R1V3JieG9ydkFj?= =?utf-8?B?MXQveEVnK1dYcXhLTXFsQVN4QStWeTFJQmlaQ3A3RzY2dnJsekI3T2VNWFBp?= =?utf-8?B?ZzVESjlVMnN3MDN5VjdQRW1vNjNFQ1ppcm8yMlMwZkxvVEk1U1l6bElaeWZ1?= =?utf-8?B?ZVY5SEtIdlplR2VBMzRsRmg2OE9EUXBSSm92eDNnU0FLcUZaSnZFVENnMlMz?= =?utf-8?B?R2l5YVR5elMra1gvczdtbE1KdjkxSXQ3OSs3U0V2WUg0Y2daclJxbFlvdEtE?= =?utf-8?B?TDhzSXkrSGx5Ymx2UkVJR2ZKdEE3bXowNW94ZGo1eXFFZHY4R08xSnZ4QTM2?= =?utf-8?B?VkhlWkx3a3VKNHU4b3pOVDJPODQvYzYwMWJpUTdvbzg1VUlkV1dKazZHQXdn?= =?utf-8?B?TG1ydHdvSWF1VElsc2RRdlB5bEZwMDRLalM4YU85Vks2VjBLTDNCN3phaG1k?= =?utf-8?B?em9hNnRzUFBPYUdEbVJxTGw2WE1IalJZYUtOTEFYelhJVy9rWlNGWjE0bGxP?= =?utf-8?B?ZXB3bFlXVjNXSVNzSE1qeDJWOVRsQk1rbUhmRkpSQVRSV2RrK09rRk11UTVR?= =?utf-8?B?MzZsc0RkRnYvNCtQeGRmV0MxeTluZDlxaFRqc3ViS0U1Zmd2RGxYSlRBQWFV?= =?utf-8?B?QTRFTmtnZXNWdnVpbkd5WlBQc2IxeGszVGZCaU9zc1Q4MGZFY0ZUeStSajZm?= =?utf-8?B?Y3R6cXVJTURrK3ZFSU9mQk5yVlA4NFM5aFZKei92QWIxZ1pwWjNrSmdqT24r?= =?utf-8?B?bG9zanI0UHFxVWNZK0VFakFNV0VxZnoyczBhOXpWa1JWSTc2UTVrUVNydDR6?= =?utf-8?B?MHhpSU9PZHJrSCt4cXBWbmtvMFJZMEQ4WlVjVE1vU3RpS1hFNjNsZmRTWG5S?= =?utf-8?B?dERJbHhkNHh3c1ZXOE1EWHRobm92S2x6cjlHaXlmSS83ZlNQUTU1S1AydXFL?= =?utf-8?B?TmdJdnFDQ2U2bDNkVDlHWlpOZCtEM0NwTjJZL0h6bXJ2VUFLKzFJcU9lcCs4?= =?utf-8?B?aHorbW5zNGhFeitEMzNPQ0VhRlVKWWwya1dKL3paTE5EaldLRE1qaWdiMnNH?= =?utf-8?B?UHgrK2R3dDdwb01QQUZINkNXcGJzRlhZZGVoTUd6Rjl2UGljall0VnFvTGll?= =?utf-8?B?R2hKRHhEdWQ0SFlxL2JZNnR3dUR2VWNxblY5VVdpcnVMbFVYRmsrSXpEQzFP?= =?utf-8?B?YkVHNVRGZmdnRThDZGNYS1VpcHd3cHgwUW1WcHdVNFpicE4reU9ncGdsRVJx?= =?utf-8?B?M3Fwa0szSHpKbmNrL2ZUOHNLbGF3aHNlU3JwWWgyendQTWRwaTk2dVRZSUxt?= =?utf-8?B?NWFNNjBiLzBWZ2x5amNzNnBqQk1DZEp0WTlyQXl3N0p4bWlDVlF3bExCOWoy?= =?utf-8?B?bk9IajBEZU8zbXk4MUE3bERaS0VvUUR2R0NtUVVNdGhKRHh4anN0ZldxTlZT?= =?utf-8?B?akFyUHUxQWJVK3IyWjJpc1JCWWQ3NEtiWGErSzN0bHB5K0xtNEEzR2JhZ2Nl?= =?utf-8?B?aENheFhwZW1OTXVNdG9PdCs5WENkMTdPclFwamhWZWNuWVZKU2xnOXNzRWZu?= =?utf-8?B?RGV1VXJML3pIZ0xpM1BiMlJXYkcwL3JPL0pNVS9veitPekJ3WWowbU1zamVn?= =?utf-8?B?Mm5ObXV3bkVlZ2E4ZVlob1cvOUVRNjJuTVhGamI5dXd3TWp5cEVyWW5keSt6?= =?utf-8?B?b2pSbk1HZ21LbXVQKzFoajVoUjRzQ09MT01nV3JjY3dneFJjTU96VXhMN1JZ?= =?utf-8?B?YWl0MXUxYk1Cc3JSLzFBVVdCN1RNMXhtMllqbkEvbndoSU85N0hnakhMdzVw?= =?utf-8?B?Nmt1TGZPNTJseHlnbG9UVFR6eVB1Qll2Z3VIM3V3R1FFWWg0eW1vK0RIWm1B?= =?utf-8?B?V0VVMkJHN0VmMFJZRkVNdWVGTVZFMS9wdkZLQWVjMVdTMlB0eTNLYVlwdTRI?= =?utf-8?B?LzExTDFGODZ3Mzd3TC9USGpFODd4c2E1cysyaERCd1dsUEdmMVE5dThIeEdL?= =?utf-8?B?eWtlTWNWMFRmZ25MdkpGYk9aMXV2VXA5T2lPVVJraE0wazJPY1ROVllxWEdQ?= =?utf-8?Q?KjhlXhhqTf5SXXZFCu7uMfGLCM8/T6KZ16HwE?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PR3PR07MB7018.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7b74d386-5498-44ec-74ff-08d9931eabc7 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2021 16:36:58.8439 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iy0QdQfbLxMvKX/4xsO1Scbs+Uk8m2uPDLgpj1SoCTClT+swSyVGXBj2iL9k/dIQcIYVV4Q9vGiisThqjpH586UKDGS5xN049Cjkmvopu9Y6Zy1E2P+J0bY0PVmBpsP0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB5114 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-alto-unified-props-new-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2021 16:37:09 -0000 SGVsbG8gUGF1bCwNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIHJldmlldy4gQSBuZXcgdmVyc2lv biBpcyB1bmRlciBlZGl0aW9uIHRvIGFkZHJlc3MgeW91ciBjb21tZW50cy4gDQpQbGVhc2Ugc2Vl IGlubGluZSBob3cgd2UgcGxhbiB0byBhZGRyZXNzIHRoZW0uIENhbiB5b3UgbGV0IHVzIGtub3cg d2hldGhlciB0aGUgcHJvcG9zZWQgdXBkYXRlcyBtZWV0IHlvdXIgZXhwZWN0YXRpb25zPyANCkJl c3QgcmVnYXJkcywNClNhYmluZSBhbmQgY28tYXV0aG9ycw0KDQo+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj5Gcm9tOiBQYXVsIFdvdXRlcnMgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGll dGYub3JnPg0KPlNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDE1LCAyMDIxIDExOjM3IFBNDQo+ VG86IHNlY2RpckBpZXRmLm9yZw0KPkNjOiBhbHRvQGlldGYub3JnOyBkcmFmdC1pZXRmLWFsdG8t dW5pZmllZC1wcm9wcy1uZXcuYWxsQGlldGYub3JnOyBsYXN0LQ0KPmNhbGxAaWV0Zi5vcmcNCj5T dWJqZWN0OiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWFsdG8tdW5pZmll ZC1wcm9wcy1uZXctMTgNCj4NCj5SZXZpZXdlcjogUGF1bCBXb3V0ZXJzDQo+UmV2aWV3IHJlc3Vs dDogSGFzIE5pdHMNCj4NCj5JIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9m IHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzICBvbmdvaW5nDQo+ZWZmb3J0IHRvIHJldmlldyBh bGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSAgSUVTRy4gIFRoZXNlDQo+ Y29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNl Y3VyaXR5IGFyZWENCj5kaXJlY3RvcnMuDQo+RG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJz IHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55DQo+b3RoZXIgbGFzdCBj YWxsIGNvbW1lbnRzLg0KPg0KPlRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXMgSGFzIE5pdHMN Cj4NCj5UaGlzIGRvY3VtZW50IGV4dGVuZHMgUkZDIDcyODUgKHRoZSBBTFRPIHByb3RvY29sKSB3 aXRoIHNvbWUgbmV3DQo+cmVnaXN0cmllcyBhbmQgdmFsdWVzLiBBcyBzdWNoLCB0aGVyZSBpcyBu byByZWFsIGNoYW5nZSB0byB0aGUgcHJvdG9jb2wsIG9ubHkgdG8NCj50aGUgcG9zc2libGUgaW5m b3JtYXRpb24gY29udmV5ZWQgdmlhIHRoZSBBTFRPIHByb3RvY29sLiBUaGVyZWZvciBpdCBpcw0K PmFwcHJvcHJpYXRlIHRvIHJlZmVyIHRvIFJGQyA3Mjg1IGZvciB0aGUgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMsIGFzIGlzIGRvbmUgaW4NCj50aGlzIGRvY3VtZW50Lg0KWyBbU1JdIF0gDQpbIFtT Ul0gXSBEbyB5b3UgbWVhbiB3ZSBzaG91bGQga2VlcCB0aGUgc2VjdXJpdHkgc2VjdGlvbiBvZiB0 aGlzIGRvY3VtZW50IGFzIGl0IGlzIG9yIHNob3VsZCB3ZSBzaG9ydGVuIGl0Pw0KPg0KPldoaWxl IGV4dGVuc2lvbnMgdG8gYSBwcm90b2NvbCBkb24ndCBuZWNlc3NpdGF0ZSBhbiBVcGRhdGVzOiBj bGF1c2UsIGluIHRoaXMNCj5jYXNlIEkgdGhpbmsgaXQgc2hvdWxkIGJlY2F1c2UgdGhlIGRvY3Vt ZW50IGFkZHJlc3NlcyBzaG9ydGNvbWluZ3MgaW4gdGhlDQo+b3JpZ2luYWwgcHJvdG9jb2wuIFRo YXQgaXMsIG5ldyBpbXBsZW1lbnRhdGlvbnMgYXJlIGV4cGVjdGVkIHRvIHJlYWxseSByZXF1aXJl DQo+aW1wbGVtZW50aW5nIHRoaXMgbmV3IGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlICJjb3JlIHNw ZWNpZmljYXRpb24iLiBUaHVzDQo+aW1wbGVtZW50ZXJzIHJlYWRpbmcgNzI4NSBzaG91bGQgcmVh bGx5IGJlIHdhcm5lZCB0byBhbHNvIHJlYWQgKGFuZA0KPmltcGxlbWVudCkgdGhpcyBkb2N1bWVu dC4NCg0KWyBbU1JdIF0gd2UgZG8gbm90IG9wcG9zZSBlbnRpdGllcyBhZ2FpbnN0IGVuZHBvaW50 cyB0aGVyZWZvcmUgdGhpcyBleHRlbnNpb24gZG9lcyBub3QgaW50ZW5kIHRvIHJlcGxhY2UgZW5k cG9pbnRzIGJ5IGVudGl0aWVzLiBCb3RoIGFyZSB1c2VmdWwsIGFzIHNvbWUgdXNlIGNhc2VzIGNh biBsaXZlIHdpdGggdGhlIGJhc2UgcHJvdG9jb2wuIEEgZGlzY3Vzc2lvbiB0aHJlYWQgaGFzIGp1 c3Qgc3RhcnRlZCBvbiB0aGlzIHBvaW50IGFuZCB3ZSB3aWxsIGxpa2UgdG8gaGF2ZSB5b3VyIGNv bmNsdXNpb25zIG9uIHRoZSBleHBvc2VkIHBvaW50cyBvZiB2aWV3DQo+DQo+VGhlIElBTkEgY29u c2lkZXJhdGlvbnMgYXJlIHF1aXRlIHZlcmJvc2UuIFVzdWFsbHksIHRoaXMgc2VjdGlvbiBvbmx5 IGNvbnRhaW5zDQo+dGhlIG1pbmltYWwgaW5mb3JtYXRpb24gZm9yIGFuIElBTkEgb3BlcmF0b3Ig dG8gcmVhZCB0byBpbXBsZW1lbnQgdGhlDQo+cmVxdWVzdGVkIGNoYW5nZXMuIEluIHRoaXMgY2Fz ZSB0aGVyZSBpcyBsb3RzIG9mIHRleHQgb24ganVzdGlmeWluZyB0aGluZ3MgdGhhdA0KPmFyZSBi ZXR0ZXIgb21pdHRlZCBvciB3cml0dGVuIG91dCBpbiBhbm90aGVyIHNlY3Rpb24uDQpbIFtTUl0g XSANClsgW1NSXSBdIFdlIGhhdmUgaWRlbnRpZmllZCBzb21lIHBhcmFncmFwaHMgYW5kIHRleHQg dGhhdCBhcmUgbW9yZSBjb25zaWRlcmF0aW9ucyB0aGFuIHNwZWNpZmljYXRpb25zOg0KLS0tLS0t LS0tLSAxMi4yLjIuICBBTFRPIEVudGl0eSBEb21haW4gVHlwZSBSZWdpc3RyYXRpb24gUHJvY2Vz cw0KLS0tLS0gcGFyYSAzIGl0ZW0gNSAiTWVkaWEgdHlwZSBvZiBkZWZpbmluZyBpbmZvcm1hdGlv biByZXNvdXJjZToiIHJlbW92ZWQgcmVkdW5kYW50IHRleHQuIA0KLS0tLS0gcGFyYSAzIGl0ZW0g NiAiS25vd2luZyB0aGUgbWVkaWEgdHlwZS4uLiIgcmVtb3ZlZA0KDQotLS0tLS0tLS0tLSAxMi4z LiAgQUxUTyBFbnRpdHkgUHJvcGVydHkgVHlwZSBSZWdpc3RyeQ0KLS0tLS0gcGFyYSA0OiByZW1v dmVkIGxhc3Qgc2VudGVuY2UNCi0tLS0tIHBhcmEgNCAtIGl0ZW0gMiByZW1vdmVkIGxhc3Qgc2Vu dGVuY2UNCg0KPg0KPlRoZSBuZXcgSUFOQSByZWdpc3RyaWVzIGRvIG5vdCBhbGwgc2VlbSB0byBh bGxvdyBmb3IgcHJpdmF0ZSB1c2UgcmVnaXN0cmF0aW9ucz8NCj5UaGlzIG1lYW5zIHRlY2huaWNh bGx5IGFueSBuZXcgdmFsdWUgY2Fubm90IGJlIHRlc3RlZCB1bmxlc3MgYnkgdmlvbGF0aW5nIHRo ZQ0KPlJGQy4gQXQgbGVhc3QsIHRoYXQgaXMgbXkgcmVhZGluZyBidXQgSSdtIGEgbGl0dGxlIGNv bmZ1c2VkIGJ5IGl0Lg0KWyBbU1JdIF0gDQpbIFtTUl0gXSB3ZSBhZ3JlZSwgYWxsIG5ldyBJQU5B IHJlZ2lzdHJpZXMgc2hvdWxkIGFsbG93IGZvciBwcml2YXRlIHJlZ2lzdHJhdGlvbnMuIA0KV2hp bGUgdGhpcyBoYXMgYmVlbiBkb25lIGZvciBlbnRvdHkgcHJvcGVydHkgdHlwZXMgaW4gc2VjdGlv biA1LjIuMSwgd2Ugd2lsbCAgYWRkIHByaXZhdGUgdXNlIGZvciBFbnRpdHkgRG9tYWluIFR5cGVz LCBhbmQgcGxhbiB0byB1cGRhdGUgdGhlIGRvY3VtZW50IGFjY29yZGluZ2x5IGFzIGZvbGxvd3Mu DQoNCi0tLS0tLS0tLS0gU2VjdGlvbiA1LjEuMS4gIEVudGl0eSBEb21haW4gVHlwZSAtICBwYXJh Z3JhcGggNCwgDQpib3Jyb3dpbmcgZnJvbSBSRkMgNzI4NS4gIA0KDQpPTEQNCiAgIC4uLi4uIEVh Y2ggZW50aXR5IGRvbWFpbiB0eXBlDQogICBNVVNUIGJlIHJlZ2lzdGVyZWQgd2l0aCB0aGUgSUFO QSwgZm9sbG93aW5nIHRoZSBwcm9jZWR1cmUgc3BlY2lmaWVkDQogICBpbiBTZWN0aW9uIDEyLjIu MiBvZiB0aGlzIGRvY3VtZW50Li4uLi4gDQoNCk5FVw0KLi4uLi4gIEVudGl0eSBkb21haW4gdHlw ZSBpZGVudGlmaWVycyBwcmVmaXhlZCB3aXRoICJwcml2OiIgYXJlIHJlc2VydmVkIGZvciBQcml2 YXRlIFVzZQ0KW1JGQzUyMjZdIHdpdGhvdXQgYSBuZWVkIHRvIHJlZ2lzdGVyIHdpdGggSUFOQS4N Cg0KQWxsIG90aGVyIGVudGl0eSBkb21haW4gdHlwZXMgYXBwZWFyaW5nIGluIGFuIEhUVFAgcmVx dWVzdCBvcg0KcmVzcG9uc2Ugd2l0aCBhbiAiYXBwbGljYXRpb24vYWx0by0qIiBtZWRpYSB0eXBl IA0KIE1VU1QgYmUgcmVnaXN0ZXJlZCB3aXRoIHRoZSBJQU5BLCBmb2xsb3dpbmcgdGhlIHByb2Nl ZHVyZSANCnNwZWNpZmllZCAgaW4gU2VjdGlvbiAxMi4yLjIgb2YgdGhpcyBkb2N1bWVudC4NCg0K IEZvciBhbiBlbmRwb2ludCBkb21haW4gdHlwZSBpZGVudGlmaWVyIHdpdGggdGhlICJwcml2OiIg cHJlZml4LCBhbiBhZGRpdGlvbmFsDQpzdHJpbmcgKGUuZy4sIGNvbXBhbnkgaWRlbnRpZmllciBv ciByYW5kb20gc3RyaW5nKSBNVVNUIGZvbGxvdyAoaS5lLiwNCiJwcml2OiIgb25seSBpcyBub3Qg YSB2YWxpZCBlbnRpdHkgZG9tYWluIHR5cGUgaWRlbnRpZmllcikgdG8gcmVkdWNlIHBvdGVudGlh bCBjb2xsaXNpb25zLiAgDQpBIFByaXZhdGUgVXNlIGVudGl0eSBkb21haW4gdHlwZSBpZGVudGlm aWVyIGFuZCBpdHMgYXNzb2NpYXRlZCBpbnRlcm5hbCBzcGVjaWZpY2F0aW9uIE1VU1QgYXBwbHkg dG8gYWxsIHByb3BlcnR5IG1hcHMgIG9mIGFuIElSRC4gDQouLi4uLg0KDQotLS0tLS0tLS0tIFNl Y3Rpb24gNS4xLjIuICBFbnRpdHkgRG9tYWluIE5hbWUNClRoZSAzcmQgcGFyYWdyYXBoIHdpbGwg YmUgbW9kaWZpZWQgYXMgZm9sbG93czoNCg0KT0xEDQogICBFYWNoIGVudGl0eSBkb21haW4gaXMg aWRlbnRpZmllZCBieSBhIHVuaXF1ZSBlbnRpdHkgZG9tYWluIG5hbWUgd2hpY2gNCiAgIGlzIGEg c3RyaW5nIG9mIHRoZSBmb2xsb3dpbmcgZm9ybWF0Og0KDQogICAgICAgRW50aXR5RG9tYWluTmFt ZSA6Oj0gWyBbIFJlc291cmNlSUQgXSAnLicgXSBFbnRpdHlEb21haW5UeXBlDQoNCiAgIFdoZXJl IHRoZSBwcmVzZW5jZSBhbmQgY29uc3RydWN0aW9uIG9mIGNvbXBvbmVudDoNCg0KICAgICAgICJb IFsgUmVzb3VyY2VJRCBdICcuJyBdIg0KDQogICBkZXBlbmRzIG9uIHRoZSBjYXRlZ29yeSBvZiBl bnRpdHkgZG9tYWluLg0KDQpORVcNCiAgIEVhY2ggZW50aXR5IGRvbWFpbiBpcyBpZGVudGlmaWVk IGJ5IGEgdW5pcXVlIGVudGl0eSBkb21haW4gbmFtZSB3aGljaA0KICAgaXMgYSBzdHJpbmcgb2Yg dGhlIGZvbGxvd2luZyBmb3JtYXQ6DQoNCiAgICAgICBFbnRpdHlEb21haW5OYW1lIDo6PSBbIFsg UmVzb3VyY2VJRCBdICcuJyBdIFsgInByaXY6IiBdIEVudGl0eURvbWFpblR5cGUNCg0KICAgV2hl cmUgDQoNCiogIHRoZSBwcmVzZW5jZSBhbmQgY29uc3RydWN0aW9uIG9mIGNvbXBvbmVudDoNCg0K ICAgICAgICJbIFsgUmVzb3VyY2VJRCBdICcuJyBdIg0KDQogICBkZXBlbmRzIG9uIHRoZSBjYXRl Z29yeSBvZiBlbnRpdHkgZG9tYWluLg0KDQoqIHRoZSBjb21wb25lbnQgWyAicHJpdjoiIF0gaXMg cHJlc2VudCB3aGVuIHRoZSBlbnRpdHkgZG9tYWluIHR5cGUgaXMgZGVmaW5lZCBmb3IgUHJpdmF0 ZSBVc2UuDQoNCi0tLS0tLS0tLS0gU2VjdGlvbiAxMi4yIEFMVE8gRW50aXR5IERvbWFpbiBUeXBl IFJlZ2lzdHJ5DQoNCi0tLSBBZnRlciBwYXJhZ3JhcGggMiwgd2Ugd2lsbCBhZGQgYSAxLXNlbnRl bmNlIHBhcmFncmFwaDogIkFzIHNwZWNpZmllZCBpbiBTZWN0aW9uIDUuMS4xLCBpZGVudGlmaWVy cyBwcmVmaXhlZCB3aXRoICJwcml2OiIgYXJlDQpyZXNlcnZlZCBmb3IgUHJpdmF0ZSBVc2Ugd2l0 aG91dCBhIG5lZWQgdG8gcmVnaXN0ZXIgd2l0aCBJQU5BLiINCg0KLS0tIFRhYmxlIDIgd2lsbCBo YXZlIGFuIGFkZGl0aW9uYWwgbGluZQ0KSWRlbnRpZmllciAtPiBwcml2Og0KSW50ZW5kZWQgU2Vt YW50aWNzIC0+IFByaXZhdGUgdXNlDQoNCi0tLS0tLS0tLS0gNS4yLjEuICBFbnRpdHkgUHJvcGVy dHkgVHlwZSAtIHBhcmFncmFwaCAzDQphZGQgc2VudGVuY2UgaW4gdGhlIGVuZDoNCiJBIFByaXZh dGUgVXNlIGVudGl0eSBkb21haW4gdHlwZSBpZGVudGlmaWVyIGFuZCBpdHMgYXNzb2NpYXRlZCBp bnRlcm5hbCBzcGVjaWZpY2F0aW9uIE1VU1QgYXBwbHkgdG8gYWxsIHByb3BlcnR5IG1hcHMgIG9m IGFuIElSRC4gIg0KDQotLS0tLS0tLS0tIDUuMi4yLiAgRW50aXR5IFByb3BlcnR5IE5hbWUNCk9M RA0KRW50aXR5UHJvcGVydHlOYW1lIDo6PSBbIFJlc291cmNlSUQgXSAnLicgRW50aXR5UHJvcGVy dHlUeXBlDQoNCk5FVw0KRW50aXR5UHJvcGVydHlOYW1lIDo6PSBbIFJlc291cmNlSUQgXSAnLicg IFsgInByaXY6IiBdIEVudGl0eVByb3BlcnR5VHlwZQ0KDQotLS0tLS0tLS0tIFNlY3Rpb24gMTIu My4gIEFMVE8gRW50aXR5IFByb3BlcnR5IFR5cGUgUmVnaXN0cnkNCi0tLSBBZnRlciBwYXJhZ3Jh cGggMSwgd2Ugd2lsbCBhZGQgYSAxLXNlbnRlbmNlIHBhcmFncmFwaDogIkFzIHNwZWNpZmllZCBp biBTZWN0aW9uIDUuMi4xLCBpZGVudGlmaWVycyBwcmVmaXhlZCB3aXRoICJwcml2OiIgYXJlDQpy ZXNlcnZlZCBmb3IgUHJpdmF0ZSBVc2Ugd2l0aG91dCBhIG5lZWQgdG8gcmVnaXN0ZXIgd2l0aCBJ QU5BLiINCj4NCj4NCg0K From nobody Tue Oct 19 11:53:40 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8129A3A0C6C for ; Tue, 19 Oct 2021 11:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aiven.io 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 exms-mwBHJZA for ; Tue, 19 Oct 2021 11:47:56 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 750E53A0C77 for ; Tue, 19 Oct 2021 11:47:56 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id g10so16244424edj.1 for ; Tue, 19 Oct 2021 11:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=KUKDDk/ffAhmijuE56Xgez1aib8QCR1QCYwy41nJjlY=; b=M7NpuFPcxHHQo7uBlA1+h0eEQwEtW2e9VFo+itBwO4u37M0hNg1oE3jN4ne8bVfuIs OadXQxpHQsoXnBj3nz1BUIwVXl+iMtijIrumEdcZPeHSHNOoENj52HcfktnkOCmQBMCk Skpkue7oG6v6QjHKmyzMwsL54qjK33pGTA47s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=KUKDDk/ffAhmijuE56Xgez1aib8QCR1QCYwy41nJjlY=; b=Tq4PpU000cIZlb/rCFpgRcFc2FxKEUq8DpJTiK3jVPOpkIelHBADsn1odYIgXsHziB ZdIR3613iesk8h/JnnZu20Leo2bEH6T7gyD8K34Pa8g825AWpPaHfBRYkxV9TotIo7lw 0lLZisa55sJ2fEtgAhirgQWU+wYiRFauxQ8fuGT6RdubLhwgI5pz1szi8Dno7vpzSNrr CgvoS7qTxi/etIW/4gUDJvzaKtizsDG3g3WUffYEVMSF1Zz/CvPB/mdH3EUfDoY6gmO5 2g6LkT8n2/VrZTZQ6lsSutxANnXF5VLgYygKjwdmo4vHs66w2rexqxUa0MvEYiRJVDkZ +Suw== X-Gm-Message-State: AOAM531fOd4sOiwYFNzVewIMwJxwwiA4HDeQwBIN5STkN0sPGa+ebpdn kF2TnQyuzTce3fi0/XQnTyt6aQ== X-Google-Smtp-Source: ABdhPJxFJlc564UXXF6LF6TRWLcgZCUwc7kGPWLRcgJPIVHfsaESzP24JfggcoO++Hk7m/QfVSo5ow== X-Received: by 2002:a05:6402:84d:: with SMTP id b13mr57086865edz.6.1634669272964; Tue, 19 Oct 2021 11:47:52 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca. [193.110.157.194]) by smtp.gmail.com with ESMTPSA id v8sm11938126edj.7.2021.10.19.11.47.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Oct 2021 11:47:52 -0700 (PDT) Date: Tue, 19 Oct 2021 14:47:49 -0400 (EDT) From: Paul Wouters To: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" cc: "secdir@ietf.org" , "draft-ietf-alto-unified-props-new.all@ietf.org" , "alto@ietf.org" , "last-call@ietf.org" In-Reply-To: Message-ID: <40ff27ba-5c94-efc4-3b4e-41a9d390f590@nohats.ca> References: <163174184742.9427.9373192733692803905@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: X-Mailman-Approved-At: Tue, 19 Oct 2021 11:49:39 -0700 Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-alto-unified-props-new-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2021 18:48:02 -0000 On Tue, 19 Oct 2021, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote: > Thanks a lot for your review. A new version is under edition to address your comments. > Please see inline how we plan to address them. Can you let us know whether the proposed updates meet your expectations? That looks good, thanks! >> appropriate to refer to RFC 7285 for the Security Considerations, as is done in >> this document. > [ [SR] ] > [ [SR] ] Do you mean we should keep the security section of this document as it is or should we shorten it? I meant it is good as is. >> While extensions to a protocol don't necessitate an Updates: clause, in this >> case I think it should because the document addresses shortcomings in the >> original protocol. That is, new implementations are expected to really require >> implementing this new document as part of the "core specification". Thus >> implementers reading 7285 should really be warned to also read (and >> implement) this document. > > [ [SR] ] we do not oppose entities against endpoints therefore this extension does not intend to replace endpoints by entities. Both are useful, as some use cases can live with the base protocol. A discussion thread has just started on this point and we will like to have your conclusions on the exposed points of view An RFC update does not mean "do not implement what was in the older one". Update really means that one should read (and ideally implement) both documents to get the updated picture of what the IETF believes should be implemented. If this is just an optional extension, then Update: is not needed. But if it modifies the previous document to clarify or extend in a way that is core to the protocol, it should probably Update: the previous RFC so implementers know there is more to take into account than just that core older document. >> The IANA considerations are quite verbose. Usually, this section only contains > [ [SR] ] We have identified some paragraphs and text that are more considerations than specifications: Thanks. I think it will look better. Generally, think of this Section as something only the IANA operator will read to actually perform the registry updates and that any other reader will skip the section entirely. Paul From nobody Tue Oct 19 19:06:29 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637063A048A; Tue, 19 Oct 2021 19:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 YLNcnMgNe_55; Tue, 19 Oct 2021 19:04:26 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E414D3A040A; Tue, 19 Oct 2021 19:04:25 -0700 (PDT) Received: from fraeml735-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HYv3f0rRxz67yJR; Wed, 20 Oct 2021 10:01:18 +0800 (CST) Received: from dggeml702-chm.china.huawei.com (10.3.17.135) by fraeml735-chm.china.huawei.com (10.206.15.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.15; Wed, 20 Oct 2021 04:04:21 +0200 Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeml702-chm.china.huawei.com (10.3.17.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.15; Wed, 20 Oct 2021 10:04:19 +0800 Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2308.015; Wed, 20 Oct 2021 10:04:19 +0800 From: Qin Wu To: Paul Wouters , "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" CC: "secdir@ietf.org" , "draft-ietf-alto-unified-props-new.all@ietf.org" , "alto@ietf.org" , "last-call@ietf.org" Thread-Topic: [Last-Call] Secdir last call review of draft-ietf-alto-unified-props-new-18 Thread-Index: AdfFVnpo4uclBceW0kW1LdMhbWJK7A== Date: Wed, 20 Oct 2021 02:04:19 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-alto-unified-props-new-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 02:04:32 -0000 >> While extensions to a protocol don't necessitate an Updates: clause,=20 >> in this case I think it should because the document addresses=20 >> shortcomings in the original protocol. That is, new implementations=20 >> are expected to really require implementing this new document as part=20 >> of the "core specification". Thus implementers reading 7285 should=20 >> really be warned to also read (and >> implement) this document. > > [ [SR] ] we do not oppose entities against endpoints therefore this=20 > extension does not intend to replace endpoints by entities. Both are=20 > useful, as some use cases can live with the base protocol. A=20 > discussion thread has just started on this point and we will like to=20 > have your conclusions on the exposed points of view An RFC update does not mean "do not implement what was in the older one". U= pdate really means that one should read (and ideally implement) both docume= nts to get the updated picture of what the IETF believes should be implemen= ted. If this is just an optional extension, then Update: is not needed. But= if it modifies the previous document to clarify or extend in a way that is= core to the protocol, it should probably Update: the previous RFC so imple= menters know there is more to take into account than just that core older d= ocument. [Qin Wu] Thank Paul for comment on this issue, ALTO WG has revisited issues= again and the conclusion we made is this draft just focuses on an optional= extension, a few explanation text will be added into abstract to clarify w= hy update tag is not needed and confusion words will be cleaned up. https://mailarchive.ietf.org/arch/msg/alto/ykK66Uv_ypbsh9mn9SPu0QL01-k/ From nobody Tue Oct 19 19:42:46 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA233A0CB1; Tue, 19 Oct 2021 19:42:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Sean Turner via Datatracker To: Cc: draft-ietf-taps-interface.all@ietf.org, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163469775639.5436.17223656477070371812@ietfa.amsl.com> Reply-To: Sean Turner Date: Tue, 19 Oct 2021 19:42:36 -0700 Archived-At: Subject: [secdir] Secdir early review of draft-ietf-taps-interface-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 02:42:37 -0000 Reviewer: Sean Turner Review result: Has Issues This is an early sector review. Based on the ARTART early reviews of this I-D and the -arch I-D, there is no doubt going to need to be another review after the authors get done restructuring both I-Ds. BTW: Theresa thank you for the heads up about that restructuring. It forced me to read the -arch and -impl I-Ds, but that probably helped me not make silly requests of the authors/WG. tl;dr: I picked "has issues" knowing there is a rewrite on the way and I would like to reserve final judgement until then. I apologize upfront because I am going to ramble a bit before I get to the specifics: The taps I-Ds are about “a protocol-independent Transport Services Application Programming Interface (API).” I took a pretty liberal approach when reviewing this I-D from a security perspective because these I-Ds are somewhat different than the “normal” protocol I-Ds. As noted in the -arch I-D: these I-Ds do not specify “specific protocols or algorithms” … gasp. But, that’s probably okay in this context. I wondered what you would say about an API: - Apps need to use the API properly! check: see -arch I-D - Implementation/Library needs to be from trust source! check: see -interface I-D - Apps need to use the right keys at the right time! check: see -arch I-D - Avoid fallback/downgrade to insecure protocols! check: see -arch I-D and -impl I-D - Deal with 0-RTT! check: see -impl I-D - Address privacy aspects! check: see -interface I-D I mean maybe you could add something about: - randomness for keys - but that better already be in the security protocol specifications so I do not think it is absolutely needed here. - following good programming techniques - but I am not sure where you would point nor whether it really makes sense to do so. I think I found what I was looking for is somewhere in the stack of I-Ds. Am I worried somebody can implement this wrong. Sure. But, not any more than I would be for any other protocol. Now on to the specifics: NOTE: I tried not repeat anything from the ARTART review. 0) s6: maybe this wording would be better? For these two sentences are you trying to say that MUST else if? OLD: At least one Local Endpoint MUST be specified if the Preconnection is used to Listen() for incoming Connections, but the list of Local Endpoints MAY be empty if the Preconnection is used to Initiate() connections. NEW: At least one Remote Endpoint MUST be specified if the Preconnection is used to Initiate() Connections, but the list of Remote Endpoints MAY be empty if the Preconnection is used to Listen() for incoming Connections 1) s6.3.1 I know this is an example, but can we replace: SecurityParameters.Set(supported-group, "secp256k1") with SecurityParameters.Set(supported-group, "secp256r1") r1 the current MTI for TLS. k1 is for bitcoin :) Or, is this where I get a bitcoin because I caught the shiny object? :) 2) s6.3.2: Is this like checking the certificate status? 3) s8.1.1- I read this definition a bunch. Are there two special values? The Type line says “Full Coverage” is special, but then the description says “0” is special too. Maybe look at s91.3.6 for inspiration? 4) s8.1.2: Any reason it’s not called connPriority? Seems arbitrary to drop the end of the word when connTimeout is even longer. 5) s8.1.2-should “Type” line also include (non-negative) like s8.1.1 and s9.1.3.2 do? 6) s8.1.3/.4: The Numeric values specifies seconds, minutes, hours, or millennia? 7) s8.1.6: don’t you need to specify the Type? I guess Enumeration is what you’re after? 8) s8.1.11.2/.3/.4: Are these sizes in bytes too like 8.1.11.1? 9) s8.2.1: RFC 5482 allows granularity of minutes or seconds don’t you need to say which it is here? 10) s8.2.2: Is there some reason it’s not called tcp.userTimeoutEnabled? 11) s8.2.3: Is there some reason it’s not called tcp.userTimeoutChangable? 12) s9.1.3.2: Why 100? 13) s9.1.3.2: Why shorten to msrPrio when msgOrdered is almost as long and safelyReplayable is longer? 14) A.1: Could the caution about freeing memory be generalized? 15) What follows are the I-D nits references to check. Some of these might be on purpose: == Outdated reference: A later version (-11) exists of draft-ietf-taps-arch-10 ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-06) exists of draft-ietf-httpbis-priority-03 == Outdated reference: A later version (-10) exists of draft-ietf-taps-impl-09 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) From nobody Wed Oct 20 02:43:44 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6AB3A095C; Wed, 20 Oct 2021 02:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 vogPjsApKCZu; Wed, 20 Oct 2021 02:39:14 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50120.outbound.protection.outlook.com [40.107.5.120]) (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 9510E3A108F; Wed, 20 Oct 2021 02:37:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NS4LWo1vRa60F2gCcNL5p6ycyChGXbJqKwiI/5apClsVKOVrpjDcppsTniTypVf8XfbamTp4w1GUALbfD7jpMnx/W41qlUmo5U3fk/TGFCLmBQiwhAbQBN2irY67393c7o7MqeRn9YNuHdpG+EDHGY9rEx2nYG9GAwcsxEPt/jmnA0WGWehATwjMT+nbSA0xo/EHsek9i3QrMlbq4K7oJSuDwLcqM+DU3xcFUy7z2eWiIPlIcbUkrxnfLWrUx6uw9MwL9nVRcbYFDCD4GG3dNQyNCnVWNNKHwhjOe2bzNWHCCJiLsUFBXf6NBrYWwQVfYmlrnbjLLP3NPTwpY0/PvQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1JVYcOhVcZ1oy3UsGxqAZY2VSqYuLMxBqwEtdhDM4Ig=; b=LI8r/ThZVpScG0mWJlW1HDkADYsnR6/G3Y5BiuIG29QyjDqzui3HRMnphK6QiUffHm9tbxoFoGfedITvnLc7IhZrjZYwUo5D1Qb3ypyWlu/s2VpczGm7P4081MThH355YI/lchs7+CElsqitUh/S3WD9vr87PfndvWVnPZpQ+vvCBochwRlgUx6fxoHSAFdCkyjfG62vpoTpNrzbVFvAg6IqVQtqWxrGOAXtGKfkHQIC/jGFjuWpXLmBLVJAiJVaZyAccThvqhFM/rhSvHTlPq836zoA3eMGlp3qWFLVdfQdCXRTDNiqs1wdv0jQ7l2J0kN5hdVsTZCQmx+HFqRk1g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1JVYcOhVcZ1oy3UsGxqAZY2VSqYuLMxBqwEtdhDM4Ig=; b=n/E0OXrueV/pibvR9utDE6FoIXmfCgaykUvTxHt39UFA0zpaYU+9IbC0DLUJp0rtR1C7IQWJCn5Enc2jtCadcllb7ysAYCS4RsLPSChC20uxBWQoZzPef/5+lvb3CG4zIpZBkXZI29F4UI4RvzTfUhy16V8SPq5kyYz6nYodBrk= Received: from PR3PR07MB7018.eurprd07.prod.outlook.com (2603:10a6:102:7d::13) by PR1PR07MB5033.eurprd07.prod.outlook.com (2603:10a6:102:8::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.13; Wed, 20 Oct 2021 09:37:51 +0000 Received: from PR3PR07MB7018.eurprd07.prod.outlook.com ([fe80::905b:f94d:2807:c70]) by PR3PR07MB7018.eurprd07.prod.outlook.com ([fe80::905b:f94d:2807:c70%6]) with mapi id 15.20.4628.016; Wed, 20 Oct 2021 09:37:51 +0000 From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" To: Paul Wouters CC: "secdir@ietf.org" , "draft-ietf-alto-unified-props-new.all@ietf.org" , "alto@ietf.org" , "last-call@ietf.org" Thread-Topic: [Last-Call] Secdir last call review of draft-ietf-alto-unified-props-new-18 Thread-Index: AQHXqnnk7JtJLI4x6UiiL1aHEjfKt6vatqJggAAoCoCAAPhvMA== Date: Wed, 20 Oct 2021 09:37:51 +0000 Message-ID: References: <163174184742.9427.9373192733692803905@ietfa.amsl.com> <40ff27ba-5c94-efc4-3b4e-41a9d390f590@nohats.ca> In-Reply-To: <40ff27ba-5c94-efc4-3b4e-41a9d390f590@nohats.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia-bell-labs.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8a5d9046-f7b2-4f20-6d1f-08d993ad4938 x-ms-traffictypediagnostic: PR1PR07MB5033: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: a6jl3gIkZQBEjPoTnCNPqUEO0i4Vi0xZOgGdvAQMbJSkvbkzW6pAfwJUP4uhEbS3aKiHqyQOWB5HfjyUOVeiS6OyILF6dIG34IAAN+RWBMVL4ePPJTBF8mgwSTNvU41CY+3GMLhD7lKI+BNsI3WTstRuKEPdo6cs0fXwYQyISvs/BZl7eRmHOFV7t6mx0EPyMiGpVnRzMTIYIYpVLfD8hEUBIEim2MUHXOp34hBflgohtRQaQZuOEjP1eRHQAqN6amGxubZsJLsEwJCUrq0brnQpDvrrXRsF6B62unWnjgBd7v4TQMWglYnpII2KMpNijvtr3f/nXdarqN/Z59+YvDrVS1yQ+kIe1wAHM798jdsWeVzNU+ObyICADCQ6AWRgxUQtWBtL9sB8t6QCcVRrHS+Av8WFGGm5ocrX2UtRnN+KCYG3GxFH61BOIoEArAOFELzoUyxv/tmyX1uMiXykJqhu0lRQCAwRpVZ5dZnmtxTMqfYvGksSJsvh0/Exs/5ZElS0O7+Onz1znXiImkhSqoAvmBVBmxBl2jf06MzMo9LT0wwLCvs02AOObv5bSjXujE6IuCEgO2VuTaM7QmrrU0Na34QFWDUqHmpCZgUnK41D/NQte2N4g8gN2MXuAr4OxAuMNWjpX+62EaVK2DRhn5tgiMtrp8VH8uEGQ27QbZwfXIGONLItKD+jPaWgaTHvaiWuLBdZaj5GkMrpTI7Xng== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3PR07MB7018.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66476007)(64756008)(66556008)(66446008)(8676002)(76116006)(66946007)(55016002)(186003)(6916009)(38070700005)(5660300002)(86362001)(122000001)(71200400001)(2906002)(54906003)(38100700002)(4326008)(8936002)(82960400001)(316002)(52536014)(9686003)(26005)(83380400001)(33656002)(508600001)(7696005)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?t1v5ss3R+2F+4WlhiDLOdJ5biVk7EO1yrnfwBvMwn12DSNokScN9sur4ldIz?= =?us-ascii?Q?AYVukkox7jsCgI6HoVPiyvdc2rdiqa61zVGgAcEko49YW4ZZDEFRxn3XX1Ih?= =?us-ascii?Q?3K+JGBPN2Tq1GUqm06y5rPyzJAtu6E8Ua3ob0kTdp+GlNkXybfRlX7enZY70?= =?us-ascii?Q?eMny88bTrHUJiTt2r1z7narFBF+sE7gGnaLXzS2N2bM+HZNqys7/D0fPFhOI?= =?us-ascii?Q?xEdScELNjIPV9uF41uR0jbIS6hxneeuEamp8gAa3zQ7zV7RpPJaiL2yLgkiA?= =?us-ascii?Q?wvYWMj/JaplAYf4bc6cGJxr+wMtARmzRaVj9VNHsXfam9esRyhO7gK5HOSSO?= =?us-ascii?Q?a8O31C5EmV4vzcBWBvl+eIBsFIBUMGSzan93GcC8VJ4poEqNQD4gjYWy239K?= =?us-ascii?Q?EKJNvSr30IK9ncmUw9uEXBkZHrU++JoFz1wMwPqzj/a1kqLoVmIQMxN2SuSX?= =?us-ascii?Q?qbmzSDhJe4+6Km5en3K3ZYHj6ESZdQH02O6V+BYDB6quhBV9WXoR7nDWxwRP?= =?us-ascii?Q?+qH+rLAczpXTocBkVvIsKqOVa3B9AAReza0DJcr12eRprP4vDR1PotBzjbuY?= =?us-ascii?Q?0Gc5hYeuGRhCSgISozglNr31bkjjubQ+DJyCR09oasuNGWtGbO7lKEDdqwQD?= =?us-ascii?Q?V/Zrct2TNMweGLDrEpLiZmx1tOs8A+YHc3zqz0vD7DAqHIMmySLiKPkBboMU?= =?us-ascii?Q?bY43+naYuabTyxfZsXzXTzoTrjJDe2P5viNcknO6gOxn7OAxILpFIL1Bq4n6?= =?us-ascii?Q?+MHhw2NizIRNbN5PMZYUX2WCE0SbdtyKCYBNrtu7URexMFWgq5L4BujaiT7Z?= =?us-ascii?Q?aemZq4SPEH+8WlDcJONdiLZeO3Kagd0CyshrFVSNft4ikhzPB5qQrzXQo9dz?= =?us-ascii?Q?RQTlF1OLII5qM5KJP31LwDMFPZkmM59IVXFJm/WdvTLRM74KjXlShBgZeWB+?= =?us-ascii?Q?mUt9saJKniI+S0KDeRbeVA1eLnM3L4g3qiOIwg6O58p8vWv9FjWoHEFVvPvA?= =?us-ascii?Q?fhF51i4/yJ64t/mLQkGaPzzm56Izp579lBOkpP+7yMJiwS4Ryk2Dt9eMBwnR?= =?us-ascii?Q?BQhUyNiW4FbjqIKC3i7lyM3/r2XCrTZSp1DhVZvDHlIFr0IV55evM2Q1BKPq?= =?us-ascii?Q?n0leodfJ7RiecK3kDmwrgNLqq1uDgEbYY1h89M2mrap9KTaeaTo3TTFWz7kc?= =?us-ascii?Q?U50RhTEGzAsLjAgy8SEvEbMlM6eIHSYzcwPcl4TJBvfr4XZKiUTcfHVxJwKq?= =?us-ascii?Q?zj7jLb8olHqI32TPAwMNqpzGrYlhUrNKOVliY8nGgtm6Q1tRBWxLUUxtfiue?= =?us-ascii?Q?PaRrn3p3rf4YWurJeLGmZZYAOQSiCB88BGQ7WCTNBhGSpajCld2Q7C0QTzxG?= =?us-ascii?Q?6qEbSQlF4l/nF4XOjkC+o1bvmyLpxnuGrm5q+6oZP7Du/4Tx0Lq7A0X3sFWR?= =?us-ascii?Q?CkuqPyv88DPpSZRe8lnDqymXB3uiJg+Th02AGlNLDKH2ISYn1X7gnNMimoHK?= =?us-ascii?Q?nICi9IZzjdSkg2JhS2j87dwht+6rb5OmsTLhaADdZGwcqwi2IdtXUMTUNvbZ?= =?us-ascii?Q?M5Zymf0KDQfW2bWhXDpCXAFir2QnIN5idSB2a0j+37KMOE7bDl0/8b56Ejka?= =?us-ascii?Q?qJXiTqYE8YChMhGdKT0MlDVnKm4cFam25DWvLQjmSo7I3jEyhCB2J17pGvyj?= =?us-ascii?Q?mf0VMTKgJOScxt7awDuFYrZbVfsqhkPbwRz0tOeKfANfA+0BpMH+JLlY+HBs?= =?us-ascii?Q?GiknqWowzg=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PR3PR07MB7018.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8a5d9046-f7b2-4f20-6d1f-08d993ad4938 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2021 09:37:51.5889 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Z3DLFfSewtcjz9qn1FavbgfDrJMiKDk0FxRwS8lfrJlLtei9jmi86dg90WLYpWEWqUbvr4wD5FnZKSg+fyKL/b19mTV0TjX89+yDcDLVVyKxLwWcEugpxQK7JCX63SA8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB5033 Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-alto-unified-props-new-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 09:39:20 -0000 Hello Paul,=20 Thanks a lot for your feedback. You will see the updates in version 19 Best regards, Sabine >-----Original Message----- >From: Paul Wouters >Sent: Tuesday, October 19, 2021 8:48 PM >To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) > >Cc: secdir@ietf.org; draft-ietf-alto-unified-props-new.all@ietf.org; >alto@ietf.org; last-call@ietf.org >Subject: Re: [Last-Call] Secdir last call review of draft-ietf-alto-unifie= d-props- >new-18 > >On Tue, 19 Oct 2021, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote: > >> Thanks a lot for your review. A new version is under edition to address = your >comments. >> Please see inline how we plan to address them. Can you let us know >whether the proposed updates meet your expectations? > >That looks good, thanks! > >>> appropriate to refer to RFC 7285 for the Security Considerations, as >>> is done in this document. >> [ [SR] ] >> [ [SR] ] Do you mean we should keep the security section of this documen= t >as it is or should we shorten it? > >I meant it is good as is. > >>> While extensions to a protocol don't necessitate an Updates: clause, >>> in this case I think it should because the document addresses >>> shortcomings in the original protocol. That is, new implementations >>> are expected to really require implementing this new document as part >>> of the "core specification". Thus implementers reading 7285 should >>> really be warned to also read (and >>> implement) this document. >> >> [ [SR] ] we do not oppose entities against endpoints therefore this >> extension does not intend to replace endpoints by entities. Both are >> useful, as some use cases can live with the base protocol. A >> discussion thread has just started on this point and we will like to >> have your conclusions on the exposed points of view > >An RFC update does not mean "do not implement what was in the older one". >Update really means that one should read (and ideally implement) both >documents to get the updated picture of what the IETF believes should be >implemented. If this is just an optional extension, then Update: is not ne= eded. >But if it modifies the previous document to clarify or extend in a way tha= t is >core to the protocol, it should probably Update: the previous RFC so >implementers know there is more to take into account than just that core >older document. > >>> The IANA considerations are quite verbose. Usually, this section only >>> contains > >> [ [SR] ] We have identified some paragraphs and text that are more >considerations than specifications: > >Thanks. I think it will look better. Generally, think of this Section as s= omething >only the IANA operator will read to actually perform the registry updates = and >that any other reader will skip the section entirely. > >Paul From nobody Sat Oct 23 07:08:54 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D803A0A6C for ; Sat, 23 Oct 2021 07:08:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <163499812781.18499.6681957156770115486@ietfa.amsl.com> Date: Sat, 23 Oct 2021 07:08:51 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2021 14:08:52 -0000 Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview For telechat 2021-10-28 Reviewer LC end Draft Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy Last calls: Reviewer LC end Draft Shaun Cooley 2021-10-18 draft-ietf-jmap-smime Scott Kelly 2021-10-27 draft-ietf-regext-rfc7484bis Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 Catherine Meadows 2021-10-28 draft-ietf-calext-ical-relations Alexey Melnikov 2021-10-27 draft-ietf-opsawg-ntf Daniel Migault 2021-10-26 draft-ietf-idr-bgp-ext-com-registry Adam Montville 2021-11-23 draft-eggert-bcp45bis Russ Mundy 2021-10-26 draft-ietf-rum-rue Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Samuel Weiler 2021-08-25 draft-ietf-alto-path-vector Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2021-08-30 draft-ietf-alto-cdni-request-routing-alto Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Liang Xia 2021-03-17 draft-ietf-core-sid Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy Dacheng Zhang 2021-09-07 draft-ietf-bess-evpn-bum-procedure-updates Early review requests: Reviewer Due Draft Stephen Farrell 2021-09-15 draft-ietf-ippm-ioam-direct-export Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Kathleen Moriarty 2021-10-25 draft-ietf-dots-multihoming Tina Tsou 2021-08-25 draft-ietf-opsawg-sbom-access Loganaden Velvindron 2021-08-18 draft-ietf-taps-arch Next in the reviewer rotation: Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tim Polk Vincent Roca Kyle Rose Joseph Salowey Rich Salz From nobody Sat Oct 23 13:54:27 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439FD3A0DF8 for ; Sat, 23 Oct 2021 13:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 c-fv7RagDc1p for ; Sat, 23 Oct 2021 13:54: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 0B2253A0DF6 for ; Sat, 23 Oct 2021 13:54:18 -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 19NKs9tJ025984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 23 Oct 2021 16:54:15 -0400 Date: Sat, 23 Oct 2021 13:54:09 -0700 From: Benjamin Kaduk To: Sean Turner Cc: secdir@ietf.org Message-ID: <20211023205409.GY88762@kduck.mit.edu> References: <163469775639.5436.17223656477070371812@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <163469775639.5436.17223656477070371812@ietfa.amsl.com> Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-taps-interface-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2021 20:54:25 -0000 Hi Sean, A big thanks for doing the review in the context of the pending changes prompted by the ARTART review, and the cluster of related documents as a whole! It's great to see that you made a checklist of what's needed (security-wise) for an API and saw that each was covered somewhere in the cluster of documents, as well as providing the specific comments on this draft. Thanks again, Ben On Tue, Oct 19, 2021 at 07:42:36PM -0700, Sean Turner via Datatracker wrote: > Reviewer: Sean Turner > Review result: Has Issues > > This is an early sector review. Based on the ARTART early reviews of this I-D > and the -arch I-D, there is no doubt going to need to be another review after > the authors get done restructuring both I-Ds. > > BTW: Theresa thank you for the heads up about that restructuring. It forced me > to read the -arch and -impl I-Ds, but that probably helped me not make silly > requests of the authors/WG. > > tl;dr: I picked "has issues" knowing there is a rewrite on the way and I would > like to reserve final judgement until then. > > I apologize upfront because I am going to ramble a bit before I get to the > specifics: > > The taps I-Ds are about “a protocol-independent Transport Services Application > Programming Interface (API).” I took a pretty liberal approach when reviewing > this I-D from a security perspective because these I-Ds are somewhat different > than the “normal” protocol I-Ds. As noted in the -arch I-D: these I-Ds do not > specify “specific protocols or algorithms” … gasp. But, that’s probably okay in > this context. > > I wondered what you would say about an API: > - Apps need to use the API properly! check: see -arch I-D > - Implementation/Library needs to be from trust source! check: see -interface > I-D - Apps need to use the right keys at the right time! check: see -arch I-D - > Avoid fallback/downgrade to insecure protocols! check: see -arch I-D and -impl > I-D - Deal with 0-RTT! check: see -impl I-D - Address privacy aspects! check: > see -interface I-D > > I mean maybe you could add something about: > > - randomness for keys - but that better already be in the security protocol > specifications so I do not think it is absolutely needed here. > > - following good programming techniques - but I am not sure where you would > point nor whether it really makes sense to do so. > > I think I found what I was looking for is somewhere in the stack of I-Ds. Am I > worried somebody can implement this wrong. Sure. But, not any more than I would > be for any other protocol. > > Now on to the specifics: > > NOTE: I tried not repeat anything from the ARTART review. > > 0) s6: maybe this wording would be better? > > For these two sentences are you trying to say that MUST else if? > > OLD: At least one Local Endpoint MUST be specified if the Preconnection is > used to Listen() for incoming Connections, but the list of Local > Endpoints MAY be empty if the Preconnection is used to Initiate() > connections. > > NEW: At least one Remote Endpoint MUST > be specified if the Preconnection is used to Initiate() Connections, > but the list of Remote Endpoints MAY be empty if the Preconnection is > used to Listen() for incoming Connections > > 1) s6.3.1 I know this is an example, but can we replace: > > SecurityParameters.Set(supported-group, "secp256k1") > > with > > SecurityParameters.Set(supported-group, "secp256r1") > > r1 the current MTI for TLS. k1 is for bitcoin :) > > Or, is this where I get a bitcoin because I caught the shiny object? :) > > 2) s6.3.2: Is this like checking the certificate status? > > 3) s8.1.1- I read this definition a bunch. Are there two special values? The > Type line says “Full Coverage” is special, but then the description says “0” is > special too. Maybe look at s91.3.6 for inspiration? > > 4) s8.1.2: Any reason it’s not called connPriority? Seems arbitrary to drop the > end of the word when connTimeout is even longer. > > 5) s8.1.2-should “Type” line also include (non-negative) like s8.1.1 and > s9.1.3.2 do? > > 6) s8.1.3/.4: The Numeric values specifies seconds, minutes, hours, or > millennia? > > 7) s8.1.6: don’t you need to specify the Type? I guess Enumeration is what > you’re after? > > 8) s8.1.11.2/.3/.4: Are these sizes in bytes too like 8.1.11.1? > > 9) s8.2.1: RFC 5482 allows granularity of minutes or seconds don’t you need to > say which it is here? > > 10) s8.2.2: Is there some reason it’s not called tcp.userTimeoutEnabled? > > 11) s8.2.3: Is there some reason it’s not called tcp.userTimeoutChangable? > > 12) s9.1.3.2: Why 100? > > 13) s9.1.3.2: Why shorten to msrPrio when msgOrdered is almost as long and > safelyReplayable is longer? > > 14) A.1: Could the caution about freeing memory be generalized? > > 15) What follows are the I-D nits references to check. Some of these might be > on purpose: > > == Outdated reference: A later version (-11) exists of > draft-ietf-taps-arch-10 > > ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) > > == Outdated reference: A later version (-06) exists of > draft-ietf-httpbis-priority-03 > > == Outdated reference: A later version (-10) exists of > draft-ietf-taps-impl-09 > > -- Obsolete informational reference (is this intentional?): RFC 5245 > (Obsoleted by RFC 8445, RFC 8839) > > -- Obsolete informational reference (is this intentional?): RFC 5766 > (Obsoleted by RFC 8656) > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview From nobody Sat Oct 23 15:47:39 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE8F3A0870; Sat, 23 Oct 2021 15:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.48 X-Spam-Level: X-Spam-Status: No, score=-1.48 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 6p7ZW5s71uiV; Sat, 23 Oct 2021 15:46:45 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147F23A0908; Sat, 23 Oct 2021 15:46:42 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:dc3d:ff49:1741:d8c3]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 345AD721E2807; Sun, 24 Oct 2021 00:46:34 +0200 (CEST) From: tuexen@fh-muenster.de Message-Id: <0D125385-E009-4EAD-8087-F7A90F74663B@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_71478D1B-7A86-475A-A62D-5A9AC11FD86E"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Sun, 24 Oct 2021 00:46:33 +0200 In-Reply-To: <2bac74f5-e134-d50c-a640-4a87fdbc5790@mandelberg.org> Cc: secdir@ietf.org, iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org To: David Mandelberg References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> <2bac74f5-e134-d50c-a640-4a87fdbc5790@mandelberg.org> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2021 22:46:54 -0000 --Apple-Mail=_71478D1B-7A86-475A-A62D-5A9AC11FD86E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 14. Oct 2021, at 22:55, David Mandelberg = wrote: >=20 > Op 14-10-2021 om 15:31 schreef tuexen@fh-muenster.de: >>> On 14. Oct 2021, at 19:57, David Mandelberg = wrote: >>> =46rom a security perspective, there are multiple good options for = MAC algorithms to use here, including some HMAC algorithms. (I don't = know enough about MAC algorithms to be too much more specific.) >>>=20 >>> =46rom a standards perspective, I think the doc should be clear = about what the requirements actually are. This seems like an unusual = case, because there are no interoperability concerns as far as I can = tell. (Except maybe length? Are there constraints on the length of the = field?) I don't know what the right thing to do here is, but I'd lean = towards 1) documenting the requirements for interoperability, 2) = documenting the requirements for security, and 3) providing an example = algorithm that implementations should use unless they have a reason to = pick something different. Do other people think that's a good way to go? = Or should it be kept simpler and just recommend something specific? >>>=20 >>> If it helps, here's some draft text of what I'm thinking: >> You are suggesting to add this to section 5.1.3, I guess. So are you = suggesting to remove the MAC entry from Section 2.3? >=20 > Yes, if you think that makes sense. OK, removed the text from Section 2.3. I updated the text in Section 5.1.3 such that the new paragraph reads: The hashing method used to generate the MAC is strictly a private matter for the receiver of the INIT chunk. The use of a MAC is mandatory to prevent denial-of-service attacks. There is a tradeoff between to computational complexity and the level of security the MAC provides. Using the HMAC-SHA1 might be an acceptable compromise. The secret key SHOULD be random ( provides = some information on randomness guidelines). The secret keys need to have an appropriate size. When using HMAC-SHA1, secret keys of at least 160 bits are appropriate = according to . The secret key SHOULD be changed reasonably frequently, and the = timestamp in the State Cookie MAY be used to determine which key is used to verify the = MAC. I use HMAC-SHA1 since this seems to be what is used in the FreeBSD and = Linux implementations. >=20 >>> The State Cookie MUST include information (e.g., a MAC or digital = signature) that the sender of the INIT ACK chunk can later use to = cryptographically authenticate the State Cookie. It MUST NOT cause the = size of the State Cookie to exceed X bytes in total, and it SHOULD = provide at least Y bits of security. For example, the State Cookie's = authenticity protection could use Z. >> Well, we are not that specific about size, especially regarding Y. We = only mention: >> An implementation SHOULD make the cookie as small as possible to = ensure interoperability. >=20 > Oops, I missed that. No need to add more about the State Cookie size = then, as far as I'm concerned. >=20 >> This is basically about trying that the packet containing the = INIT-ACK does not need to be fragmented >> at the IP layer. >> If you think, I can add a statement about the length of the key being = used in the operation. >=20 > I think telling people to use cryptography without giving any guidance = about what algorithms or parameters to use could potentially lead to = implementations accidentally picking insecure options. So I think it = would be nice to see some guidance there, even if it's non-normative. Done in the above text. Referring to HMAC-SHA1 in non-normative way. >=20 >>> I'm guessing Y =3D 128 is reasonable. For Z, I'm guessing = HMAC-SHA-256 with some specific key length (256 bits?) but like I said = above, I don't know enough about MAC algorithms to provide good guidance = here. Since I'm using HMAC-SHA1, I'm using a length of at least 160 bits. >> We actually left that open. Since you compute the cookie when = responding to an INIT chunk, it is also >> important that you don't spend too many cycles on generating it. How = you balance the level of >> protection against the cookie modification and protection against the = CPU load during an INIT flood >> depends on the system, the application, and is left open. >=20 > Oh that's a good point. Was that in the doc and I missed it? If not, = it might be nice to mention as guidance for implementors on how to pick = the right algorithm and parameters. Though I'd probably still lean = towards also including a reasonable example, for implementors to use by = default if they're unsure of what to pick. I mention it in the above cited text. >=20 >> The cookie mechanism is used on the server side to avoid keeping = state before the server >> has validated that it communicates with the IP address it is thinking = it communicates with. >> So I'm not too concerned about this. But I follow any advice you are = giving... >=20 > I'm not too concerned about it either :) I think some clarification = and an example (as discussed above) would be good, but I don't feel = strongly about any of the specifics. (Just maybe don't recommend = HMAC-MD5 truncated to 32 bits.) The text above talks about using HMAC-SHA1 and the text says to put the = MAC in the cookie. So no truncation.=20 Best regards Michael --Apple-Mail=_71478D1B-7A86-475A-A62D-5A9AC11FD86E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTEw MjMyMjQ2MzNaMC8GCSqGSIb3DQEJBDEiBCCeTJgLtSFHJx3pYmbkHJCDU81sx0YdkVP0f2EkBInR sjCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQELBQAEggEAbUrcUY+gIhgUUxBSNBPF7GFwNFpz W/PiNyLeY8mf0HFS7Cis53E+pN6NX4hHq/BBHYi30XsqCx3rXp7DBD99tKBjoWjghpVfoztLeZjF 2F3yZm4jV0LLnpnR9C7PeZMYfZAHYnLA0+REH7xdJWiUUKdC7B1Fv+9sDHygskiuJDZ1+6EX/od6 DVmwQX6AkQyrorJ+bCN0KNQz9424lSPkHPGMeuQ+X3tfO2Xnfc20QjcDHPpk1nrZUCcjMMfe/SZI uM9dCfgT5L4lSpa2jLNouebI+aliOz1dZKaDvFK6j3xAQy7GBNz132s8mxbMcLX5B9NJTYhgBb8E DrreGdbMmgAAAAAAAA== --Apple-Mail=_71478D1B-7A86-475A-A62D-5A9AC11FD86E-- From nobody Sun Oct 24 11:56:03 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAE13A08CD; Sun, 24 Oct 2021 11:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_SOFTFAIL=0.665] 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 lMFByea_IfaD; Sun, 24 Oct 2021 11:55:58 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5A33A08D7; Sun, 24 Oct 2021 11:55:56 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:dc3d:ff49:1741:d8c3]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id EC8BC721E2806; Sun, 24 Oct 2021 20:55:50 +0200 (CEST) From: tuexen@fh-muenster.de Message-Id: <87B43E4B-F93B-4ED7-9BFD-C501B093F9DB@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_E30CBC11-1170-4F4E-8EC2-20A2002AFCF0"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Sun, 24 Oct 2021 20:55:50 +0200 In-Reply-To: <24941.43160.312498.778487@fireball.acr.fi> Cc: David Mandelberg , iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org, secdir@ietf.org To: Tero Kivinen References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> <2bac74f5-e134-d50c-a640-4a87fdbc5790@mandelberg.org> <24941.43160.312498.778487@fireball.acr.fi> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2021 18:56:02 -0000 --Apple-Mail=_E30CBC11-1170-4F4E-8EC2-20A2002AFCF0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On 18. Oct 2021, at 19:02, Tero Kivinen wrote: > > David Mandelberg writes: >> I think telling people to use cryptography without giving any guidance >> about what algorithms or parameters to use could potentially lead to >> implementations accidentally picking insecure options. So I think it >> would be nice to see some guidance there, even if it's non-normative. > > I first assumed this cookie is similar than what for example IKEv2 > uses, i.e. generated and verified by one and reflected by the other > end to verify that the other end did see the previous message. > > When I checked the draft I noticed it is not at all similar than what > is used by IKEv2 or Photuris, because the Cookie contains both the > "minimal subset of information" and the MAC. > > To see how IKEv2 specifies this see section 2.6 of RFC7296 and the > description about the COOKIE notification, but here is relevant text > from there (note this example uses just simple hash with secret, which > is not that safe as a MAC, but should be enough for this kind of > purposes what IKEv2 does): > > ---------------------------------------------------------------------- > 2.6. IKE SA SPIs and Cookies > ... > An IKE implementation can implement its responder cookie generation > in such a way as to not require any saved state to recognize its > valid cookie when the second IKE_SA_INIT message arrives. The exact > algorithms and syntax used to generate cookies do not affect > interoperability and hence are not specified here. The following is > an example of how an endpoint could use cookies to implement limited > DoS protection. > > A good way to do this is to set the responder cookie to be: > > Cookie = | Hash(Ni | IPi | SPIi | ) > > where is a randomly generated secret known only to the > responder and periodically changed and | indicates concatenation. > should be changed whenever is > regenerated. The cookie can be recomputed when the IKE_SA_INIT > arrives the second time and compared to the cookie in the received > message. If it matches, the responder knows that the cookie was > generated since the last change to and that IPi must be the > same as the source address it saw the first time. Incorporating SPIi > into the calculation ensures that if multiple IKE SAs are being set > up in parallel they will all get different cookies (assuming the > initiator chooses unique SPIi's). Incorporating Ni in the hash > ensures that an attacker who sees only message 2 can't successfully > forge a message 3. Also, incorporating SPIi in the hash prevents an > attacker from fetching one cookie from the other end, and then > initiating many IKE_SA_INIT exchanges all with different initiator > SPIs (and perhaps port numbers) so that the responder thinks that > there are a lot of machines behind one NAT box that are all trying to > connect. > > If a new value for is chosen while there are connections in > the process of being initialized, an IKE_SA_INIT might be returned > with other than the current . The responder in > that case MAY reject the message by sending another response with a > new cookie or it MAY keep the old value of around for a > short time and accept cookies computed from either one. The > responder should not accept cookies indefinitely after is > changed, since that would defeat part of the DoS protection. The > responder should change the value of frequently, especially > if under attack. > > When one party receives an IKE_SA_INIT request containing a cookie > whose contents do not match the value expected, that party MUST > ignore the cookie and process the message as if no cookie had been > included; usually this means sending a response containing a new > cookie. The initiator should limit the number of cookie exchanges it > tries before giving up, possibly using exponential back-off. An > attacker can forge multiple cookie responses to the initiator's > IKE_SA_INIT message, and each of those forged cookie replies will > cause two packets to be sent: one packet from the initiator to the > responder (which will reject those cookies), and one response from > responder to initiator that includes the correct cookie. > > A note on terminology: the term "cookies" originates with Karn and > Simpson [PHOTURIS] in Photuris, an early proposal for key management > with IPsec, and it has persisted. The Internet Security Association > and Key Management Protocol (ISAKMP) [ISAKMP] fixed message header > includes two eight-octet fields called "cookies", and that syntax is > used by both IKEv1 and IKEv2, although in IKEv2 they are referred to > as the "IKE SPI" and there is a new separate field in a Notify > payload holding the cookie. > ---------------------------------------------------------------------- > > As in this draft cookie is not only a cookie, as it also needs to > include the data needed to reconstruct the state this puts much more > emphasis on the properties of the MAC. > > In IKEv2 cookie is simply a MAC of things that is already somewhere > else in the incoming packet (which are cryptographically proteced > later anyways). I.e., the cookie is just used to verify that initiator > has already done one round trip to the server before we create state > based on the data that is in the first packet. > > Now as the cookie here contains more than just MAC part, it makes > cookie to have more security issues. Now the cookie needs to have more > of internal structure and recipient needs to parse it properly. This > also means that if attacker is able to modify the cookie in such way > that it still passes the checks it might be able to mount more serious > attacks. In IKEv2 case that is not possible, as cookie is just HASH of > data elsewhere on the packet, thus there is no structure to mess up. > I.e., in IKEv2 it would be possible to use very short MAC, as even > with one octet MAC that will limit the resource consumption to 1/256th > of the non cookie case, but one octet MAC is not going to be good > enough to protect the subset of information needed to re-create the > TCB. In the FreeBSD implementation, we put the INIT and INIT ACK chunk in the cookie. And when parsing this information, we do it the same way as parsing any inout from the network. > > In addition to that your cookie generation might even leak out some > internal data from the server if implemnetor really creates a TCB and > then includes too much data from the TCB to cookie (i.e., if someone > just created TCB, didn't bother to create minimal subset of > information, but simply decided that TCB is small enough that it can > be used as such, and then TCB might include some pointers to other > structures that are internal to the kernel). The specification does not require the cookie to be encrypted. So the sender should not put any information in the cookie that can't be shared. In the FreeBSD case, most of the information was already on the wire... > > Because of this I do recommend using the proper cryptographic message > authentication code (MAC) and not a thing that IKEv2 and Photurus > used, i.e. simple hash with secret at the end (which would most likely > still be safe for this use, but proper MAC is better). Also you do > want to say something that the MAC part of that cookie, needs to have > certain length to protect against forgery attempts, you are not using > cookie to just protect against denial of service. The text I added to address Davids issue, refers to HMAC-SHA1. Is that acceptable? Best regards Michael > -- > kivinen@iki.fi --Apple-Mail=_E30CBC11-1170-4F4E-8EC2-20A2002AFCF0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTEw MjQxODU1NTBaMC8GCSqGSIb3DQEJBDEiBCBVW19WzhEWuZk454U81Z+mUYp0SfDjgBRghBB1Jh3x TjCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQELBQAEggEAn9etsyO6zM+/ZBvdqGhZJBMGKA5W R2uHIQ77SxScCws1t56Eh35pNiprNOhPDzpt2pecK26nMDBpICN8ZJ0Dm0qRTbG8hUDb6wt8ZL8f MLMtoF7pt+51b1opDwDq5YZpMtZuNyGsDXi16GatxR8V+b6erK9hhv/yDL9FskkAqhPefxqeW8IX loVaJMZxV1vfdx2IMWmSGF3qi6R7UZZbltbJymRGAUUMClE3ghsYakdOwlSYHvUk4VxyIOW3PmnM etOHs8/Hopt6wxsbh5POuvfy4iJ+bwZ1j2ZmzjS7EHmoXmI1hT3iVNmS1tP0w3rDOV0eGvBOIDuV Ch3Z3VpO5AAAAAAAAA== --Apple-Mail=_E30CBC11-1170-4F4E-8EC2-20A2002AFCF0-- From nobody Mon Oct 25 07:15:45 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3883A0E79; Mon, 25 Oct 2021 07:15:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault via Datatracker To: Cc: draft-ietf-idr-bgp-ext-com-registry.all@ietf.org, idr@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163517133207.31516.1654709006169226653@ietfa.amsl.com> Reply-To: Daniel Migault Date: Mon, 25 Oct 2021 07:15:32 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-idr-bgp-ext-com-registry-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 14:15:37 -0000 Reviewer: Daniel Migault Review result: Ready Hi, 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. The document is ready to me. I do have though a generic question I regularly ask to myself - regarding the reference to place. My current thinking is that there are usually more than one reference that would be useful to place. Typically, there is a reference that creates the code point in this case, 7153, 8955, 8955, some references are updating the registry (this document) and in some cases, some references are deprecating the usage of the code point - mostly for crypto. I do not think we have clear guidance on which reference to place. In my opinion more than one reference could be placed. I am wondering if there are any thoughts on this. Yours, Daniel From nobody Mon Oct 25 10:21:19 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23443A0CF6; Mon, 25 Oct 2021 10:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=nokia.onmicrosoft.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 K3nLgIGnjcru; Mon, 25 Oct 2021 10:20:57 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2120.outbound.protection.outlook.com [40.107.22.120]) (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 A5C7B3A0CD5; Mon, 25 Oct 2021 10:20:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=er6KSOsdJCXOYtcS7+cvwqjCJK+KmA7IlmxG8C/U+PD7L5cSAaz1g0dtZdfI5jpUq+FDo4vIQuc2jhKa8U077PPK+a54QwoUlP41aZIkzx4nDBakU6klDJ4g68SyH/iiayTdeY/JeBxIFAQ9sBe7icfAChfkyfLIwyyH1tCYeyi1a60Mt9a1uKRBGCbyLgO5sUbqDzhjuScFE+76mnfRcz+nTlpDyiH4puIyoRBoYSK9OcBO/mGGcz8TzbM7hQS4Gn80jrQWg5+EVys/U9thJGGaxWMx6Xao5dwadIoZZHTbHd3LPq4b3gsIQw0JIE47v4C1JMCz8N2jv6tIP4g4CA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=S96jKdMmPX7RITxWlk6VEZbEygSW4XxaCF1CnfJNzCw=; b=RAq5+gB2MiVYfzoQbHd80iQd5/bUzdkE8GijBjfwpPvBgiYuukYop5GqxJ/7GBBgYeO5MyI7nCh9xwzwlW0aonLyj74+Q4KAU7CUSUCS8DTq6aSxG+cy5T+NABwSIQhckYA3T15zI9p5n6cUm+3fkDPAX0zSMcRbTSwpNWb14+KFz4byMn2aMIXj1G1YNx0WbnmIg5PzGlLZok9jWl2MRNvry16lW5NxFNUK5zRnA2qAiL3BrQUqSt6g732hljTu/X6xQYGIeP44q3G3Y3m0yuEq/3pkyBVbXNPf7DPG6+Y49kAAOC0c3BNXRjwal813nF4Tnmx2DwIgZlmYdKnQ6Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S96jKdMmPX7RITxWlk6VEZbEygSW4XxaCF1CnfJNzCw=; b=OMzUNDotYz2b0A0bJ96uICTBp8VMh3la9rpvJAW3hhHq3IjJjSBNGKKvItUgKPyI6zclBr6dscuMKrEcLotI2fMkavDlDXSNmgbT2DVj4pUM78fX8PkYWyq/cvBMa7Ar+AuBXkt93I4A/laWhM+HVA1HTO5wUbgo4/KuiDHiGN8= Received: from PR3PR07MB7018.eurprd07.prod.outlook.com (2603:10a6:102:7d::13) by PR1PR07MB5034.eurprd07.prod.outlook.com (2603:10a6:102:9::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.13; Mon, 25 Oct 2021 17:20:49 +0000 Received: from PR3PR07MB7018.eurprd07.prod.outlook.com ([fe80::905b:f94d:2807:c70]) by PR3PR07MB7018.eurprd07.prod.outlook.com ([fe80::905b:f94d:2807:c70%8]) with mapi id 15.20.4649.013; Mon, 25 Oct 2021 17:20:49 +0000 From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" To: "alto@ietf.org" CC: Martin Duke , "drafts-lastcall@iana.org" , "ops-dir@ietf.org" , "art@ietf.org" , "secdir@ietf.org" Thread-Topic: [alto] I-D Action: draft-ietf-alto-unified-props-new-19.txt Thread-Index: AQHXycIzbWUv6KOcwki+MUcKKtxjwavj8abA Date: Mon, 25 Oct 2021 17:20:49 +0000 Message-ID: References: <163518138730.21825.2677496007464598428@ietfa.amsl.com> In-Reply-To: <163518138730.21825.2677496007464598428@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia-bell-labs.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 933621c9-7620-4144-b0b7-08d997dbca2c x-ms-traffictypediagnostic: PR1PR07MB5034: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 20BdgLTs5ANQN5T9lxPqvIGP9tP514d5M2wTQu79Ev1SOI2ALXrc8dFuZV7uhq0IrQ0dq6jlBJNgrb2snXICRkffep0nMwpzbjXmbrobTrxPbAypU1jSjQiKeEIKlb+xsZ6jV1O/QaAN5pkZE3SxLd/38FYETVMrSgwWpr/eZHCPvzLtlYaelgw2P2l6E40BphIzHNdHZrOBzcrHivc0BDggB2PMsc1XxgkdU1U504PBb9MtqvY7DpE0LdwzuNtoHH2ZiyQIxu7BG0tILTCBM1NsASRqN48smLZPph9Jb/rmtIkZ2G5F/37JOwZt1x5ltgPzbmTW4wLk208dNuGTmjhULJR0QZZV7dWMDLyht/DIQo/k8ogB0pJSOPaNjsZpaKYB4RK8fK7m1Q2DoLCMPfUE008UpILdLHYzI5+Fiz8zgyS9JckNq3WSqsBTn0UYQkR2t7gXGhiO2ucMAfWVA04a9KhZ7W1fV3z4E4LjVImHY+H/O7iXfc/nNwsS87T7F+HcTh3kuAoJD7QhlAMb3yvZqsE9urBaEj/HBt1OO0DRvabskGpWqcbPzlSJyVGmxIo/HiO3PJ7uUuxCe4Dk70FAGXs0HaWuIKRS1TdmmPszwMrH0bcHaGxUjeIcw0dapHYlcLQFyDjrU3fmDCoMe/rnhmNXpTIQbSnJvR/I/7mHnoW6sWJhDJJWeWx9+kBvt/YVhPVRjzTsOPRqM85zhKPQYd5Qh97CIoYNNMpNbqOHo+HkS0QGTJfBjEQFEAqjHzNUyoCcSbBg81ujejJMJm4U3Zklr0/yfBAcLgtfrxfR1ZX5iIHkN4WtRUbCam3k0qMDcGo9VaRenw12VSdvQA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3PR07MB7018.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(316002)(8936002)(83380400001)(33656002)(66556008)(122000001)(66476007)(71200400001)(55016002)(186003)(52536014)(76116006)(4326008)(38100700002)(82960400001)(86362001)(66946007)(66446008)(64756008)(6506007)(7696005)(66574015)(9686003)(4001150100001)(2906002)(38070700005)(5660300002)(8676002)(54906003)(6916009)(508600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Nc/1Nc+MpU2S15++TjDvE8l6QO1aFv2OUakBOHREed5ozxVU5hwyQdj8iYqd?= =?us-ascii?Q?K5DQ3n/jQDbdV260YvFC67/CqH5261nn88gEFLiOWs70/b2Qiewoy8ktNWT5?= =?us-ascii?Q?srlBoq1XKHBoPc856qUuOIV2uZF+LTX/uRTtV67CMQAZNwXszH4SEGHMUxZ7?= =?us-ascii?Q?25d4GYn/eu61WZnc+kdQj3CioC+E74qvrAWuMGYo9qkgGMaJwzjCoqeHdCPG?= =?us-ascii?Q?q7SmKmkBUQSQ8BlLUaqRrck9d5Ck9idJpsr4xPvxJJ41jorxsCzo1PHBpJdW?= =?us-ascii?Q?JprO3gbd2TkQ8Y8W3l1u1/LmAUhxCJIxQ1vOBOhoCp9AtBLVRxcZZoIOJYxe?= =?us-ascii?Q?qawEu4DX42ychKMkJTuaf51PXf7GCdxl3TFP0N5VxaRYqBfYbw+BhLwFTA3k?= =?us-ascii?Q?yk+IDH40z+L20SU0u/3nYBhpjCYNsI+etceokvXsL02eurzSnAbel10MTcZs?= =?us-ascii?Q?4p4CVLQ+9MwCx8zT5xsR1XP2WEPY18oHlxLMGdH3GkBsRlFbvkjT3nMBWm4k?= =?us-ascii?Q?AfFSCjDfQQBzH1tRYtZh92mTJmjSyRFLpKaR5AmGu0pdPMQfkuUdf0WFrS1X?= =?us-ascii?Q?2QMtZylv8NaKIb4971leu2skxi5STelx/U073zHXtUW7Rfmb6qCwc96VpMGs?= =?us-ascii?Q?+atrxqp7+mlgxnCNkt1Wi5TPzAlJPsPqELbDNKPhnvviqR8/9vSHuuLVAW8Y?= =?us-ascii?Q?xf4ktAOgYvS6fqyv2JT/vbGIh6V6vV4r09cIpGOt46cbB/M73U2j91TRZ0sy?= =?us-ascii?Q?WpzsIe6V/SdFQwAMvKdC6g0kph3NuwvhaQDB+a/tJHz0pFzbCCax8ZCHO4IC?= =?us-ascii?Q?DFKdIuu80SojBHGNxQIenv+NpguOivQURiQ5xcDbgtFZ3eZ6wlRUxmEOnup0?= =?us-ascii?Q?M9OC2DVmlUXB319Mnuj3cU5cgQCa5e03WxZgBuO9rzJSPlyNQkp5KLUx43ZA?= =?us-ascii?Q?k172GlAE+lQVsbZ/kTnmY0l0ewUOf2hHmDa6ide1H5EEdIE7yREnIXGiTbjK?= =?us-ascii?Q?p018sYlehurZQdRkQLd6duO4svaOYjpPPTaI+ef+eoIuQIjcQ+n+kQ1Ci6mN?= =?us-ascii?Q?azDTu2fTZ7d2cwsbvfB0ObBZ8C0HTYtfbrKOherto2XOTTzY9mxQZlpRxyRV?= =?us-ascii?Q?qW4pAHP8sQc/EcEOo1jpnSFNuoxXz7IEO3Rv8ECz29o7wyhZlk5zWKEonIYp?= =?us-ascii?Q?KnA7IpBJZXbvZb40O2s4B41lqxBql8yfKvra98iw4OF57oaUKaUvACJ+7u/s?= =?us-ascii?Q?XdMU15GrmuvUoXsehLk+ABzJ59Etqk4vidphGGtoRTlyNHYbbGyWIYZ9kFdh?= =?us-ascii?Q?d6Rbhqde5RukZ9IgsQzpIaxiFn9DtGxZQK84dE6Ri15WDoke/ERoUWEyHODc?= =?us-ascii?Q?6CW9Udpq4rx6R9xekiULAMgnkQyAN/KwwL5fKqTWTNfAcpbQszifbYSApZtU?= =?us-ascii?Q?EwX+erMDp2kB3NCZhNnOFK2N1KzyqDjdusq4sIyaIhwsES7EhHit6kKtcJH6?= =?us-ascii?Q?WcXiYvS6pgMhSlKuYn3Ai+xBQ+4KXw1INdC7TAtyK6jFCdowWsJbxpNyn8ik?= =?us-ascii?Q?hzPPrMogsJne4FoAu1kpRPZp1X/A8n9rVRTUrdDag8iPwyyQLycSpHWRNxTS?= =?us-ascii?Q?FSqp4paS7JbghvcVhQPrPFAyZtK096ExUL5lSBBYQ/mHk6sQ/sbTrXqRHTXJ?= =?us-ascii?Q?FOMOl81+/K0WaqNqHvey1AYV1YvVDLoReSeD1F7wCBNXPg5wazNOptZHNjOK?= =?us-ascii?Q?dm+v3mDsP8/6ft5PO/y7ZWzAAxmvozga99OvD5vRrVUMCgCz0uDK?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PR3PR07MB7018.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 933621c9-7620-4144-b0b7-08d997dbca2c X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2021 17:20:49.4606 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2+BasEayfzOY4gdAbDi+zO/hYE2pNnDqdP9cBnqL955UDVrIYf9IrTOBwQt61yT5TmKYDPnBoTccQB72VUOUm12OTt7e0JieRrslDs9QVduwuSPU14bFScEzZrGQ06Qo X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB5034 Archived-At: Subject: Re: [secdir] [alto] I-D Action: draft-ietf-alto-unified-props-new-19.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 17:21:02 -0000 Dear ALTO WG, The version below addresses the reviews received from our AD Martin Duke, t= he IANA with Sabrina Tanamal, the OPSDIR Scott Bradner, the ARTDIR Spencer = Dawkins and the SECDIR Paul Wouters.=20 Great thanks to all of you for your review, insight and valuable guidance. = This v19 It has been edited upon your feedback to our proposed updates. We = hope all the issues have been solved.=20 Until the submission deadline, I will: - Detail to Spencer and Mike Bishop how their comments have been addressed, - look-up occurrences of "domain name" where "entity" should be inserted, - wait for your further feedback.=20 Thanks, Sabine >-----Original Message----- >From: alto On Behalf Of internet-drafts@ietf.org >Sent: Monday, October 25, 2021 7:03 PM >To: i-d-announce@ietf.org >Cc: alto@ietf.org >Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-19.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. >This draft is a work item of the Application-Layer Traffic Optimization WG= of >the IETF. > > Title : ALTO Extension: Entity Property Maps > Authors : Wendy Roome > Sabine Randriamasy > Y. Richard Yang > Jingxuan Jensen Zhang > Kai Gao > Filename : draft-ietf-alto-unified-props-new-19.txt > Pages : 61 > Date : 2021-10-25 > >Abstract: > This document specifies an extension to the base Application-Layer > Traffic Optimization (ALTO) Protocol that generalizes the concept of > "endpoint properties", which were so far tied to IP addresses, to > entities defined by a wide set of objects. Further, these properties > are presented as maps, similar to the network and cost maps in the > base ALTO protocol. While supporting the endpoints and related > endpoint property service defined in RFC7285, the protocol is > extended in two major directions. First, from endpoints restricted > to IP addresses to entities covering a wider and extensible set of > objects; second, from properties on specific endpoints to entire > entity property maps. These extensions introduce additional features > allowing entities and property values to be specific to a given > information resource. This is made possible by a generic and > flexible design of entity and property types. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ > >There is also an htmlized version available at: >https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-19 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-alto-unified-props-new-19 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > > >_______________________________________________ >alto mailing list >alto@ietf.org >https://www.ietf.org/mailman/listinfo/alto From nobody Mon Oct 25 17:23:28 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D7F3A0DF6; Mon, 25 Oct 2021 17:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=nokia.onmicrosoft.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 OmXOC_ik7hg0; Mon, 25 Oct 2021 17:23:07 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40136.outbound.protection.outlook.com [40.107.4.136]) (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 4E3C13A0DF1; Mon, 25 Oct 2021 17:23:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GpeGfAF7Gt7L7tYBO2PW6gXHpgzz5P2jlm3LmF5gcXzPL7+omfTU4khSUhJTtgH949mYgUoXvITn++wdzwUwYqiVabHjGDLo3LeGxFHiCaGrJXKy9krSc24miBSsBtgnuiWofnGiKsut5c/gOag25xiasjJ9Ndx9MAbbOpOpn5johnw9JvxSnSgZ0UIBY7jJ7gwBeDbFMLeIe3Yb3NbnfsDihqpMK3XziY/+gA0RY1jHonp6CAV+lSlcL2fUFPJufk+lNAHIO/ry67JsbkAiUTZ4GMtogxCiCMGiLlYmL8VXgalO89raWhPfx/3r+vbS4COI177NkuHXudLt6+/v6Q== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VLyWk3wjBE0e6u2NU69zvHqBLnC0m61c/H5+GCEpvpE=; b=JbmOsiNybQk6qUQZEXL9OS6bt9s8gtgMr1ZPtihQW61Yife6TkNEGbgn/hyquOppflBy7L0+a9Ri73ycsKreB7ZZgH+p6RxffoPAPtl5EVetI+dWoCVprJB5e16M8AWqpLPpUOuLCxtlZ/QjkSFQsHnagYKkKYbdIlg3PICyyuu1+MJRGMsYKhDi+dUEwOd1+jr8gyxSKCjVo/1tlRV+zZsbKmhmSZvfAAcAsIwBS/hFhq/xt2Fk0IRi+hWFfEABTuC0EmlpByxrryS2RTw6OgByLrRtywQjXW9MZ6W1IB3ipz9GcYbmC7IFaJvIl3xBob8UXvbxW1U24V1G1XDzFg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VLyWk3wjBE0e6u2NU69zvHqBLnC0m61c/H5+GCEpvpE=; b=TpjCEhHJ477N/I2+t1CllPCRloXArO2jfG2l3CTmTyhaFn0w+m/LcoCb7yUbjNQdAZ6xAPZsuoBEEnVCUZwOsVbDmTC/XpuJYBM1UddBH3GL0k9zod84v/dGdPhZhCmasOvgv6HZ8X0d74XYC6d1PlIRDlIyUa7qdz+2vjf5ado= Received: from PR3PR07MB7018.eurprd07.prod.outlook.com (2603:10a6:102:7d::13) by PR3PR07MB6633.eurprd07.prod.outlook.com (2603:10a6:102:6c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.8; Tue, 26 Oct 2021 00:23:03 +0000 Received: from PR3PR07MB7018.eurprd07.prod.outlook.com ([fe80::905b:f94d:2807:c70]) by PR3PR07MB7018.eurprd07.prod.outlook.com ([fe80::905b:f94d:2807:c70%8]) with mapi id 15.20.4649.013; Tue, 26 Oct 2021 00:23:03 +0000 From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" To: IETF ALTO , Martin Duke , "art@ietf.org" , "ops-dir@ietf.org" , "secdir@ietf.org" Thread-Topic: [alto] I-D Action: draft-ietf-alto-unified-props-new-20.txt Thread-Index: AQHXyfsKHbAFrVTpckaV0N8+TlbyH6vkZkAw Date: Tue, 26 Oct 2021 00:23:03 +0000 Message-ID: References: <163520574432.32728.7180217253406867548@ietfa.amsl.com> In-Reply-To: <163520574432.32728.7180217253406867548@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia-bell-labs.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 043178a1-9a6f-4dcf-f513-08d99816c64f x-ms-traffictypediagnostic: PR3PR07MB6633: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wp18AcOOYyYSOk1D1V0mmhm4CZ0yUhZRhef/mB4J6H1wRugAdJFjJilST/kZqOzOIDVsvuJj/+XjeXR+r9AkxiRfMhItTkmLvkk859niQxWI0M6PdF26ZdodWqv09P1jAq4IvTjLFSIQgsR1IqL/GSspSwzEhZFe9dm4b44ScFS1H7UXHb8h1Cgnu4wu9yOv+Yw0nzChLDfSi9ARL0IprWT+kUxls8QCbDycIyvd49Ov3BkXhK2gYnTLcWSeo5Ax4ReizRTWrfvzoMUcyl7abgQHeHsUjY2KGZyHH+2krIVfux+NGh9LfDwv5bFB6g4gtPt17HfaF4OEUaeKUULfCRyd6zEGWT4J0u+WDBytVkx23oaDp3F8yOzVPWs24okfBcSTKhmtwn9PnOYP/d1pIvAmp71b9sJLZQtpGHq3RhIE2MgLSxbzEBx3mJoeqW6IDwWHnSHK+qg9KRPNGEAiRJ0pjpXV5vDyZLGg5TSNOIBzh+4LHC5QnXVC2zVDSEWPOsZLOmexm1sa7+5NVr06r6fGh580X/DAPpKQvy+TvJEFdgGUgttd9OKkvWM2NCyooRkuPEA0srkR0urSiCpEZeQFcv1lI2lxDC7FR4OOOQaqJnSiwUp2hTiY6kgI6/6IPAZyvf0ryBbHcyOFtEDDBzG6PgJ3uTUpWJutuBqc2SfLK3+HHZTZdNaYuhSuS5TB4QyGU4VpwX8s0BR85w60HPELUIt7ngqvDdG1nQIY2iCQ+e62VRkOFAEYLhvIQ3aeGm9u6hvP5J7u28CUM3ZU4A2z/b0+/Nxs1FoPb8FPwe3YQP4wngAjrwT81S7LhKZU x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3PR07MB7018.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(76116006)(5660300002)(316002)(33656002)(66946007)(83380400001)(52536014)(86362001)(66476007)(64756008)(2906002)(66446008)(186003)(110136005)(6506007)(53546011)(7696005)(66556008)(38100700002)(82960400001)(55016002)(122000001)(8936002)(8676002)(66574015)(38070700005)(9686003)(508600001)(4001150100001)(966005)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 2 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?EPcNQ+MDG1KMPpPCQ1VKa8E10ViMUl+lpXO07EDHDWwDBBBs755lWHCK9mzF?= =?us-ascii?Q?paCuTzfM68t1mTrkleysvQg64PmsgfcwS+mSn5CB24c/6eHRdxeg/osfMDx+?= =?us-ascii?Q?KfQCvhbQEcsoS1Yc1G/NeozzqGC5egFQdR0OO6kj243Di9XxlnmEdKVENuiU?= =?us-ascii?Q?FoW7LaUzABCf+mZOuZ7sLKLYqq5+4Qlh5k/le76SFA+Qe+IyzKv2bgJJSZMJ?= =?us-ascii?Q?7Qcc0pnlMfhlhbdM0N72sCkBhotLAY7cwKv2mo/geUTkPvth1QqaCfzmdN10?= =?us-ascii?Q?aTje/6UkGyC7E4f0QE8+iwCp5MfmB3fEP8yIUW1NKIiW1D+zSbS19kk3pAWn?= =?us-ascii?Q?qUCeHSJyuw6kWFu4K8aMPyInLW4g1kexvL9fT1jMqT9vJc09xE7zUKO/UF8v?= =?us-ascii?Q?RIatroqokXpi3apijiGW8d9eZBt1Z0Rc5f46selWzMy5Hbez2IstKvUP1w+1?= =?us-ascii?Q?JDvz4KGF7TLWGSwBKvXT7IIHMtvO1CNTc4glM21XwBkPlW4ToPP/YfgOH/Ev?= =?us-ascii?Q?AOGTgBEGwSiuFRX30NS/wsT+uZetCA371BRag7DzoaNd+1we3MxO/oK6yqtd?= =?us-ascii?Q?hWfmHu+e0y0fb+CIBFNQTW5NNrgkbA3ziCFOwL/rP7imT7spRpPrB8Ap+NC0?= =?us-ascii?Q?vijEuzQU60T4XIEJE5k8nTbRwbOk8823DBukfPbiRyk0vRSl4AFEk7Tc7USl?= =?us-ascii?Q?PLO9IQtdan1KVw7SsJx3pc/YkioaiDd0VtgQqTELras77uUSmO6zyfIskbpb?= =?us-ascii?Q?DKpd/Lnq1a73C4sp7gzVBHYJ9UExj161N+wgx8yB55QHJVo+0LkMrF6XjhMC?= =?us-ascii?Q?K8lI8IHla6KSB8SXgMGIdsQuKzQvu70kjRIyj/fiXkT/6lsT9HGbWVTTToxu?= =?us-ascii?Q?fNAAVC/UXXESXqqecJFIQiCTIu+ancE9XjKGRqvlkuKqEEhg5qst5W0YPgfF?= =?us-ascii?Q?0g5AqYNDDBDuFpYElT5X8QYXvFexD8VcG3gTgXm8Qf8PcaLmva/kGSvgzErQ?= =?us-ascii?Q?yOraXAwOgIgSlsipCVnYuj77UjoWT1yltUJYpmvca7rFxlD6GLuU3i2OUmxv?= =?us-ascii?Q?LMNJFb7yytqeQ/AWqd9SqJhImzjo1QVWAmdSQ5dITlINlThz28tTD/nEYCUN?= =?us-ascii?Q?CDixJsXhsYkBTIk3uT35Rlzd1h/2xY9vAV9T74Wat1hEBEtt2Rhe8Q97l/ZU?= =?us-ascii?Q?dm9/B3/jNqhr+RgWM2HhdZzvZbaRKAkVZmRB7j9Abklq08l+7LgsDC2m00ls?= =?us-ascii?Q?qsAraJvuPXrBanieT4JMnIkQZKUe1RArd8quV8iNqxFky8H7ClnsT1KwG6hT?= =?us-ascii?Q?sXWIfouGHPYsKddgDNFebioc+vhfvr2Dq/k4qwD+f8SY3Xp0rt0meVsQGYXo?= =?us-ascii?Q?KvZiq+rn6iPkRBY+zRsst3oWLWikWuKLzt6VVQW1oGK164uBomUoqO1DADtt?= =?us-ascii?Q?yLeCq476wSbIKN7ZwL/6NcXHtraE/0mn8VeRFHasAI1F/DlgQztES5V48pFQ?= =?us-ascii?Q?CaIyCTzPSzbLx8Ec1wxNZk+bSFyZKfYwD0qLYkjKGU27d9NBTlsuENT60UIH?= =?us-ascii?Q?9wHBBcIJ+WxWJ1cMO5iRqGgdk21nHBatvjJXaVyfIFUasrQuUBnrbq5nnYKn?= =?us-ascii?Q?xJx4T9yfhTySOkZSABflrQ9KoibM2Ny8C6/W3ht6ahfnhwK0ZwJ6fna1VRzA?= =?us-ascii?Q?BUurteEoRB3OtnfoSE8843vbqp1FKH92wd49PbVc/r1DpXcDpCbD/OK9NA8N?= =?us-ascii?Q?OubXXoBdbqKzkwXnq/Fbyj2aL+If80J8RYqgFl0PJHw6wTyYvL63G/IOP2aY?= x-ms-exchange-antispam-messagedata-1: GZAPnyYCV3r2/g== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PR3PR07MB7018.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 043178a1-9a6f-4dcf-f513-08d99816c64f X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2021 00:23:03.2680 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: K8V635uAnnkHMSs9E9FLd6GXQq5TK9i8aR1bD7CXzMq+CD58ZTrYeQXMyXWNEe1apwtBjsENSgtODXJ+dxPokd7aMPN5YNBxyYUwd2xIYJxCTs5dftc84cdXruDF2FGA X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR07MB6633 Archived-At: Subject: [secdir] FW: [alto] I-D Action: draft-ietf-alto-unified-props-new-20.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 00:23:12 -0000 Dear ALTO WG and reviewers, This new version 20 fixes some typos in version 19, among which many may ap= pear as errors.=20 In particular, I had an issue with the markups and many "" disapp= eared.=20 I also removed the "" from the EntityDomainName (5.1.2) and EntityPropertyN= ame formats (5.2.2) To see the significant diffs with the previous version, please diff=20 https://www.ietf.org/archive/id/draft-ietf-alto-unified-props-new-18.txt and=20 https://www.ietf.org/archive/id/draft-ietf-alto-unified-props-new-20.txt=20 If you have already started reviewing version 19, please accept my apologie= s. Thanks, Sabine -----Original Message----- From: alto On Behalf Of internet-drafts@ietf.org Sent: Tuesday, October 26, 2021 1:49 AM To: i-d-announce@ietf.org Cc: alto@ietf.org Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-20.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application-Layer Traffic Optimization WG = of the IETF. Title : ALTO Extension: Entity Property Maps Authors : Wendy Roome Sabine Randriamasy Y. Richard Yang Jingxuan Jensen Zhang Kai Gao Filename : draft-ietf-alto-unified-props-new-20.txt Pages : 61 Date : 2021-10-25 Abstract: This document specifies an extension to the base Application-Layer Traffic Optimization (ALTO) Protocol that generalizes the concept of "endpoint properties", which were so far tied to IP addresses, to entities defined by a wide set of objects. Further, these properties are presented as maps, similar to the network and cost maps in the base ALTO protocol. While supporting the endpoints and related endpoint property service defined in RFC7285, the protocol is extended in two major directions. First, from endpoints restricted to IP addresses to entities covering a wider and extensible set of objects; second, from properties on specific endpoints to entire entity property maps. These extensions introduce additional features allowing entities and property values to be specific to a given information resource. This is made possible by a generic and flexible design of entity and property types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-alto-unified-props-new-20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto From nobody Tue Oct 26 03:26:25 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2D33A0DCE; Tue, 26 Oct 2021 03:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (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 4o2qas3FWd5h; Tue, 26 Oct 2021 03:26:19 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 049623A0DC4; Tue, 26 Oct 2021 03:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1635243977; d=isode.com; s=june2016; i=@isode.com; bh=bt+GZYhlc5HIS0phwdjza0fIL9jH6Vf4ESEx7xSn6b0=; 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=UuRlJuSsikaDQGgqB5r+28DGmKLCupEaH/zTL3/3gredF7e4CJLboeYksL3qljRBCIZsJf L9Y7xlYYKnb2q7BeGx+sW25EtqsvA0QQHVztkUm0J++rEltpktmmySGnEvbYKgw8z8Yiid Iz0lpEah6jR5sHTcWIARRkF2kVLB2Wk=; Received: from [192.168.1.222] (host5-81-100-13.range5-81.btcentralplus.com [5.81.100.13]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 26 Oct 2021 11:26:17 +0100 From: Alexey Melnikov To: secdir@ietf.org Cc: last-call@ietf.org, draft-ietf-opsawg-ntf.all@ietf.org Message-ID: Date: Tue, 26 Oct 2021 11:26:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-opsawg-ntf-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 10:26:24 -0000 Reviewer: Alexey Melnikov Review result: Ready Hi, 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. Network telemetry is a technology for gaining network insight and facilitating efficient and automated network management. This document defines network telemetry as an extension of Operations, Administration, and Management (OAM) techniques. This document clarifies the terminologies and classifies the modules and components of a network telemetry system from different perspectives, in particilar whether they operate at the control plane, the management plane or the forwarding plane. Examples of both IETF and non IETF technologies are given. The document is well written and has a good Security Considerations section. As this document is describing a framework, the security considerations stay generic, but the Security Considerations covers everything I can think of in regards to data confidentiality, privacy, access control, etc. Nits: JSON and XML should have informative references. Best Regards, Alexey From nobody Tue Oct 26 07:57:46 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AD93A125D for ; Tue, 26 Oct 2021 07:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 6ui5mwdPQv3r for ; Tue, 26 Oct 2021 07:57:40 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 563963A1485 for ; Tue, 26 Oct 2021 07:57:25 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id s4so5445900uaq.0 for ; Tue, 26 Oct 2021 07:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EQl82wFE2zycDPyruIMKEFMEIi8oNU007ppZqkvvUPs=; b=E3nRX4JWoRU3GnEQN/tf7axK75VgRZa6DdBZgtCHgbU6JESC9B55OJD4yPEJ4Lzpa9 UCFgQbFDvUzT4DPZETjQwMBnSEGCqzh2Ng8WAskVGDl8IstA/UWp17N2ZrfVMwGQE5Xj ZF4NRTL0VGTmERe237VKeVyMkKPFeOpPux5o1G1BEDoQl3UXZn1biXerxqHQE086GgH1 JQ521w1aY/dnRR6QGY/wBrmT+v3qz5+8uP0Gsp2Hq3X3IL52VsesLlmhBk4xT2pjva3S 8swar4dt8yNOJK7RC+mkNaAHGoMohUeDKC+D0UBgttDKuzeAV/89KhZB3mPekucLl1s7 7Lyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EQl82wFE2zycDPyruIMKEFMEIi8oNU007ppZqkvvUPs=; b=p0b+hUYG0cvNQOc7JFUC+zqDxI0RNRkbMypWTJi9bpIpfLy2bXtsI76Vn8tO4bDP3/ 3WXMVHS31sPAXrQzrACtshmUx1jLExnQ/HDByClNbRmrIgdG47ctc5DfrWWRIeDCWuGg 9Jbt7HeN7dFEzxQtFLW6EZgXZO0JQDxQQzQB0DZwa6Hd6cqhpvIEly76E+A8YaEoFU+D yOqmL0c9YUz6hHxUfV3Sy7trEWpTAHUvXS7Fzj8S93fgmCoZIsRM+QeS91ko7apL8EXH bxIIZHABnKcL4BoXtBH1guV5Lr39LtIfFuzpODu5d1/LZMissJCCSCJtGprlVJNgb6/h AubA== X-Gm-Message-State: AOAM531oXakapJYuauEaHIb9Y/ZMgB5XlGddw3c4I+ELMtZdmIvbXR3H xUZJ1xTMUDgwH37oyY7EiAaC9O4a6tH88ERc7hR3+w== X-Google-Smtp-Source: ABdhPJwiDxXpdTsjLtrelVRPErRQnHCcoktRBpG4JfDaK0o+mm3LHu+QxAimSveji9vkV9Wdkdy6dFlxSLDlp7/iC0Y= X-Received: by 2002:ab0:5928:: with SMTP id n37mr23398579uad.15.1635260242182; Tue, 26 Oct 2021 07:57:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Tue, 26 Oct 2021 10:57:11 -0400 Message-ID: To: Alexey Melnikov Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-opsawg-ntf.all@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000e0641005cf42b140" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-opsawg-ntf-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 14:57:45 -0000 --000000000000e0641005cf42b140 Content-Type: multipart/alternative; boundary="000000000000da744705cf42b11b" --000000000000da744705cf42b11b Content-Type: text/plain; charset="UTF-8" On Tue, Oct 26, 2021 at 6:26 AM Alexey Melnikov wrote: ... > the Security Considerations covers > everything I can think of in regards to data confidentiality, privacy, > access control, etc. > I disagree on this point. The draft mentions privacy in exactly two places. First, in Background: > It is easy to see that network operations can benefit from > network big data to gather insights into flows without breaching > privacy. This statement is presented without justification. I disagree. If anything, it is hard to see how network operations can collect "big data" _without_ breaching privacy. The techniques described in this draft are technically identical to the Pervasive Monitoring attack documented in RFC 7258. Second, in the Security Considerations: > In addition to security, privacy is also an important issue. Network > telemetry means to improve the network operation which can ultimately > benefit end user's quality of experience. The network operators must > be held accountable and strive for a balance between managing the > network and maintaining the user privacy of that network. I don't think the IETF should be publishing drafts that recommend compromising user privacy, and I find the qualifications here vague and toothless. Although I view these as serious concerns, I think they can be remedied quite easily. It seems clear to me that the focus of this draft is on "technical" networks whose endpoints do not represent users. When all endpoints on the network represent a single administrative entity, user privacy concerns are largely inapplicable. To that end, I would replace these two paragraphs with: > When a network's endpoints do not represent individual users (e.g. in industrial, datacenter, and infrastructure contexts), network operations can often benefit from large-scale data collection without breaching user privacy. and > Large-scale network data collection is a major threat to user privacy [RFC7258]. The Network Telemetry Framework is not applicable to networks whose endpoints represent individual users, such as general-purpose access networks. Any collection or retention of data in those networks must be tightly limited to protect user privacy. --000000000000da744705cf42b11b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Tue, Oct 26, 2021 at 6:26 AM Alexey Melnik= ov <alexe= y.melnikov@isode.com> wrote:
    ...
    =C2=A0th= e Security Considerations covers
    everything I can think of in regards to data confidentiality, privacy,
    access control, etc.

    I disagree on this= point.

    The draft mentions privacy in exactly two = places.

    First, in Background:

    =
    >=C2=A0 =C2=A0It is easy to see that network operations can benefit= from
    >=C2=A0 =C2=A0network big data to gather insights into flows = without breaching
    >=C2=A0 =C2=A0privacy.

    This = statement is presented without justification.=C2=A0 I disagree.=C2=A0 If an= ything, it is hard to see how network operations can collect "big data= " _without_ breaching privacy.=C2=A0 The techniques described in this = draft are technically identical to the Pervasive Monitoring attack document= ed in RFC 7258.=C2=A0
    =C2=A0
    Second, in the Security Co= nsiderations:

    >=C2=A0 =C2=A0In addition to secu= rity, privacy is also an important issue.=C2=A0 Network
    >=C2=A0 =C2= =A0telemetry means to improve the network operation which can ultimately>=C2=A0 =C2=A0benefit end user's quality of experience.=C2=A0 The n= etwork operators must
    >=C2=A0 =C2=A0be held accountable and strive fo= r a balance between managing the
    >=C2=A0 =C2=A0network and maintainin= g the user privacy of that network.

    I don'= t think the IETF should be publishing drafts that recommend compromising us= er privacy, and I find the qualifications here vague and toothless.

    Although I view these as serious concerns, I think they c= an be remedied quite easily.=C2=A0 It seems clear to me that the focus of t= his draft is on "technical" networks whose endpoints do not repre= sent users.=C2=A0 When all endpoints on the network represent a single admi= nistrative entity, user privacy concerns are largely inapplicable.=C2=A0 To= that end, I would replace these two paragraphs with:

    <= div>> When a network's endpoints do not represent individual users (= e.g. in industrial, datacenter, and infrastructure contexts), network opera= tions can often benefit from large-scale data collection without breaching = user privacy.

    and

    > La= rge-scale network data collection is a major threat to user privacy [RFC725= 8].=C2=A0 The Network Telemetry Framework is not applicable to networks who= se endpoints represent individual users, such as general-purpose access net= works.=C2=A0 Any collection or retention of data in those networks must be = tightly limited to protect user privacy.
    • --000000000000da744705cf42b11b-- --000000000000e0641005cf42b140 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPmAYJKoZIhvcNAQcCoIIPiTCCD4UCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggzyMIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBNEwggO5oAMCAQICEAEPeo9/GxknaxVybmbU vmIwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMTEwMTgx MzI4MjFaFw0yMjA0MTYxMzI4MjFaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFzY0Bnb29nbGUuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0Og2McfM9XYxay9lQdacWd75OScDFx75 QNs68foESjDzjCyh2pg+v1chyqSuCIt/79bjwTJTFmaXKLgdbd51VD6v1gPRkO8YVHJ/YqXBSF1o 3YgiLMmt6fG4kjqcniKBxMiFXvt5tKbW16aM5Z1iAeegQWuotS2ejvCqcmx98l8dXJMaWTX0EJ7v vZeZn9plzQw3JTAeVUi4c4UtRIXPeC+CT8xzcFFmAYKGAsFuQEPISAwi60+ao7RuMhNAltVL7ZSG +/04uzRd7k2TWBJnp86zzg/y0XEwdNYWwV0oL4kNZPxcUXbxNXFB4v7reLZK5t+RJXFNCb1d7y+j 7k+keQIDAQABo4IBzzCCAcswHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5jb20wDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUzoIjhzUXsKy1 m4Ay0XMzONSDXt0wTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYmaHR0cHM6 Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wCQYDVR0TBAIwADCBmgYIKwYBBQUHAQEE gY0wgYowPgYIKwYBBQUHMAGGMmh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRsYXNy M3NtaW1lY2EyMDIwMEgGCCsGAQUFBzAChjxodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2Nh Y2VydC9nc2F0bGFzcjNzbWltZWNhMjAyMC5jcnQwHwYDVR0jBBgwFoAUfMwKaNei6x4schvRzV2V b4378mMwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9jYS9nc2F0 bGFzcjNzbWltZWNhMjAyMC5jcmwwDQYJKoZIhvcNAQELBQADggEBAKah4EqFB7nuTg1M3QGI963Z HaE551W8LWOHfTZf4zmOeoXCNoeyLN9D8qRz3+lHR8kME/T5q/F5KLThPCM4BTTzPGF59tMSebum Afvzbn1X8bFW4Q1boaF0HXKEHIZS3PHUBqH3Xbd6+hCb8hh2KRQl7iGxYJrAKQpTuC++Tw+rPGkl F6/NcliGHu2xiRBsyeDh1mkzZBAvugrisg0vnmuaWz/jxYVHgSK00NNiypuK/0Aggs95eeoB6m1R dZbXdPzEYrRk2o93YrZOi7Xabj7fBDk2VbMYyyqMbjalA5CDbxk4TK0OfXFE2sMEi8ojnONBpINK X9kRA5udV0GDqmoxggJqMIICZgIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFzIFIzIFNNSU1FIENBIDIwMjACEAEP eo9/GxknaxVybmbUvmIwDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEILmxWzWvrvZi JJXyGJ3tcwpfHEeHidxteVuNQSfuZkszMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTIxMTAyNjE0NTcyMlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJ YIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcN AQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQDCC5cbcpJTB6WAQrerapW9WpVHDETN +Rn/X+DH+UpPg9KO/aBh1Xz0uxiUp3aAYSQYLpBtdYlTZBNlFvW6f+kWlAQ4A5O5vPVtF4W53lGz F7oyBfU0goGh0CYOoirbnlLcKRt5rhDNViREEi41zN3d9w28CRuSAUmcSM9zBZMwNiySc1qsmxQP 4JR/mBx/xhpErjeYwTITIoINO3CZTu5yJYOHWEwIvvxqnTHB8aJvD74G73SaFMe3K64X83AMhJlJ FZzHsds+0Jnh4quw7p5AIvZQo2SPv3TMCv06BtlAKKszJEWab9Clcas6/wZEwl3Bybl/FC9nMXzN ze8C+9jK --000000000000e0641005cf42b140-- From nobody Tue Oct 26 10:55:44 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA6D3A15DA; Tue, 26 Oct 2021 10:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 mTgf44_DHRTL; Tue, 26 Oct 2021 10:55:32 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2117.outbound.protection.outlook.com [40.107.244.117]) (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 4B4663A0DED; Tue, 26 Oct 2021 10:55:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZFK9dvIuk/DYcYxc9P3mvyNT+8Mbxl+0M1PeyI4jsEp6LjmUF+t4rlSaJ27Mqe88kqwYuGbnpUgX2kiN8eb2IA5BMM4kVfsbg9NQTQ+VScOadsXbZAcc4ww/uyCSWMSvzG6wEKNEmsTuGSVWfoCpFmYrBp3cz+RJkx0nWFKOyzmQ8VAvvV+JdOA+CX+2u9KME+/Wils0VEvSfARVyqjA3egr4qliiUw+KqUDWBYMhPdjnLNK8gdvXm7pzMqI/4IHaRKqdbVpEXAOCVOIXSzQ5afl19mB3Vp/0aVM8QirdPrt379Tq66PbdQ3g+vZ3umGAKhdZpBVnL+kdifR/q8meA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Ec5pPH0tbrKnTiZFmzQVcG3TbnpGaqfhqWIKkKcqpFE=; b=m6orBpG9/ZQWQFA+cHHjEctuOo9oI9XYEmbNNQYceIeHwAil1ZL3KX/UrjSdZBhIcqVHFVy+3cvXMgSQC39mIrlH73c7Tmt0o21FKArx8mHMFFDwuIyFDBFvPcZwFCxEUaaNHff8VST1MWccU1ZzWwQwIHt0FRq6sb8E99cF++wLtzZIaLWc1hN32X5hyP1zN6T4sF5ckxBBRXkJH6vvQf6kHu4iDhC1OpQ6WwCKjPMYLcsUWseUZ9m1Tc0dYNeZDIgiILrcaFldZB91RwQb+Jxbf+V1H9Zhx22FxJXfzZLc82x3tJFzB0fJGVG+0uWkShqH1tDzhuz+YLXl2QsZ2w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ec5pPH0tbrKnTiZFmzQVcG3TbnpGaqfhqWIKkKcqpFE=; b=PR7thyckF2NvNotQR8VGyHCxyYusYwf9ORrLyM2bEoXy/08dPkPHC3FK+ccJvZxWclzBBNcE5IdJknpVXLcsCjQUXjryJ0zK4/uq8h+rCrXXtfba+JYsM4TEyOKow82YBGoXgwvp/doz+1Knvar4AQLyV9ICn3Fq9+sZj5QyJ6Q= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by BY5PR13MB3505.namprd13.prod.outlook.com (2603:10b6:a03:195::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.12; Tue, 26 Oct 2021 17:55:00 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::410d:64ed:3b3a:a6b5]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::410d:64ed:3b3a:a6b5%7]) with mapi id 15.20.4649.014; Tue, 26 Oct 2021 17:55:00 +0000 From: Haoyu Song To: Ben Schwartz , Alexey Melnikov CC: "secdir@ietf.org" , "last-call@ietf.org" , "draft-ietf-opsawg-ntf.all@ietf.org" Thread-Topic: [secdir] Secdir last call review of draft-ietf-opsawg-ntf-09 Thread-Index: AQHXylPv6nxr0pPd3EyPSu4wQGaGG6vlXtqAgAAwpOA= Date: Tue, 26 Oct 2021 17:55:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2c30c8d4-80b4-41db-2f90-08d998a9bb36 x-ms-traffictypediagnostic: BY5PR13MB3505: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qWpPlwDMQd7yQ7wNAK7HENToif4tGmubAhm89jep4uMgClR76ldM0e9StRv0A4miBo/acviibhGVmYi2DG6VD9sQIVgT1aEfu+SKcyvhMFXESS23wUinJDZlKDbK2AU8c2g5txSeWpsOpSUchL1TFUzcVqaoZkvIplFDEY8u45QPX0PS+5mRvLO9lkZgTYf+5Imngx87QvydOfz9UtXurGyOkzInjFLECVW6sPxmmfMMoHqPDfqld/gnqN7dePmmTa4thoUdZ1FwI12lRDpuNqwE5YLSkd7pYqVjVmfvWGV23wQrdKWvz8baJVa6eX17/I6iGvNfLUq4ItrrUAJyLXVYxDsA1RgEc16NoE9EDxvBM1sIHTTrWWhAyak2T1o3BokLIel95BVm1eeM4gcHSndvxcsCEGuSnCS4PZQ7mOlpOyvEQYJWLA1ZfcQ/XhDfDNOqTAA/P1Q9/v2ih33EL7btBNFOu2NH2SzE1wFTScZ+33dPBwg2GLDgQZd5EqJ84ONCTy5KzWs2bwfW5ufCmboD1yaII/DDoPDO2LOIFmz1t07rz1bu+zDrhqT6N9LZz4piJVc+3vm99xevvZQ81Ts0q5byIAujL5DDJTR6Ka2KvNt/vPyldiGnFz7zAVCBYNnxUPzgwYI2oXkJYiXhoKL0gTvLlR3g3w2kvv6FvLcIp8krWfMI+8FLVN9SDpuftYcTzU6P5ZN98c+CAaGLPQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(110136005)(54906003)(122000001)(4326008)(186003)(33656002)(316002)(26005)(38100700002)(44832011)(7696005)(66476007)(55016002)(71200400001)(66946007)(66446008)(8676002)(64756008)(53546011)(66556008)(76116006)(9686003)(2906002)(5660300002)(38070700005)(9326002)(52536014)(8936002)(83380400001)(508600001)(86362001)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?S3hqTCtOdXZJVnV4ZFpMOXZ1TjlQZHNQcVp1OGcyVWdDVTkySG5tckQxMlJn?= =?utf-8?B?Z0U1dHBsM0tUK3FvZERmMHVpK2duRzh1cFBvS3BabmoyalFPUlJieUF1UVZm?= =?utf-8?B?Ny9KbGRvd3UvZ1ZxNWtXbTdJQ3A4U2pEVkFpWVJ2V0RrWjVvQSt1a0xpc285?= =?utf-8?B?NjJ1cUhEUUdta0p0SXJ6RllkQ2k0eDZvWUhyOUNmZkhQbVJQOUtWZEMzbTFn?= =?utf-8?B?cTJIalpSREdDclFUd00wNXlaVmZZWVJIN2FBcjFDUU5EVjc5M3JDVjFFcFk1?= =?utf-8?B?M3V3ZXE1ckRQeW9MZHgyL1Y3azBQQTdydTFVOUwvaDF1NlFSV3BJK3V5WEow?= =?utf-8?B?YjRGdE11TzU0Mk0yQnVKVHRDZC9Sb3RGOTNOb2p6TTdCYWJMRHFIQVlneFZW?= =?utf-8?B?dGVXempBNmZqQ016UmVTY3RjLzBmZ2RHL2U1S0d4R1p0eE5ZYTBINnVjTW5v?= =?utf-8?B?WUZrb3BaeFRKYmFPN0t4Uy9jRGtiaEx0eEtidUlSTkN3UDIxQlRNZjVaRWUr?= =?utf-8?B?NVVxMytXL3hxNndNUUo4WnR1bGJKZzBtNERtOTV1WEVMcldaUERoaS9DU3l3?= =?utf-8?B?VVUyOVArZ0IzSDJaTG41dGZzN3VUZ1J3TzVjY2RybkVMdGlyRFdDUjBHemxI?= =?utf-8?B?WlhjdUR6RzZpa3VRUmc1cWpIVHBYQlRTYUhDVjVNY0l2MjNZOWIvYi8yem5a?= =?utf-8?B?T2VNN21kTnJzZ3hpR0o2Tllod2QzeXRXcVJyN3Z1U0I3dlFla1RZVEVEMCt4?= =?utf-8?B?bjBTb0VPalpaVWw4MERXSTBFY2RqSWpNeUoybGpHSVdXb0pMMHFzcGJoZXRv?= =?utf-8?B?bTN1c2lQQ21KTFFZeVhxOTU1cWJPZGZJbXMrZjZ3S3pZWFU0Vzc5WWFFRDJ3?= =?utf-8?B?ZjVwT0szby9uZlpBa2drSjdDWUQ1VDQxTlh1R3lKcS9FS0p4QlBJRXAwZ1h3?= =?utf-8?B?SEk4OTRYeGZhNUU3SEpqVWxSQ2JnWEtCVHJ0eXdVb3ZobVJkWVZhSE1YcDc1?= =?utf-8?B?K1VGc2RNUGxadVByMFlIWW1ScHZPdkJYVndqSTE4ZnB4SGc1R2VVZnJKTmJN?= =?utf-8?B?MGdTY2QvYXpxd042Y0s4ZGNUSEVVb3p0SDRxQS9OU0pxQXd3MXIyc1lzWFlp?= =?utf-8?B?Ym5XVmVETHRuTjNYSnRObU9pajVpczRxLzBOalVnbXZFeml4OHhLbGFwNUpk?= =?utf-8?B?bk9OZjRyakNVeUh1QmQ1YSs1ck8wZmFKYmNPcnU3c1dvT2UwSkhWdGFxak9D?= =?utf-8?B?b0VEZmpKRkdBTGkxWVo5M1NhQysyMWw0QVNLMTNmL0dBVWdMOVUzK1F0R2Rw?= =?utf-8?B?TEx0aHN6SytTYUM1TURXMmx6dW1aYVV1Um1FZnhTQXZYeDFDUWtsVncweTM3?= =?utf-8?B?cHFRcG9EWCttRk1aUDRsOE5EanhDbEJEYStEQzVzVVIzdGZzT05XVnpCZ1p2?= =?utf-8?B?VWdsd01UbzZaaGY3R2xpM2ljTm5vSy9aZlc2WkZsa3luUkxCTXhscnUwNzND?= =?utf-8?B?MlliTDVpa3hPMjdFK1lYM3lOUE5XOE92ajdUR0V3SHFsYStLMnNpTHlxOHJk?= =?utf-8?B?Uk41eWorMXBlNDhpN1BjZWExamJHdWVZSkZGVm5zM3NpeDc2VDdKalV4c3Zs?= =?utf-8?B?NTVZZnpYcWpSbWhWQkhwSmlJeHNxM1E5dU9KL2krUXBYbGdNY2lsbHM5eHYx?= =?utf-8?B?YUIwN0xDWW51bVdFSjVmcGxmOEN1dUNOUTNVOHdNRVNNaHRtVldVVTJVOTNL?= =?utf-8?B?V212Ulh3dEVmM05ESE9GUHFaR01nUkl0b20yWHh1T0J4NENhYXZ2c0RNTVQr?= =?utf-8?B?bVFFNFZNV1I1enRCaDZLMkEvSXhMSlF3TU1BUmR6MEkrVFYxd2JjQW44N2Fu?= =?utf-8?B?OTk3UHhUNW5MV0g5ZlJMUlk3R1U3cVhmbWxxdTZnRW4xZ0FDSzN2YVVwWXhL?= =?utf-8?B?NXJuWVJrdkdkVXhzdEx2elVBVllibFc0d1hGT29PUW1hVVBzSG9XbGFSV1B1?= =?utf-8?B?SDVZRmQ1N2pydmx6MU10TFdXd1M0aDc2VUczbzVSWDkwTW9TSWhkVnZMTUZk?= =?utf-8?B?QmR5MUxxUmpGNXlLcFNoNHNZQ1VLZUJRbDFyUkdqRnBCZ2JoMVNjb2xIZWxR?= =?utf-8?B?dXNXNnhQSWhGbFpRSFNSekpiZ1N6aGo3QlJxVk5aNWFDMUxSRkl2c2NOMEV6?= =?utf-8?B?Wmc9PQ==?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB4787C40F580B3C3ECA36D1AF9A849BY3PR13MB4787namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2c30c8d4-80b4-41db-2f90-08d998a9bb36 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2021 17:55:00.4583 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YTfifoZIHCwDEu0BbkncPZG7uECCJ8arsEM/p9LLe2qlum6eGHpJCva4gAOCtLCHdCisLgULjH7GkAbNA1BWog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3505 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-opsawg-ntf-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 17:55:37 -0000 --_000_BY3PR13MB4787C40F580B3C3ECA36D1AF9A849BY3PR13MB4787namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVuLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHN1Z2dlc3Rpb25zISBZZXMg d2Ugc2hvdWxkIG1ha2UgaXQgY2xlYXIgdGhhdCBuZXR3b3JrIHRlbGVtZXRyeSBhcmUgbm90IGFw cGxpY2FibGUgdG8gaW5kaXZpZHVhbCBlbmQgdXNlcnMuIEnigJlsbCBpbmNsdWRlIHRoZSBuZXcg dGV4dCB5b3VyIHByb3Bvc2VkIGluIHRoZSBkb2N1bWVudC4NCg0KQmVzdCByZWdhcmRzLA0KSGFv eXUNCkZyb206IEJlbiBTY2h3YXJ0eiA8YmVtYXNjQGdvb2dsZS5jb20+DQpTZW50OiBUdWVzZGF5 LCBPY3RvYmVyIDI2LCAyMDIxIDc6NTcgQU0NClRvOiBBbGV4ZXkgTWVsbmlrb3YgPGFsZXhleS5t ZWxuaWtvdkBpc29kZS5jb20+DQpDYzogc2VjZGlyQGlldGYub3JnOyBsYXN0LWNhbGxAaWV0Zi5v cmc7IGRyYWZ0LWlldGYtb3BzYXdnLW50Zi5hbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2Vj ZGlyXSBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLW9wc2F3Zy1udGYtMDkN Cg0KT24gVHVlLCBPY3QgMjYsIDIwMjEgYXQgNjoyNiBBTSBBbGV4ZXkgTWVsbmlrb3YgPGFsZXhl eS5tZWxuaWtvdkBpc29kZS5jb208bWFpbHRvOmFsZXhleS5tZWxuaWtvdkBpc29kZS5jb20+PiB3 cm90ZToNCi4uLg0KIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBjb3ZlcnMNCmV2ZXJ5dGhp bmcgSSBjYW4gdGhpbmsgb2YgaW4gcmVnYXJkcyB0byBkYXRhIGNvbmZpZGVudGlhbGl0eSwgcHJp dmFjeSwNCmFjY2VzcyBjb250cm9sLCBldGMuDQoNCkkgZGlzYWdyZWUgb24gdGhpcyBwb2ludC4N Cg0KVGhlIGRyYWZ0IG1lbnRpb25zIHByaXZhY3kgaW4gZXhhY3RseSB0d28gcGxhY2VzLg0KDQpG aXJzdCwgaW4gQmFja2dyb3VuZDoNCg0KPiAgIEl0IGlzIGVhc3kgdG8gc2VlIHRoYXQgbmV0d29y ayBvcGVyYXRpb25zIGNhbiBiZW5lZml0IGZyb20NCj4gICBuZXR3b3JrIGJpZyBkYXRhIHRvIGdh dGhlciBpbnNpZ2h0cyBpbnRvIGZsb3dzIHdpdGhvdXQgYnJlYWNoaW5nDQo+ICAgcHJpdmFjeS4N Cg0KVGhpcyBzdGF0ZW1lbnQgaXMgcHJlc2VudGVkIHdpdGhvdXQganVzdGlmaWNhdGlvbi4gIEkg ZGlzYWdyZWUuICBJZiBhbnl0aGluZywgaXQgaXMgaGFyZCB0byBzZWUgaG93IG5ldHdvcmsgb3Bl cmF0aW9ucyBjYW4gY29sbGVjdCAiYmlnIGRhdGEiIF93aXRob3V0XyBicmVhY2hpbmcgcHJpdmFj eS4gIFRoZSB0ZWNobmlxdWVzIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0IGFyZSB0ZWNobmljYWxs eSBpZGVudGljYWwgdG8gdGhlIFBlcnZhc2l2ZSBNb25pdG9yaW5nIGF0dGFjayBkb2N1bWVudGVk IGluIFJGQyA3MjU4Lg0KDQpTZWNvbmQsIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9uczoN Cg0KPiAgIEluIGFkZGl0aW9uIHRvIHNlY3VyaXR5LCBwcml2YWN5IGlzIGFsc28gYW4gaW1wb3J0 YW50IGlzc3VlLiAgTmV0d29yaw0KPiAgIHRlbGVtZXRyeSBtZWFucyB0byBpbXByb3ZlIHRoZSBu ZXR3b3JrIG9wZXJhdGlvbiB3aGljaCBjYW4gdWx0aW1hdGVseQ0KPiAgIGJlbmVmaXQgZW5kIHVz ZXIncyBxdWFsaXR5IG9mIGV4cGVyaWVuY2UuICBUaGUgbmV0d29yayBvcGVyYXRvcnMgbXVzdA0K PiAgIGJlIGhlbGQgYWNjb3VudGFibGUgYW5kIHN0cml2ZSBmb3IgYSBiYWxhbmNlIGJldHdlZW4g bWFuYWdpbmcgdGhlDQo+ICAgbmV0d29yayBhbmQgbWFpbnRhaW5pbmcgdGhlIHVzZXIgcHJpdmFj eSBvZiB0aGF0IG5ldHdvcmsuDQoNCkkgZG9uJ3QgdGhpbmsgdGhlIElFVEYgc2hvdWxkIGJlIHB1 Ymxpc2hpbmcgZHJhZnRzIHRoYXQgcmVjb21tZW5kIGNvbXByb21pc2luZyB1c2VyIHByaXZhY3ks IGFuZCBJIGZpbmQgdGhlIHF1YWxpZmljYXRpb25zIGhlcmUgdmFndWUgYW5kIHRvb3RobGVzcy4N Cg0KQWx0aG91Z2ggSSB2aWV3IHRoZXNlIGFzIHNlcmlvdXMgY29uY2VybnMsIEkgdGhpbmsgdGhl eSBjYW4gYmUgcmVtZWRpZWQgcXVpdGUgZWFzaWx5LiAgSXQgc2VlbXMgY2xlYXIgdG8gbWUgdGhh dCB0aGUgZm9jdXMgb2YgdGhpcyBkcmFmdCBpcyBvbiAidGVjaG5pY2FsIiBuZXR3b3JrcyB3aG9z ZSBlbmRwb2ludHMgZG8gbm90IHJlcHJlc2VudCB1c2Vycy4gIFdoZW4gYWxsIGVuZHBvaW50cyBv biB0aGUgbmV0d29yayByZXByZXNlbnQgYSBzaW5nbGUgYWRtaW5pc3RyYXRpdmUgZW50aXR5LCB1 c2VyIHByaXZhY3kgY29uY2VybnMgYXJlIGxhcmdlbHkgaW5hcHBsaWNhYmxlLiAgVG8gdGhhdCBl bmQsIEkgd291bGQgcmVwbGFjZSB0aGVzZSB0d28gcGFyYWdyYXBocyB3aXRoOg0KDQo+IFdoZW4g YSBuZXR3b3JrJ3MgZW5kcG9pbnRzIGRvIG5vdCByZXByZXNlbnQgaW5kaXZpZHVhbCB1c2VycyAo ZS5nLiBpbiBpbmR1c3RyaWFsLCBkYXRhY2VudGVyLCBhbmQgaW5mcmFzdHJ1Y3R1cmUgY29udGV4 dHMpLCBuZXR3b3JrIG9wZXJhdGlvbnMgY2FuIG9mdGVuIGJlbmVmaXQgZnJvbSBsYXJnZS1zY2Fs ZSBkYXRhIGNvbGxlY3Rpb24gd2l0aG91dCBicmVhY2hpbmcgdXNlciBwcml2YWN5Lg0KDQphbmQN Cg0KPiBMYXJnZS1zY2FsZSBuZXR3b3JrIGRhdGEgY29sbGVjdGlvbiBpcyBhIG1ham9yIHRocmVh dCB0byB1c2VyIHByaXZhY3kgW1JGQzcyNThdLiAgVGhlIE5ldHdvcmsgVGVsZW1ldHJ5IEZyYW1l d29yayBpcyBub3QgYXBwbGljYWJsZSB0byBuZXR3b3JrcyB3aG9zZSBlbmRwb2ludHMgcmVwcmVz ZW50IGluZGl2aWR1YWwgdXNlcnMsIHN1Y2ggYXMgZ2VuZXJhbC1wdXJwb3NlIGFjY2VzcyBuZXR3 b3Jrcy4gIEFueSBjb2xsZWN0aW9uIG9yIHJldGVudGlvbiBvZiBkYXRhIGluIHRob3NlIG5ldHdv cmtzIG11c3QgYmUgdGlnaHRseSBsaW1pdGVkIHRvIHByb3RlY3QgdXNlciBwcml2YWN5Lg0K --_000_BY3PR13MB4787C40F580B3C3ECA36D1AF9A849BY3PR13MB4787namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEJlbiw8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBzdWdnZXN0aW9ucyEgWWVzIHdl IHNob3VsZCBtYWtlIGl0IGNsZWFyIHRoYXQgbmV0d29yayB0ZWxlbWV0cnkgYXJlIG5vdCBhcHBs aWNhYmxlIHRvIGluZGl2aWR1YWwgZW5kIHVzZXJzLiBJ4oCZbGwgaW5jbHVkZSB0aGUgbmV3IHRl eHQgeW91ciBwcm9wb3NlZCBpbiB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhb3l1 PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gQmVuIFNjaHdhcnR6ICZsdDtiZW1hc2NAZ29vZ2xlLmNvbSZn dDsgPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMjYsIDIwMjEgNzo1NyBBTTxi cj4NCjxiPlRvOjwvYj4gQWxleGV5IE1lbG5pa292ICZsdDthbGV4ZXkubWVsbmlrb3ZAaXNvZGUu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gc2VjZGlyQGlldGYub3JnOyBsYXN0LWNhbGxAaWV0Zi5v cmc7IGRyYWZ0LWlldGYtb3BzYXdnLW50Zi5hbGxAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtzZWNkaXJdIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb3Bz YXdnLW50Zi0wOTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIFR1ZSwgT2N0IDI2LCAyMDIxIGF0IDY6MjYgQU0gQWxleGV5IE1lbG5pa292ICZs dDs8YSBocmVmPSJtYWlsdG86YWxleGV5Lm1lbG5pa292QGlzb2RlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmFsZXhleS5tZWxuaWtvdkBpc29kZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi4uLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7dGhlIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zIGNvdmVycyA8YnI+DQpldmVyeXRoaW5nIEkgY2FuIHRoaW5r IG9mIGluIHJlZ2FyZHMgdG8gZGF0YSBjb25maWRlbnRpYWxpdHksIHByaXZhY3ksIDxicj4NCmFj Y2VzcyBjb250cm9sLCBldGMuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRpc2FncmVlIG9uIHRoaXMgcG9pbnQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkcmFmdCBt ZW50aW9ucyBwcml2YWN5IGluIGV4YWN0bHkgdHdvIHBsYWNlcy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rmlyc3QsIGluIEJhY2tncm91bmQ6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDsmbmJzcDsgJm5ic3A7SXQgaXMgZWFzeSB0byBzZWUgdGhhdCBuZXR3b3JrIG9wZXJhdGlvbnMg Y2FuIGJlbmVmaXQgZnJvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mZ3Q7Jm5ic3A7ICZuYnNwO25ldHdvcmsgYmlnIGRhdGEgdG8gZ2F0aGVyIGluc2lnaHRz IGludG8gZmxvd3Mgd2l0aG91dCBicmVhY2hpbmc8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3ByaXZh Y3kuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHN0 YXRlbWVudCBpcyBwcmVzZW50ZWQgd2l0aG91dCBqdXN0aWZpY2F0aW9uLiZuYnNwOyBJIGRpc2Fn cmVlLiZuYnNwOyBJZiBhbnl0aGluZywgaXQgaXMgaGFyZCB0byBzZWUgaG93IG5ldHdvcmsgb3Bl cmF0aW9ucyBjYW4gY29sbGVjdCAmcXVvdDtiaWcgZGF0YSZxdW90OyBfd2l0aG91dF8gYnJlYWNo aW5nIHByaXZhY3kuJm5ic3A7IFRoZSB0ZWNobmlxdWVzIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0 IGFyZSB0ZWNobmljYWxseSBpZGVudGljYWwNCiB0byB0aGUgUGVydmFzaXZlIE1vbml0b3Jpbmcg YXR0YWNrIGRvY3VtZW50ZWQgaW4gUkZDIDcyNTguJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY29uZCwgaW4gdGhlIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7ICZuYnNwO0luIGFkZGl0aW9uIHRvIHNlY3VyaXR5LCBw cml2YWN5IGlzIGFsc28gYW4gaW1wb3J0YW50IGlzc3VlLiZuYnNwOyBOZXR3b3JrPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDt0ZWxlbWV0cnkgbWVhbnMgdG8gaW1wcm92ZSB0aGUgbmV0d29yayBvcGVy YXRpb24gd2hpY2ggY2FuIHVsdGltYXRlbHk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO2JlbmVmaXQg ZW5kIHVzZXIncyBxdWFsaXR5IG9mIGV4cGVyaWVuY2UuJm5ic3A7IFRoZSBuZXR3b3JrIG9wZXJh dG9ycyBtdXN0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtiZSBoZWxkIGFjY291bnRhYmxlIGFuZCBz dHJpdmUgZm9yIGEgYmFsYW5jZSBiZXR3ZWVuIG1hbmFnaW5nIHRoZTxicj4NCiZndDsmbmJzcDsg Jm5ic3A7bmV0d29yayBhbmQgbWFpbnRhaW5pbmcgdGhlIHVzZXIgcHJpdmFjeSBvZiB0aGF0IG5l dHdvcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgZG9uJ3QgdGhpbmsgdGhlIElFVEYgc2hvdWxkIGJlIHB1Ymxpc2hpbmcgZHJhZnRzIHRo YXQgcmVjb21tZW5kIGNvbXByb21pc2luZyB1c2VyIHByaXZhY3ksIGFuZCBJIGZpbmQgdGhlIHF1 YWxpZmljYXRpb25zIGhlcmUgdmFndWUgYW5kIHRvb3RobGVzcy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWx0aG91Z2ggSSB2aWV3IHRoZXNl IGFzIHNlcmlvdXMgY29uY2VybnMsIEkgdGhpbmsgdGhleSBjYW4gYmUgcmVtZWRpZWQgcXVpdGUg ZWFzaWx5LiZuYnNwOyBJdCBzZWVtcyBjbGVhciB0byBtZSB0aGF0IHRoZSBmb2N1cyBvZiB0aGlz IGRyYWZ0IGlzIG9uICZxdW90O3RlY2huaWNhbCZxdW90OyBuZXR3b3JrcyB3aG9zZSBlbmRwb2lu dHMgZG8gbm90IHJlcHJlc2VudCB1c2Vycy4mbmJzcDsgV2hlbiBhbGwgZW5kcG9pbnRzIG9uIHRo ZSBuZXR3b3JrDQogcmVwcmVzZW50IGEgc2luZ2xlIGFkbWluaXN0cmF0aXZlIGVudGl0eSwgdXNl ciBwcml2YWN5IGNvbmNlcm5zIGFyZSBsYXJnZWx5IGluYXBwbGljYWJsZS4mbmJzcDsgVG8gdGhh dCBlbmQsIEkgd291bGQgcmVwbGFjZSB0aGVzZSB0d28gcGFyYWdyYXBocyB3aXRoOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFdoZW4g YSBuZXR3b3JrJ3MgZW5kcG9pbnRzIGRvIG5vdCByZXByZXNlbnQgaW5kaXZpZHVhbCB1c2VycyAo ZS5nLiBpbiBpbmR1c3RyaWFsLCBkYXRhY2VudGVyLCBhbmQgaW5mcmFzdHJ1Y3R1cmUgY29udGV4 dHMpLCBuZXR3b3JrIG9wZXJhdGlvbnMgY2FuIG9mdGVuIGJlbmVmaXQgZnJvbSBsYXJnZS1zY2Fs ZSBkYXRhIGNvbGxlY3Rpb24gd2l0aG91dCBicmVhY2hpbmcgdXNlciBwcml2YWN5LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBMYXJn ZS1zY2FsZSBuZXR3b3JrIGRhdGEgY29sbGVjdGlvbiBpcyBhIG1ham9yIHRocmVhdCB0byB1c2Vy IHByaXZhY3kgW1JGQzcyNThdLiZuYnNwOyBUaGUgTmV0d29yayBUZWxlbWV0cnkgRnJhbWV3b3Jr IGlzIG5vdCBhcHBsaWNhYmxlIHRvIG5ldHdvcmtzIHdob3NlIGVuZHBvaW50cyByZXByZXNlbnQg aW5kaXZpZHVhbCB1c2Vycywgc3VjaCBhcyBnZW5lcmFsLXB1cnBvc2UgYWNjZXNzIG5ldHdvcmtz LiZuYnNwOyBBbnkNCiBjb2xsZWN0aW9uIG9yIHJldGVudGlvbiBvZiBkYXRhIGluIHRob3NlIG5l dHdvcmtzIG11c3QgYmUgdGlnaHRseSBsaW1pdGVkIHRvIHByb3RlY3QgdXNlciBwcml2YWN5Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_BY3PR13MB4787C40F580B3C3ECA36D1AF9A849BY3PR13MB4787namp_-- From nobody Tue Oct 26 11:10:12 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F443A161C; Tue, 26 Oct 2021 11:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 9cbDJKIJpPLa; Tue, 26 Oct 2021 11:10:00 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2108.outbound.protection.outlook.com [40.107.92.108]) (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 968523A0DE9; Tue, 26 Oct 2021 11:10:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mTTVL9JPCAAGT5sbsXHX/A0qA9+LM4dzaMnu+nvEOwnjKvjvpwhAOlbE2f32YcnDOMfLqPFiCNnTSBUnXVyQvHpD129L1q1GQfnju4DAbNKoFRHtOVkgK8kilAN0UwMNGve64j3BfPZrsRg4bnZvkQRVBqUPkuSWF3rdymxHilJu2qLaMnn58IIEcscKvZnQtc1vWVnuXD3QwbjVZ9gGidfc1EuUWL7Fef6kenvVV+0CEZEVGMY1PeqxU7wkMbtgW+jEZWkaPi9h6j5j3FaXEuwQ4fD8fjUKuhA0tawgbGLnDoWfXf7IJ/gn+oYgsqXOM7xVD0YjyNYhxEpCJS819w== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aEBtZvAjX6pYfkAK/LcuvNaFxOSltJ6/qDKJtzmIxuE=; b=U8ggUkytPfA1shKRZehLKcz++PNlOcySpXuD4X49vOqdcldW8VDjMkKA1NAQiVmkguOc/bX+UwDGzMz7O9CHPHl4NeRYUdrlCdPytevOVznOKYxcnDLlpWXnW8Vms/t2kLzWq9ywSWTV53Vu19OIpIHff3MOthXGKEYzpMx6GyaAARO0e/yFwt23kYPFybtHOnAqFTQGZ/sHF+pMNzsmTPELR2bwcsWJInihjwlfgyV63rYHsiLIY/naWlAv09HEmJkFtVOoTwzdxsd4dc9f+5Es8rC3iB77z+cpcGSPmixGpJx7P0UOwhbuJO3z8WgkkwAsST0MNkg2aLU87Rl6Sw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aEBtZvAjX6pYfkAK/LcuvNaFxOSltJ6/qDKJtzmIxuE=; b=CPtvZcwlfy25oXkSC2tQ017Y/2OS3gYpVMkrb1BTA6Fmb5W+T+FZ0QtIWeEYxjSTuZCTtvLayugN0BuGHJXB5Z8m524rOM0FMb5tlLlzZENcZguboEv8R1T3bpmI9OXbXYupn/pm0WNwgoRm7OpF5e0PPwuqz2QJDfBN2M8ZaY0= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by BYAPR13MB2343.namprd13.prod.outlook.com (2603:10b6:a02:c5::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.12; Tue, 26 Oct 2021 18:09:55 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::410d:64ed:3b3a:a6b5]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::410d:64ed:3b3a:a6b5%7]) with mapi id 15.20.4649.014; Tue, 26 Oct 2021 18:09:55 +0000 From: Haoyu Song To: Alexey Melnikov , "secdir@ietf.org" CC: "last-call@ietf.org" , "draft-ietf-opsawg-ntf.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-opsawg-ntf-09 Thread-Index: AQHXylPv6nxr0pPd3EyPSu4wQGaGG6vllG2g Date: Tue, 26 Oct 2021 18:09:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: isode.com; dkim=none (message not signed) header.d=none;isode.com; dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3a43944d-c936-4513-7809-08d998abd053 x-ms-traffictypediagnostic: BYAPR13MB2343: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nFc8Advc7QsFJ4xAWChAimKR7FcKJcd1ss3pCEgZdcJu5o1ENKqBpPoCqOEm9ZEdS1UmnftvZeLz17ldDRotVaT5/hS0GtjeGvc8WnIHT/+vxSYmxjY8mjj1zlq3MIbi33QXtIFvlLWObt6Gyk43tXD88fRMhW06HfRdMDGwR/IzgO4KuGcVh2LEoqbJCf7rFCu99tJ8zx+KHvntjA53vX02Em/miAL5B4ZqXgoeRkyTEs7UkuS+wL/LT+xtNd+qeJ9FUDq/IoXI8dhAk/mv83LdVdhZa9vu32BzRc3yheNXYspCX0vfT+0FLTOkQQ0RHL1T4RkMlxGqUygKjOXutxnlryF9ME1xY5SmVjO1TNV186BH/tjo/lQoJmUubHwc0ArSmZb/QZXY76C/lwRHYGz/pFReKgLgyHYIOIU+brAibdcgjM++iy6DX/1q8sGKkWr85LCO9pMu08moLmBXFB40nK+y8ekMoJGiOuMQbT0YkuIOiWSesJAFe/gfYb4MZXvWiw5uHezjIZGra7ySoNIfBN4i3MP/LBufxWGFFKgrpCVTkMTk8HeQPT0E0uq2yj3xnN9I9dYR0AN96uEvryXrwvURSHlvStGNv4PpWp4U+1GGtIVAkqwl2v8erEjwWJMV/IVOLtqOvmrcBAlm05v6TiniYeuZSTw1zkQpEc3ZIQcBilSqXe8hlQW5uOqSVNpEYIzQwVsHKRtsy7QiyA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(7696005)(508600001)(33656002)(52536014)(55016002)(86362001)(38070700005)(9686003)(66946007)(26005)(66556008)(4326008)(316002)(8936002)(2906002)(83380400001)(66476007)(186003)(66446008)(64756008)(110136005)(5660300002)(54906003)(76116006)(53546011)(38100700002)(8676002)(122000001)(6506007)(44832011)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?MnrrSsKprMTpJStIctXgCD/sbZGmYnTZPDG4JOo+FkD496MKpHp1r2X9m7LH?= =?us-ascii?Q?/OnAEScVCvR7mZJ+qrywEFwTa/OWVvfc2ZPtC409QltINJjV6FeqjE7FXEGo?= =?us-ascii?Q?wYNqINGYGcBh476342CWQgPddl8JAjsOUY6rldNHZlyLvKJ2Y10aCwiGcw7E?= =?us-ascii?Q?ar2WGd7Tpzg60EZT/hMHDyyAbIN1cPNMY7JGch7DQoBvr8cWkfwseWKXXEQk?= =?us-ascii?Q?/S7gZwQqSvBRHSNlmHOciTR+NgcVZR1kujiKr/ynBHJZW4yNcXvlliZQOMia?= =?us-ascii?Q?MGEtxt3+LhSlaJUo76yFRzXYINa5AG4U2fio8COWKXZkR3lZGu/P1jGTb4t7?= =?us-ascii?Q?Wm2QcCbEmjZfvaQZ5oFmGU2JiFoGMEVbUerLWLMA0+lP3oWpffYCMMl37bni?= =?us-ascii?Q?xSkFEwug6JmmGXWfPUt5sUmKBXDiXl20P254CNuAQgUa4aOmWQ9h6Zw4uTcl?= =?us-ascii?Q?t4eP5G+ijCd+vNgNek0rFRGng50vlKlmu2xh/yuKsWTDALEdGsffBn8cM4Hw?= =?us-ascii?Q?/H3yS6GOo5nh8q68j+n/1wdcVB+0XafWi5B7zjCpj5MiyVnJ70om3UItiKVf?= =?us-ascii?Q?TaV6vU4W8fk0EuH/wEh4pzISV5+9vgFeYZ0mV0IkFan5NXonPsAuZKrI1pOP?= =?us-ascii?Q?FoYsbBWMGjfn5Qatcx9whWpe2b3sea/C00r8UhcE8zvZriTrESnJe8d6rRjZ?= =?us-ascii?Q?8m4k/P0RHgyIL9Ba00Iex3/DzbpxOVJ0cvNJbCSHoWGwcx7h7nygg7erEyRR?= =?us-ascii?Q?6o6Um9rHkYLed/wTz0Q1z2HQtPreDO4KaNjII2c48GUr06twwQIueHRUcuwI?= =?us-ascii?Q?GHocit64RruL3CLzh7A6QepU31RonqKYyIqiNLAHFnkK920cvOvpb4VPNU2S?= =?us-ascii?Q?K0oweVPH+OMDHd8l1LaFmkI5+wL9aQ3ITRcbqWDdDF5pU1dePYK/FCim4MGn?= =?us-ascii?Q?fEqP+QGxw8G7S0l55iWSz1/Prr5Nq8JrrJdf99CIvlUzCDd/EhIz+FqhEnOW?= =?us-ascii?Q?Rd7gSlWUnBKkLrWNsUirWR8cAu8xw01g3h/p2ILBn4q8xg3MNR8D+76X7RYE?= =?us-ascii?Q?0AkL15EFUhZ3xMxObyvCMbPVwqdC/GFkUWKlwB+3MTuzjps/0eKS9tTkYKKT?= =?us-ascii?Q?sQ3feZ6RoiGSBQktURud27W2oqvgZMs6i7N605rsMK2zs7Rc9cmoRu6Lwtuz?= =?us-ascii?Q?f8g+Yarbd2Zmhq7YjOmDrIVgoUbzfIAmGKzI2+rtarYIjLHmTrKZGlKyrtZ5?= =?us-ascii?Q?MTgXvPajq+sKvrGAkzQbpwgqPa6+M03lw2RQf9NCgLee9VZFUbOQYlXTwq6K?= =?us-ascii?Q?OIYm/a3iO24ecLz1uXDTqlYTq26osSOtOLA79Jz85GpI2YVL+UMlEF2q0m2r?= =?us-ascii?Q?0mn/tWHnuzHJrk1bGiYR17pAxwCcgusahKZ47E7OBEFrUQp4Nd5SrEaG/SMr?= =?us-ascii?Q?xk87toQBUwPesLkTBed0UDWjmfvY6LiPy+15aYJjy5vVRx31XCgaPIMZ3CpN?= =?us-ascii?Q?ZvZQ+7P8Ek8Cq9TA6KwEykCLt2gPEG2e0UAUOmSQ7CWBJ4T/30rnihzzaam/?= =?us-ascii?Q?k9rQ5hTNqdxMliJ6p1ToC5xJw9DllTpv3tnNGU3aY0DbxbtCvMiAm6xsbVRh?= =?us-ascii?Q?cA=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3a43944d-c936-4513-7809-08d998abd053 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2021 18:09:55.0610 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wM/V+jMcl1I9wuLz9uuOO2ZnhyDnogkAv4FBbBcTYzNN0iQhkSuPV6JCQEAGXSmbt3PDEd3pNkv/HOsMArbS5A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2343 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-opsawg-ntf-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 18:10:07 -0000 Hi Alexey, Thank you very much for the review. I'll add informative reference to JSON = and XML in the document. Best regards, Haoyu -----Original Message----- From: Alexey Melnikov =20 Sent: Tuesday, October 26, 2021 3:26 AM To: secdir@ietf.org Cc: last-call@ietf.org; draft-ietf-opsawg-ntf.all@ietf.org Subject: Secdir last call review of draft-ietf-opsawg-ntf-09 Reviewer: Alexey Melnikov Review result: Ready Hi, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG.=20 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. Network telemetry is a technology for gaining network insight and facilitat= ing efficient and automated network management. This document defines netwo= rk telemetry as an extension of Operations, Administration, and Management = (OAM) techniques. This document clarifies the terminologies and classifies = the modules and components of a network telemetry system from different per= spectives, in particilar whether they operate at the control plane, the man= agement plane or the forwarding plane. Examples of both IETF and non IETF t= echnologies are given. The document is well written and has a good Security Considerations section= . As this document is describing a framework, the security considerations s= tay generic, but the Security Considerations covers everything I can think = of in regards to data confidentiality, privacy, access control, etc. Nits: JSON and XML should have informative references. Best Regards, Alexey From nobody Tue Oct 26 11:36:02 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739C43A16AA for ; Tue, 26 Oct 2021 11:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.429 X-Spam-Level: X-Spam-Status: No, score=-5.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=mandelberg.org header.b=S0Qt5jKT; dkim=pass (2048-bit key) header.d=mandelberg.org header.b=KT5EK54T 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 6ng6LXi21gug for ; Tue, 26 Oct 2021 11:35:50 -0700 (PDT) Received: from mail-pf1-x461.google.com (mail-pf1-x461.google.com [IPv6:2607:f8b0:4864:20::461]) (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 A1C553A16AB for ; Tue, 26 Oct 2021 11:35:50 -0700 (PDT) Received: by mail-pf1-x461.google.com with SMTP id f11so277736pfc.12 for ; Tue, 26 Oct 2021 11:35:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:dkim-signature:dkim-signature:subject:to:cc :references:from:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=xxKy6Jd83zBoCORjEobecIEoeSkptnsSWNZmfFr1s74=; b=3bhG5OVEwQck1UvMNsx4myIRU3wfEeiXPDuEFtgsX/chbBBusBHoMztvSFibZ/SFVc ZePhegDFvQxK05piFv8ZvnGTEwkF/dPynGBSpMmFKAcIUvsHWph54xL4YzQHTH5ppFg7 Ai4CumxFZppsFpg9vfmeSiaB4mSZ2jDKt3vVuEyTUwIlRGZ/3RRmwBAVqi3Rt7l9oai7 XspDbuzIhk+VJ/4FAPGJpRirmN7CFdpzdds0bm1Xwl3VyQZzTMg6aQYzDz0wUxcEue+b PQDtkjS5z16AfYMV9M2Ul7yD+kpKbR6uMVgQrNGrXrI4AvfbNJBBq5mVlO9+H8XBE6B6 fsDA== X-Gm-Message-State: AOAM531WwbGfQTwS5WbASB85ewvqPKFc/hQegnw/HGwamGe8w9xqEMQN +J5hocqi234xd1Wsivb8od2V7dVKw0wXYuJCqrXUM5VRhtxfig== X-Google-Smtp-Source: ABdhPJzdP5Hx1/GstUOaWZWf7PKFTGWV23DQyIZiQCmIfgkZiOlkPPSDsfzIS2Nyec/SCNl2+yqXwToOKFBy X-Received: by 2002:a62:7989:0:b0:47b:e0f6:de0f with SMTP id u131-20020a627989000000b0047be0f6de0fmr21576516pfc.42.1635273348648; Tue, 26 Oct 2021 11:35:48 -0700 (PDT) Received: from mail-outbound-e14cf917.virgo.mandelberg.org (pool-74-104-157-60.bstnma.fios.verizon.net. [74.104.157.60]) by smtp-relay.gmail.com with ESMTPS id kr14sm347428pjb.16.2021.10.26.11.35.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Oct 2021 11:35:48 -0700 (PDT) X-Relaying-Domain: mandelberg.org DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=mandelberg.org; i=@mandelberg.org; q=dns/txt; s=mail-outbound-e14cf917-07914516; t=1635273347; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : from; bh=OrNNcwigRGz93FPkww3JPXyuRAAOwUzPyl/aK39jYXU=; b=S0Qt5jKTMpHJkx/ucxhGqekMel/HxjI1n0NWZ9OAFO7uYyYLniRlxsK5MRmhqtAFOhvTs 9Zz25pVlK1W2iDgDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; i=@mandelberg.org; q=dns/txt; s=mail-outbound-e14cf917-b7c648a2; t=1635273347; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : from; bh=OrNNcwigRGz93FPkww3JPXyuRAAOwUzPyl/aK39jYXU=; b=KT5EK54T+pcSuduNJkI2o3Erhs8B9SpVZdzM+4p2D2dsr2VszotemJS/KOrHKF9pytspN flys39r0UOK35uNjNzBkgIVuCm0Ddtpedgp2Svl90qsGwq3wHznt1JXmc8DETtREtHbVsr6 E9RzkmJ4PRtDQ32uj50UekOjjDiHTWqa7SXKmcTpuGkNjBhqqDANdq5nb1m56GcYaE7Pc8D aCHvEFkuwGnoXAVcAjSenVKhRBcKzysgvE+M8iTnQGv7S9bX9lzCLZOhyIfJ7KF0nNh2ils kdiaZ3Yn2XUTyL9V2f7YGT955LrCpZaR1jfMkDrLZHYWRYMOfXaZLQ6yzraQ== Received: from [IPv6:fde5:2b79:35f0:2::14e] (solaria.virgo.mandelberg.org [IPv6:fde5:2b79:35f0:2::14e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by mail-outbound-e14cf917.virgo.mandelberg.org (Postfix) with ESMTPSA id 4Hf0rM36YNzySW; Tue, 26 Oct 2021 18:35:47 +0000 (UTC) To: tuexen@fh-muenster.de Cc: secdir@ietf.org, iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> <2bac74f5-e134-d50c-a640-4a87fdbc5790@mandelberg.org> <0D125385-E009-4EAD-8087-F7A90F74663B@fh-muenster.de> From: David Mandelberg Message-ID: Date: Tue, 26 Oct 2021 14:35:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <0D125385-E009-4EAD-8087-F7A90F74663B@fh-muenster.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 18:35:56 -0000 Op 23-10-2021 om 18:46 schreef tuexen@fh-muenster.de: >> On 14. Oct 2021, at 22:55, David Mandelberg wrote: >> >> Op 14-10-2021 om 15:31 schreef tuexen@fh-muenster.de: >>>> On 14. Oct 2021, at 19:57, David Mandelberg wrote: >>>> From a security perspective, there are multiple good options for MAC algorithms to use here, including some HMAC algorithms. (I don't know enough about MAC algorithms to be too much more specific.) >>>> >>>> From a standards perspective, I think the doc should be clear about what the requirements actually are. This seems like an unusual case, because there are no interoperability concerns as far as I can tell. (Except maybe length? Are there constraints on the length of the field?) I don't know what the right thing to do here is, but I'd lean towards 1) documenting the requirements for interoperability, 2) documenting the requirements for security, and 3) providing an example algorithm that implementations should use unless they have a reason to pick something different. Do other people think that's a good way to go? Or should it be kept simpler and just recommend something specific? >>>> >>>> If it helps, here's some draft text of what I'm thinking: >>> You are suggesting to add this to section 5.1.3, I guess. So are you suggesting to remove the MAC entry from Section 2.3? >> >> Yes, if you think that makes sense. > OK, removed the text from Section 2.3. > > I updated the text in Section 5.1.3 such that the new paragraph reads: > > The hashing method used to generate the MAC is strictly a private How about just "The method ..." in case people want to use non-hash-based MAC algorithms? > matter for the receiver of the INIT chunk. > The use of a MAC is mandatory to prevent denial-of-service attacks. > There is a tradeoff between to computational complexity and the level of > security the MAC provides. > Using the HMAC-SHA1 might be an acceptable compromise. > The secret key SHOULD be random ( provides some > information on randomness guidelines). > The secret keys need to have an appropriate size. > When using HMAC-SHA1, secret keys of at least 160 bits are appropriate according > to . > The secret key SHOULD be changed reasonably frequently, and the timestamp in the What is "reasonably frequently"? Maybe add "(e.g., daily)" or some other example frequency? > State Cookie MAY be used to determine which key is used to verify the MAC. > > I use HMAC-SHA1 since this seems to be what is used in the FreeBSD and Linux implementations. From a DoS perspective, that seems fine to me, but I'd like to hear Tero's response too about if this needs to do more than just protect against DoS. From nobody Tue Oct 26 11:49:37 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F483A16CB; Tue, 26 Oct 2021 11:49:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Catherine Meadows via Datatracker To: Cc: calsify@ietf.org, draft-ietf-calext-ical-relations.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163527417024.2618.2790897732112692791@ietfa.amsl.com> Reply-To: Catherine Meadows Date: Tue, 26 Oct 2021 11:49:30 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-calext-ical-relations-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 18:49:31 -0000 Reviewer: Catherine Meadows Review result: Has Issues This draft describes increases the expressive and scope of relationships that can be defined in iCalendar. It updates the already existing RELATED-TO by allowing UID and URI as values and introduces a GAP parameter to specify the length of time between two events. It also introduces three new properties: CONCEPT (roughly, category), LINK (typed reference to external meta-data or related resources), and REFID(used to identify a key that identifies all components that use that REFID). The syntax of the relationships is given and intended use cases are described. The introduction of greater expressiveness does not by itself introduce security considerations, but the introduction of references to external sources does, specifically for URIs, which are allowed as arguments of the RELATED-TO, CONCEPT, and LINK properties. The authors of this document are aware of this, and refer the reader to [RFC3986] for more information. I agree that the security considerations related to use of URIs proposed in this draft are covered by this RFC. I wonder though, if the document shouldn’t concern a similar warning about the data type REFERENCE. This refers to an XML document or a portion of an XML document. Since XML can also be used as an attack vector, a mention in the Security Considerations Section would seem appropriate. From nobody Thu Oct 28 17:46:25 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE5C3A0771; Thu, 28 Oct 2021 17:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.429 X-Spam-Level: X-Spam-Status: No, score=-5.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 Jm8HCN4GVqCp; Thu, 28 Oct 2021 17:46:14 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A343A076C; Thu, 28 Oct 2021 17:46:13 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 35E8E1B00220; Fri, 29 Oct 2021 03:46:05 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1635468365; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NtPZJVwxla5uULCGonB4sav4wD2aeqXVr177ePHBMUk=; b=sCH1GhEZsayk0lSDZBAN40YUaynVqidnv4B6CPdR2LKkk1HG7t0cqbaCcdSEB0UjDzSex+ I+INqdGe+aOpqU3961gQWBKRKh95lUC7P1ci6Se8teP60xK8m00IsuEkIIeUfedouqO+oU 2EMPpne8Y58wofFwSDx8b+xwW8qjkygu3LHBENNKCATPIYCt0wDKtP3bf/+YxYAYYtWy5u vBElt7c9XfdQabRrXZHDOOEuRkpaEvrrpiRdF+ddN0SXFac7P81D/biLblEXbJB+PJUg5T woI7sO2VB5s7kqg7rSCvmYl76Hczd77kt+sR6pfarV4ekDzeqX+J1osRlUknZQ== Received: by fireball.acr.fi (Postfix, from userid 15204) id 5910625C12DC; Fri, 29 Oct 2021 03:46:04 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24955.17484.301497.733333@fireball.acr.fi> Date: Fri, 29 Oct 2021 03:46:04 +0300 From: Tero Kivinen To: tuexen@fh-muenster.de Cc: David Mandelberg , iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org, secdir@ietf.org In-Reply-To: <87B43E4B-F93B-4ED7-9BFD-C501B093F9DB@fh-muenster.de> References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> <2bac74f5-e134-d50c-a640-4a87fdbc5790@mandelberg.org> <24941.43160.312498.778487@fireball.acr.fi> <87B43E4B-F93B-4ED7-9BFD-C501B093F9DB@fh-muenster.de> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 11 min ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1635468365; a=rsa-sha256; cv=none; b=buylsibntzELKdoqaJVgXs0QuJXahzFUlKqBb+G34eMxZ/r8BS32Mu92ld9Drhy5M0AE7C KfDlvYB4rPCSClG8Pvmh22UVcS6RVI18wSNg2PQ1PdpVeP6IQuymOQNR3Hp1Zl0SWoVzHi 1STD9J+EeE/ieCiAeqI75gnflTLANfVqiQ6lOpFlpdAH15qPXB5WutCt2QkkzE+Cnit5ZV /bp2KgCqflrUSIgYrZLQOSw4hWKOD8BTHm2QcLN6AiWAtQQwOX8tmXjzvtR0nYMhZWNSne ZDx3hvyJJj+ERyWsWkRByFgYBH5CTNh0WAbnQ4jQeYmzK4kY/vjq1R1nHzn8Hg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1635468365; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NtPZJVwxla5uULCGonB4sav4wD2aeqXVr177ePHBMUk=; b=VbAtJ237O2CKCD3w0CMGwnPfGcLsDLNIFF6ESPGvlzQfAKIcHMpFq7I/XFEQtPgtVHxThI FlxvAxAGs2S2bkdkaUqmarktg0pLjlGxbufe8dDojZJE0qAXAqh4GghDDS0HlzUr9WaF0N G3GlhNpDh87cB3OqEjknHm904gcLebtOqpQIqiT0fClnhWKXBrcgG+0+X5YbYXx2W7h6Kb ipD8n5NDe8Yk/Ld4+wo2kI7oHH+m20eOxsSfVqkO7/CUOxpvc5ItlVWoEsnvXARrb1IE/7 C+YwaNmK1kZtT7WxK28fQ3spVtb03PdK1BelgwsjZvSVejHYb5VfPKbDlxiqBw== Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 00:46:20 -0000 tuexen@fh-muenster.de writes: > In the FreeBSD implementation, we put the INIT and INIT ACK chunk > in the cookie. And when parsing this information, we do it the same way > as parsing any inout from the network. Adding that kind of implementation guidance would be good idea for the draft too, but on the other hand that does not really follow the suggestion of using minimal subset of data, or is it really true that INIT and INIT ACK do not have any unneeded information in them? Do you include the IP addresses etc where the frame came, i.e. do you use whole IP packet or only the inner payload? One of the attacks against this is to generate lots of valid cookies from thousands of IP addresses than then resend them with faked source address to cause denial service attack on that one address. If the cookie does not have IP addresses in it then this attack is possible. > > In addition to that your cookie generation might even leak out some > > internal data from the server if implemnetor really creates a TCB and > > then includes too much data from the TCB to cookie (i.e., if someone > > just created TCB, didn't bother to create minimal subset of > > information, but simply decided that TCB is small enough that it can > > be used as such, and then TCB might include some pointers to other > > structures that are internal to the kernel). > > The specification does not require the cookie to be encrypted. So the > sender should not put any information in the cookie that can't be shared. > In the FreeBSD case, most of the information was already on the wire... But the draft does not suggest the method used by FreeBSD, but instead suggest creating TCB and taking minimal subset of it. TCB might have some private data in it, so perhaps adding some comment about that too. I.e., say that as the cookie is not encrypted care must be taken when constructing cookie, so that the cookie does not leak out any information that should not be leaked. > > Because of this I do recommend using the proper cryptographic message > > authentication code (MAC) and not a thing that IKEv2 and Photurus > > used, i.e. simple hash with secret at the end (which would most likely > > still be safe for this use, but proper MAC is better). Also you do > > want to say something that the MAC part of that cookie, needs to have > > certain length to protect against forgery attempts, you are not using > > cookie to just protect against denial of service. > The text I added to address Davids issue, refers to HMAC-SHA1. > Is that acceptable? Altough HMAC-SHA1 is still acceptable, there is common confusion where people confuse the fact that plain SHA1 is being deprecated, and assume that also means HMAC-SHA1. In some cases libraries have been removing support for code for deprecated algorithms and then suddenly there might be case that you can't use HMAC-SHA1 anymore as SHA1 algorithm got removed. Anyways as this is internal matter to the implementation I do not think we need to recommend any specific algorithm, we could simply say any MAC with acceptable security properties is fine, and if we really want to suggest something suggesting HMAC-SHA256 or similar might be better. Anyways as there is no data that needs to be properly authenticated (and parsed with care) plain hash + secret should not be used (like is used in Photurus and IKEv2), and proper MAC is needed. -- kivinen@iki.fi From nobody Thu Oct 28 17:56:58 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 324DF3A0783 for ; Thu, 28 Oct 2021 17:56:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <163546901557.28986.12511475283457298815@ietfa.amsl.com> Date: Thu, 28 Oct 2021 17:56:56 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 00:56:56 -0000 Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview For telechat 2021-10-28 Reviewer LC end Draft Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy For telechat 2021-12-02 Reviewer LC end Draft Samuel Weiler 2021-08-25 draft-ietf-alto-path-vector Klaas Wierenga 2021-08-30 draft-ietf-alto-cdni-request-routing-alto Last calls: Reviewer LC end Draft Shaun Cooley 2021-10-18 draft-ietf-jmap-smime Scott Kelly 2021-10-27 draft-ietf-regext-rfc7484bis Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 Adam Montville 2021-11-23 draft-eggert-bcp45bis Russ Mundy 2021-10-26 draft-ietf-rum-rue Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Yoav Nir 2021-11-17 draft-ietf-oauth-iss-auth-resp Magnus Nystrom 2021-11-16 draft-ietf-acme-authority-token Hilarie Orman 2021-11-15 draft-ietf-lsr-yang-isis-reverse-metric Radia Perlman 2021-11-15 draft-ietf-dispatch-javascript-mjs Derrell Piper 2021-11-15 draft-ietf-dhc-dhcpv6-yang Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Samuel Weiler 2021-08-25 draft-ietf-alto-path-vector Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Klaas Wierenga 2021-08-30 draft-ietf-alto-cdni-request-routing-alto Liang Xia 2021-03-17 draft-ietf-core-sid Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy Dacheng Zhang 2021-09-07 draft-ietf-bess-evpn-bum-procedure-updates Early review requests: Reviewer Due Draft Stephen Farrell 2021-09-15 draft-ietf-ippm-ioam-direct-export Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Kathleen Moriarty 2021-10-25 draft-ietf-dots-multihoming Tina Tsou 2021-08-25 draft-ietf-opsawg-sbom-access Loganaden Velvindron 2021-08-18 draft-ietf-taps-arch Next in the reviewer rotation: Tim Polk Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Benjamin Schwartz Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore From nobody Fri Oct 29 02:15:50 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682E23A0E7E; Fri, 29 Oct 2021 02:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.479 X-Spam-Level: X-Spam-Status: No, score=-1.479 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 HRpgViYMkxgg; Fri, 29 Oct 2021 02:15:44 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E493A0E7C; Fri, 29 Oct 2021 02:15:42 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:90ae:586f:5b0f:6ea]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id BA612721BE021; Fri, 29 Oct 2021 11:15:35 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_9CABFE02-12CB-4761-8EF0-D22782570692"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) From: tuexen@fh-muenster.de In-Reply-To: Date: Fri, 29 Oct 2021 11:15:34 +0200 Cc: secdir@ietf.org, iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <659D0564-C8DC-41AB-B118-BEAE0D2AB1A2@fh-muenster.de> References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> <2bac74f5-e134-d50c-a640-4a87fdbc5790@mandelberg.org> <0D125385-E009-4EAD-8087-F7A90F74663B@fh-muenster.de> To: David Mandelberg X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 09:15:50 -0000 --Apple-Mail=_9CABFE02-12CB-4761-8EF0-D22782570692 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 26. Oct 2021, at 20:35, David Mandelberg = wrote: >=20 > Op 23-10-2021 om 18:46 schreef tuexen@fh-muenster.de: >>> On 14. Oct 2021, at 22:55, David Mandelberg = wrote: >>>=20 >>> Op 14-10-2021 om 15:31 schreef tuexen@fh-muenster.de: >>>>> On 14. Oct 2021, at 19:57, David Mandelberg = wrote: >>>>> =46rom a security perspective, there are multiple good options for = MAC algorithms to use here, including some HMAC algorithms. (I don't = know enough about MAC algorithms to be too much more specific.) >>>>>=20 >>>>> =46rom a standards perspective, I think the doc should be clear = about what the requirements actually are. This seems like an unusual = case, because there are no interoperability concerns as far as I can = tell. (Except maybe length? Are there constraints on the length of the = field?) I don't know what the right thing to do here is, but I'd lean = towards 1) documenting the requirements for interoperability, 2) = documenting the requirements for security, and 3) providing an example = algorithm that implementations should use unless they have a reason to = pick something different. Do other people think that's a good way to go? = Or should it be kept simpler and just recommend something specific? >>>>>=20 >>>>> If it helps, here's some draft text of what I'm thinking: >>>> You are suggesting to add this to section 5.1.3, I guess. So are = you suggesting to remove the MAC entry from Section 2.3? >>>=20 >>> Yes, if you think that makes sense. >> OK, removed the text from Section 2.3. >> I updated the text in Section 5.1.3 such that the new paragraph = reads: >> The hashing method used to generate the MAC is strictly a private >=20 > How about just "The method ..." in case people want to use = non-hash-based MAC algorithms? Sure. Text changed. >=20 >> matter for the receiver of the INIT chunk. >> The use of a MAC is mandatory to prevent denial-of-service attacks. >> There is a tradeoff between to computational complexity and the level = of >> security the MAC provides. >> Using the HMAC-SHA1 might be an acceptable compromise. >> The secret key SHOULD be random ( provides = some >> information on randomness guidelines). >> The secret keys need to have an appropriate size. >> When using HMAC-SHA1, secret keys of at least 160 bits are = appropriate according >> to . >> The secret key SHOULD be changed reasonably frequently, and the = timestamp in the >=20 > What is "reasonably frequently"? Maybe add "(e.g., daily)" or some = other example frequency? In FreeBSD this can be controlled by a sysctl variable and the default = is 1 hour. But I'm adding the text you suggest. >=20 >> State Cookie MAY be used to determine which key is used to verify the = MAC. >> I use HMAC-SHA1 since this seems to be what is used in the FreeBSD = and Linux implementations. >=20 > =46rom a DoS perspective, that seems fine to me, but I'd like to hear = Tero's response too about if this needs to do more than just protect = against DoS. OK. Thanks for your comments! Best regards Michael --Apple-Mail=_9CABFE02-12CB-4761-8EF0-D22782570692 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTEw MjkwOTE1MzRaMC8GCSqGSIb3DQEJBDEiBCDPYrdnX4qlshkUaBv9S9dBt7qiGNox+kRmc83xzIeJ 7DCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQELBQAEggEAWzIDO3IbYuYyREVnMZVV8NuujFlG xdsTATq5tEmkjO6r0TYN+hogNuRAmNbL3HuFGeHdhZZv409rl+DN0eEOnY5qDxLnCKs1VHDH3vGT AgemlvUoEwnPvbHg1nZ1Dg6a2bntHyjsaFgN5QUQeeFApodRUWj1eopi822heE0m06hHEd9jyqgV 3aQXvjh9guvFFG9v2JkV0XjkhDeiaC+Cxyj+UyOLwGq3kFUeTs9OwRbWLWppe+eg7DJxdU7hlJxU jX/DS1S/uaL5RsXMrIfWogMn97T7Kml8Vj44Nw9QrmdzXkzK/0WrBoc0GodOEpV8ss7DV6Jl/nK5 w49y7gdXPAAAAAAAAA== --Apple-Mail=_9CABFE02-12CB-4761-8EF0-D22782570692-- From nobody Sun Oct 31 14:13:56 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27A13A08FD; Sun, 31 Oct 2021 14:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_SOFTFAIL=0.665, 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 MW58pQxnIuMl; Sun, 31 Oct 2021 14:13:46 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3995E3A0944; Sun, 31 Oct 2021 14:13:37 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:6dad:9b34:616f:3f07]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id A843F721E2807; Sun, 31 Oct 2021 22:13:26 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_A6AC8462-B6C9-48B7-A6C4-0F498AC48FD9"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) From: tuexen@fh-muenster.de In-Reply-To: <24955.17484.301497.733333@fireball.acr.fi> Date: Sun, 31 Oct 2021 22:13:25 +0100 Cc: David Mandelberg , iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org, secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1BB0CA3B-8B01-4D7F-A332-3311DE53489E@fh-muenster.de> References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> <2bac74f5-e134-d50c-a640-4a87fdbc5790@mandelberg.org> <24941.43160.312498.778487@fireball.acr.fi> <87B43E4B-F93B-4ED7-9BFD-C501B093F9DB@fh-muenster.de> <24955.17484.301497.733333@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2021 21:13:51 -0000 --Apple-Mail=_A6AC8462-B6C9-48B7-A6C4-0F498AC48FD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 29. Oct 2021, at 02:46, Tero Kivinen wrote: >=20 > tuexen@fh-muenster.de writes: >> In the FreeBSD implementation, we put the INIT and INIT ACK chunk >> in the cookie. And when parsing this information, we do it the same = way >> as parsing any inout from the network. >=20 > Adding that kind of implementation guidance would be good idea for the > draft too, but on the other hand that does not really follow the > suggestion of using minimal subset of data, or is it really true that > INIT and INIT ACK do not have any unneeded information in them? Do you I just wanted to provide information how this can be implemented. I = don't want to require any implementation to do it that way. I think you need to have all the information for the INIT and INIT-ACK chunk available. So you could only try to use a more compact = representation. But this comes with other drawbacks. So this is also a compromise... > include the IP addresses etc where the frame came, i.e. do you use > whole IP packet or only the inner payload? One of the attacks against FreeBSD uses the INIT and INIT ACK (without the cookie) in addition to some other information, which includes the source and destination address of the packet containing the INIT chunk. In general, the cookie needs to contain the address lists contained in the INIT and INIT ACK chunks and the corresponding source addresses of the packets containing the INIT chunk and the INIT ACK chunk, since these addresses are the ones that will be used by the association. > this is to generate lots of valid cookies from thousands of IP > addresses than then resend them with faked source address to cause > denial service attack on that one address. If the cookie does not have > IP addresses in it then this attack is possible.=20 So if the source address of the packet containing the COOKIE ECHO chunk is not one of the addresses reported earlier in the INIT chunk or used as the source address of the packet containing the INIT chunk, it won't be used. Please note that the attacker can send packets containing the COOKIE ECHO chunk from spoofed addresses, but the attacker can also include these addresses in the INIT chunk. So the only address the receiver of the COOKIE ECHO chunk considers confirmed is the address the INIT ACK was sent to. >=20 >>> In addition to that your cookie generation might even leak out some >>> internal data from the server if implemnetor really creates a TCB = and >>> then includes too much data from the TCB to cookie (i.e., if someone >>> just created TCB, didn't bother to create minimal subset of >>> information, but simply decided that TCB is small enough that it can >>> be used as such, and then TCB might include some pointers to other >>> structures that are internal to the kernel). >>=20 >> The specification does not require the cookie to be encrypted. So the >> sender should not put any information in the cookie that can't be = shared. >> In the FreeBSD case, most of the information was already on the = wire... >=20 > But the draft does not suggest the method used by FreeBSD, but instead > suggest creating TCB and taking minimal subset of it. TCB might have > some private data in it, so perhaps adding some comment about that > too. The text has changed. It doesn't mention the TCB anymore in this = subsection. It reads: Inside this State Cookie, the sender SHOULD include a MAC (see [RFC2104] for an example), a timestamp on when the State Cookie is created, and = the lifespan of the State Cookie, along with all the information necessary = for it to establish the association including the port numbers and the verification tags. >=20 > I.e., say that as the cookie is not encrypted care must be taken when > constructing cookie, so that the cookie does not leak out any > information that should not be leaked. Sure. What about adding the following sentence: Since the State Cookie is not encrypted, it MUST NOT contain information which is not being envisioned to be shared. >=20 >>> Because of this I do recommend using the proper cryptographic = message >>> authentication code (MAC) and not a thing that IKEv2 and Photurus >>> used, i.e. simple hash with secret at the end (which would most = likely >>> still be safe for this use, but proper MAC is better). Also you do >>> want to say something that the MAC part of that cookie, needs to = have >>> certain length to protect against forgery attempts, you are not = using >>> cookie to just protect against denial of service. >> The text I added to address Davids issue, refers to HMAC-SHA1. >> Is that acceptable? >=20 > Altough HMAC-SHA1 is still acceptable, there is common confusion where > people confuse the fact that plain SHA1 is being deprecated, and > assume that also means HMAC-SHA1. In some cases libraries have been > removing support for code for deprecated algorithms and then suddenly > there might be case that you can't use HMAC-SHA1 anymore as SHA1 > algorithm got removed. >=20 > Anyways as this is internal matter to the implementation I do not > think we need to recommend any specific algorithm, we could simply say > any MAC with acceptable security properties is fine, and if we really > want to suggest something suggesting HMAC-SHA256 or similar might be > better. OK. So I remove (the recently added) sentence: Using the HMAC-SHA1 might be an acceptable compromise. and replace it by A MAC with acceptable security properties SHOULD be used. Then it makes sense to also remove (the recently added) sentence: When using HMAC-SHA1, secret keys of at least 160 bits are appropriate = according to . Should I also change back "reasonably frequently (e.g., daily)" to = "reasonably frequently" when describing that the secret should be changed? >=20 > Anyways as there is no data that needs to be properly authenticated > (and parsed with care) plain hash + secret should not be used (like is > used in Photurus and IKEv2), and proper MAC is needed. > --=20 > kivinen@iki.fi --Apple-Mail=_A6AC8462-B6C9-48B7-A6C4-0F498AC48FD9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTEw MzEyMTEzMjVaMC8GCSqGSIb3DQEJBDEiBCD0WD3JGD0HloLYm/XZy1g+aDPIhp3wgu3lIMKeynXY ITCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQELBQAEggEAnL/C04PfOT9a6Dvjws66+xdUeN1D LAB4TTaSCnTMNW65dRVsl9Pw0ZZL9K3W6F5d/o5N+MDGbVUGx65sfLu8ZRPzStX/ARrduNIL5Qno gUiST+KNrOz/iONUS0XhzERP4d8UL3g1rtpIDOmUKAKVpuFa3givOFQt9pwb0uj/nm1Wgqa3ysBO vuAuRR4Gdl1fSDk/kzXIBgapFPVSxj7DqqdCmsG94BGWT6L75LNHiTBWrOXYI1KbdFk8YTIaHz6J J+XXN/BHh2gmBrOoQe011tZRP0bRQpPoYO/ook4F8t/UdXDGwccKN+GhMko65eeAFpD4NNXskU0K bWY6L8i7pgAAAAAAAA== --Apple-Mail=_A6AC8462-B6C9-48B7-A6C4-0F498AC48FD9--