From nobody Fri Jan 1 22:18: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 DB7073A0D9C; Fri, 1 Jan 2021 22:18:39 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=outlook.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 kYm8CavtPy0L; Fri, 1 Jan 2021 22:18:38 -0800 (PST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12olkn2076.outbound.protection.outlook.com [40.92.21.76]) (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 7BBA63A0D9B; Fri, 1 Jan 2021 22:18:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IgtEaF3HrPHbt6gFmBqxZM0VI9R0X1YJngFTq60B2SRdF70hIodadh/uqlisq1hE2iYg/CfZHTL044CR9MY/lDKE3SRd+7+th/ceDD3XHi6crgdeTWvYp7+oU+c8pDN1eKrsv3fZWJKV2qOJOqIBIRughn0AnvjhJs8c/PXG4Lpk2obGrRoqG/+QSdGIHG8RbIxYxSsLUjj1vBfnNwsKWLsJAduR4hRTEQGnOYKPvxZEk5Cyhg9xGOGCjtQzEL+jD06wAn1eh8zgp11LMnZtXNWcNpYVHqVK4cuYY+P8Xc/etzWA0HnLJ9mIVjvzQ0z1kBval3/MjYYW1qKkfLMk+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F2lkH+jV/qkt00MKEvWUqb+JR3U9sxQbRLiUF3xe2x0=; b=ckW40ephobdXKfXU11DdAZvJfQSGuBZ+r7nsDhxajXZQxhR+/9vUQNbtq/Gj0aPz+x2XqM0Xird+CeIROyjdvlO63eOAg3g20qdb74te2gUOMPBa2waTeCiMvElhxvKISAxih86/bY9ljugrD7w1xz2j1IzRXkFURb/0MuYD5MjKqvbABEvfHu6W2w0WNhL3mDGW0MyFKZi0oxVgxtRp5TQBddqQVp3+7Gvbh/Gjtjzsr/kq/Owx67d7SLIixuORO4zfwkx85WXfPvkUPH6P+9lIvrb4jwTyUAKDJjTw3ISklZVPI7CJVmDosjKCKEsjjynLaAAjdeitxx5TxEKkHg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F2lkH+jV/qkt00MKEvWUqb+JR3U9sxQbRLiUF3xe2x0=; b=gA/4pdgRqiIjNKUIUI1yC/7lhCP1iaKsecKYu6KQ6LSDRIeMFZ/JM5LhF2m3KqlztzTRz2W5U0HkQwWCF3vQOoV4u6XJF/7pnDb4pHY+asg14Ln6XXQeVV0OXgMJr0igd4qhUpX0rQMkCiLayLo1sjEO5seRyOsvYL1wKhNdSowqM31BLv8QYn6XzLVGyPpMX+UjdnwQBhyIZ1usR8qJQ9EgqnBxE/S/FkYCLbnreus7Z6oNY11DQsQzBWm3igcleuCeGdawfdEs854by2VaXDN1bybeoVR8AlMmybKzDlpdc2OyTHYSPvBkJU7IdsOPOJ+szopig6tvnhLOCnCQdQ== Received: from BN8NAM12FT008.eop-nam12.prod.protection.outlook.com (2a01:111:e400:fc66::52) by BN8NAM12HT172.eop-nam12.prod.protection.outlook.com (2a01:111:e400:fc66::332) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.4; Sat, 2 Jan 2021 06:18:30 +0000 Received: from MW2PR1901MB4683.namprd19.prod.outlook.com (2a01:111:e400:fc66::4c) by BN8NAM12FT008.mail.protection.outlook.com (2a01:111:e400:fc66::411) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.4 via Frontend Transport; Sat, 2 Jan 2021 06:18:30 +0000 Received: from MW2PR1901MB4683.namprd19.prod.outlook.com ([fe80::acfb:46c0:302:e8b0]) by MW2PR1901MB4683.namprd19.prod.outlook.com ([fe80::acfb:46c0:302:e8b0%7]) with mapi id 15.20.3721.020; Sat, 2 Jan 2021 06:18:29 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-cose-x509.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-cose-x509-08 Thread-Index: AQHW4M73ErZkKROHhk2JrD1oZ35R0g== Date: Sat, 2 Jan 2021 06:18:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:0F73AF2A2B9D44FFDC31C4EB6A0347EA1E4FD4E01FB6E10217C319D478A39D4B; UpperCasedChecksum:ADA0B7443F1F6D328A1B591EC2992B083E4626CCF0A020B42A994FD139EE5390; SizeAsReceived:6789; Count:41 x-tmn: [/SX5CJZdmeSJYy3Oxc2VrvHjIvUGW1gF] x-ms-publictraffictype: Email x-incomingheadercount: 41 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: f1d971f9-fc1c-4328-4527-08d8aee638f2 x-ms-traffictypediagnostic: BN8NAM12HT172: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lbDfl/mEeSY5PP3zaEk7OJf2wu9Ui4w1Wv9rpCjayJfnR4TwpjEQUcZun9LMxJksZTLH1KDBP6yCKVz06kAnwUwDQLtVyAadun3jKtt7Wn1nW2IaeXIl6WpFkFJgbE/md4K5MZpEMS6Zcs60ABAW5Jic6ptPrn+yGBngd+oxdwm621m8FO0R4fPgb7ElEelxsN4iM3DgaoXAjBftxLdXUdLV5S872vBh8et4FW/KXaQ6y6N6P5OoochSFqqjyGs+ x-ms-exchange-antispam-messagedata: 2tMFijFMJdT0S+4ojXRmsSl3dTMRs86xGcpJCSNUi61i1cG6FOi5HWWoRsTN+h2/UM9UJ6Xs7yokyzi9sit+lkXu7SjR8xSoq4GTOCC5rqXEFczC3rb5TYunJAQTjh2rfn/dGXMPs6ArnR4KuSQWsg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW2PR1901MB4683793A0AD38A020367079EDFD40MW2PR1901MB4683_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: BN8NAM12FT008.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: f1d971f9-fc1c-4328-4527-08d8aee638f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2021 06:18:29.3438 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8NAM12HT172 Archived-At: Subject: [secdir] Secdir review of draft-ietf-cose-x509-08 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, 02 Jan 2021 06:18:40 -0000 --_000_MW2PR1901MB4683793A0AD38A020367079EDFD40MW2PR1901MB4683_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This is a re-review. I reviewed draft-ietf-cose-x509-07 in September. I fou= nd nothing objectionable and all of my suggestions were addressed. As I men= tioned there, the only thing the security community might find vaguely cont= roversial is the mandate (on page 5) for support of the SHA-256 hash algori= thm "for interoperability" (along optionally with other hash algorithms). T= he document correctly notes that what is specified does not guarantee inter= operability. One new typo: page 4: duplicating certificates -> duplicate certificates --Charlie --_000_MW2PR1901MB4683793A0AD38A020367079EDFD40MW2PR1901MB4683_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG.  The= se comments were written primarily for the benefit of the security area dir= ectors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This is a re-review. I reviewed draft-ietf-cose-x509-07 in September. = I found nothing objectionable and all of my suggestions were addressed. As = I mentioned there, the only thing the security community might find vaguely= controversial is the mandate (on page 5) for support of the SHA-256 hash algorithm "for interoperabili= ty" (along optionally with other hash algorithms). The document correc= tly notes that what is specified does not guarantee interoperability.

One new typo:

page 4: duplicating certificates -> duplicate certificates


--Charlie
--_000_MW2PR1901MB4683793A0AD38A020367079EDFD40MW2PR1901MB4683_-- From nobody Sat Jan 2 09:22: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 9CBBA3A0C7E; Sat, 2 Jan 2021 09:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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, 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 SzBIQBBOCGSP; Sat, 2 Jan 2021 09:21:58 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 EA8C03A0C7C; Sat, 2 Jan 2021 09:21:57 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id 81so21174019ioc.13; Sat, 02 Jan 2021 09:21:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fJyrTUbovHzFlHqR5uVtc8KigirEArbi4I+s/IXJBog=; b=P9CDjdRXq3S1Tjw1qMPD2wZMZG7UqDYznPEsXpRRbgBTiyDhRgHwP1t1E4oREzBaml sXAMLK7GSJN4u56nhb5lc7FaxeAXhZj1BaxObVPHeaIzBEclDtQjbL0+nVAxzMh0ps57 EcQXPFkrJYP/6Ujo8BOXiOw2FfFpA9pMzYpsN4zEF1Ubcu3TVr3V7KeDcBHR1rqI72oG 5FtnZTahlwWfApub0ABLfE7UH0yJTW/6QmnJ2C7SYhm8iUBO4JMwr+GFLDA78eyDVUAM /H02YOg/6xPJANm+cgaMSAYyUT6ui8QQwCmFxWshir1WCA00Q2NxnYOwr44P0PS4qdmL eYAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fJyrTUbovHzFlHqR5uVtc8KigirEArbi4I+s/IXJBog=; b=IIUvqDpbY9tzag17KXmu9ymh8axKL8VV/se1LUVFEdC4MTfWGklrDL685Lcj02JYOF mNXI34/kOjzq36UpbQdAunWh4cFozzp7JZWKAXu2B6ypd23mUtoyTNwyzqjnGH14AU7m xvIQjSuHjfsA5X75LSSgxGorx+HQ/AFnK+HGAguKraRinC4rl1e0R3k6qfoO2gantZw2 bI1r98Ay1kI+d2L5ud+L2anPJTqCS89fxHVi25nariOEX2gQei1j5ywsjADZKRp3FKWe oaRRtnNON+GgXXwrgwxqZucueLRhz5ndH0hx9f/o7gJDwZ5ZgAJMtzVASEfax+Am8Da2 nXXA== X-Gm-Message-State: AOAM530oHbYiozI44QyySnPoGIvBg9wDQ1IQXy/2IKbCa8Pp18tSY0NN +WstFqz0OKlvBGqhRUZ9hX/J1x58swiu/VZg2wTxPATdQ5U= X-Google-Smtp-Source: ABdhPJxiZ9yV6EjvVkzZDEfk3sA9MqE0ue2JXNtNEdtiSDq+Y5efaT8G89FNJDFFBRsRWwpujRoPvQdZotBrBXoLJI8= X-Received: by 2002:a02:2a4f:: with SMTP id w76mr55498291jaw.50.1609608117085; Sat, 02 Jan 2021 09:21:57 -0800 (PST) MIME-Version: 1.0 References: <009501d6cdd2$98623ed0$c926bc70$@chinatelecom.cn> In-Reply-To: <009501d6cdd2$98623ed0$c926bc70$@chinatelecom.cn> From: Donald Eastlake Date: Sat, 2 Jan 2021 12:21:46 -0500 Message-ID: To: Aijun Wang Cc: "iesg@ietf.org" , draft-ietf-teas-pce-native-ip.all@ietf.org, secdir , last-call@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-teas-pce-native-ip-14 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, 02 Jan 2021 17:22:04 -0000 Hi, My apologies for slow response. On Tue, Dec 8, 2020 at 9:26 PM Aijun Wang wrote: > > Hi, Donald: > > > > Thanks for your careful review. > > I have updated the draft according to your suggestions, except one minor = change for the name of the document. > > It seems =E2=80=9CPath Computation Element (PCE) based Traffic Engineerin= g (TE) in Native IP Network=E2=80=9Dis more better? Thanks for making the changes. I agree that adding the word "based" to the title is an improvement. 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 Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com > > I have uploaded the new version on the IETF repository. > > Detail responses are inline below. > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > From: d3e3e3@gmail.com > Sent: Tuesday, December 8, 2020 1:58 PM > To: iesg@ietf.org; draft-ietf-teas-pce-native-ip.all@ietf.org > Cc: secdir ; last-call@ietf.org > Subject: SECDIR review of draft-ietf-teas-pce-native-ip-14 > > > > I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. Docume= nt editors and WG chairs should treat these comments just like any other la= st call comments. > > The summary of the review is Ready with Issues. > > > > Security: > > This is a very high level Informational document about a general method o= f traffic engineering using multiple BGP sessions and PCE. The Security Con= siderations section is adequate except that I would recommend adding a refe= rence for BGP security, perhaps to RFC 7454. > > [WAJ] Done, thanks. > > > > Other Issues: > > The title of the document doesn't really make it clear what it is about a= nd does not spell out some acronyms. I suggest the following: > > Path Computation Element (PCE) Traffic Engineering (TE) in Native IP Netw= orkNetworks > > [WAJ] Just add one word =E2=80=9Cbased=E2=80=9D to become =E2=80=9CPath C= omputation Element (PCE) based Traffic Engineering (TE) in Native IP Networ= k=E2=80=9D > > > > Editorial: > > There are a number of editorial/typo issues including the curious lack of= any expansion or definition for the first three acronyms listed in Section= 2 on Terminology and what appears to be a line sliced off the bottom of Fi= gure 3. Also, I think a reference should be given where BGP Flowspec is men= tioned in Section 7.1, presumably to the rfc5575bis draft. See attached for= detailed change suggestions in MS Word with tracked changes and, alternati= vely, as a PDF thereof. > > [WAJ] Done, thanks. > > > > 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 > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com From nobody Sat Jan 2 14:25:18 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 C9ABF3A0EBF; Sat, 2 Jan 2021 14:25:11 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=outlook.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 jF0ZzpDQe-qA; Sat, 2 Jan 2021 14:25:10 -0800 (PST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11olkn2072.outbound.protection.outlook.com [40.92.19.72]) (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 484C33A0EB9; Sat, 2 Jan 2021 14:25:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jBXz7YXWi0FYww27/mBMpmcTXhZeLJEW3TT8+z06iMINEoQr0ihafKMzjRfonWo6wBN80ZroNB8nUe7hSu1Vj1zDGzA297BfczoiLAziSx9BMKtXsbgUgeipIdPvCQ+695xa944GssKuoRWKS9HzgHpefUpbgo7X/QC4Z3NUBKtOTvPUHt9HCpK/ge4ZX/Mm4Oa0MDBx2MzqzwYUCStWU2GgQixau7YI7RKni9NkIhfYN32CbGoP204OUysDasTmz2KK+crqqVY/ZtWFOS3IWAOhLC91f0KQktEasQKVjjA8lO2lmAyGxH3fFWh60a3QCJyJ+1Nyow7KgfdTkz/s9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J1F2BDC+lhglEhxRgKorposm0OxujqpxX29L5RGNn5k=; b=Gp7N3TokCyjU/+QaWPjebgm5xmCBjepa3l7Bgmptjwqk74T558i9dWTB5cFiaa3vjQMH3DTOdYWNzxubsA3Y8JsEfgcTMeV6tADDmb8dOzkVDTnjWCTkJHbpNNmXSLwMiEi8mroaMjYNTj1PhWGp9kyRjcTT1j2PyyNa1Sawh+GVFTpyL6Rs7/CsWCj/e5lMG/18tUcP1S+NBUCF+B9q2KMuPHxUtsGhFJ94QtEgAinpkhkRkW+knDA7x7bRJtR3E4erzgXO+bIu94qjb1sIYbjVoUyBfT6dSv2pjZBBj74G86zQ6h8KmLVUaljGWTe9+BWUMlDfYAX/cbdiAZOhJQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J1F2BDC+lhglEhxRgKorposm0OxujqpxX29L5RGNn5k=; b=Qj6g6KkVwLQWg6QNPFCrsKHN93IhIFVb1h5DpOPSYHKjPsy6UWSsw9ZSVMpERlJhjoJN0VUXRlrtE0kriDsGa2Mn2N2S5d35+z+vS8INCruVLj20nv+XPNj8FQwrPI0OPZKj+GrGjNIgkp3+yMyfGgHL6I92TrLxI8bmSep3OOPvnI4cSUAeGM7bXIdBkDf4antoLum++81cI0s4KhJorOQHV2mcxtQlHeqo4aoqQOEszbYrTrC5b8ognmPbYLMkODGQrC4vpBET04wIT4zkVINW1f1ajohuN/yIB72GrWyibr5x3c5Nt2Wwq1abL7sXv0QegLtNsLByDZ17qWfZvw== Received: from CO1NAM11FT009.eop-nam11.prod.protection.outlook.com (2a01:111:e400:3861::4b) by CO1NAM11HT181.eop-nam11.prod.protection.outlook.com (2a01:111:e400:3861::187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.23; Sat, 2 Jan 2021 22:25:06 +0000 Received: from MW2PR1901MB4683.namprd19.prod.outlook.com (2a01:111:e400:3861::4d) by CO1NAM11FT009.mail.protection.outlook.com (2a01:111:e400:3861::317) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.23 via Frontend Transport; Sat, 2 Jan 2021 22:25:06 +0000 Received: from MW2PR1901MB4683.namprd19.prod.outlook.com ([fe80::acfb:46c0:302:e8b0]) by MW2PR1901MB4683.namprd19.prod.outlook.com ([fe80::acfb:46c0:302:e8b0%7]) with mapi id 15.20.3721.020; Sat, 2 Jan 2021 22:25:06 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-gont-numeric-ids-sec-considerations.all@ietf.org" Thread-Topic: Secdir review of draft-gont-numeric-ids-sec-considerations-06 Thread-Index: AQHW4VX2SjD0sId81UObyThhAnVqCg== Date: Sat, 2 Jan 2021 22:25:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:32710F484CDA4554084264C35030BB8C51C875F34BD42EF88F85773F6F813F2D; UpperCasedChecksum:077983F85F332999B2D438FF9AD9C42547A07468E3E5C31A34C2F194DA7FC184; SizeAsReceived:6875; Count:41 x-tmn: [f/Z5pKDgeIyNn1DdCZzsyamZkGlMVKhW] x-ms-publictraffictype: Email x-incomingheadercount: 41 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 97d77120-8618-4ac2-e82f-08d8af6d41fb x-ms-traffictypediagnostic: CO1NAM11HT181: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: N0RbWmk4XDMLH6KtW7kqT7OVk7K1J0vY73VVvewlMw2jNv/0ENXZxeri9dA9oumjH8Yg1+pIINfKNq9hoUCLzr3d26QtHH4Cw7s8O/sqIMr/vtOCeGleXVJl87+YY6PaMp4SzcGY0hcDQREQIDvTdcE5WiVPgAo5mcVxkIYEvZTpt5RAqJ2+6iH9xqOaxEB6RLZuPZN3aFAKTDZ8wY1lgco9VkvSMiUlk3mKhdZ97D3FbynYAOQBJfXF3rI9GPUU x-ms-exchange-antispam-messagedata: y5MBTnc760AJNeEs5ov9P3K2a52mwOuWMAkMDQEsizVKOuVUYrvHoVAvUkePj7hRxPLfBWrXh5OqoTZujH3iMp2XL1PxTKNVDW+vTs76fUYtwZlPdKXG4kePJEP/dTlSUcbX3D8ceJQl3Mqri8perQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW2PR1901MB46833CA29CAF359CA145963CDFD40MW2PR1901MB4683_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT009.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 97d77120-8618-4ac2-e82f-08d8af6d41fb X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2021 22:25:06.5649 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM11HT181 Archived-At: Subject: [secdir] Secdir review of draft-gont-numeric-ids-sec-considerations-06 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, 02 Jan 2021 22:25:12 -0000 --_000_MW2PR1901MB46833CA29CAF359CA145963CDFD40MW2PR1901MB4683_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document (with intended status of BCP) offers (necessarily) vague advi= ce on what specs should say about the selection of transient numeric identi= fiers used in networking protocols (like TCP sequence numbers, DNS TxIDs, I= P Fragment Identifiers, etc.). It updates RFC 3552 ("Guidelines for Writing= RFC Text on Security Considerations") in the sense that it offers addition= al guidance for information to be included in security considerations, thou= gh it more importantly offers guidance on how the text prescribing how thes= e transient identifiers are chosen should be specified. The security consid= erations might include a justification of why those algorithms are appropri= ate. Essentially, it says that when picking transient numeric identifiers, bewar= e of leaking information about other things going on at the node choosing t= he identifiers to either eavesdroppers or to the legitimate target of the c= ommunication (or making it possible for someone off-path to guess the ident= ifiers being used and forge packets). There is ample history of implementer= s making bad choices in this space to warrant getting the advice out there.= My only reservation with this document is that it would be nice if the adv= ice could be somewhere more visible (e.g., in some future update to RFC3552= ). There are three other I-Ds in process with closely related content; it woul= d be kind to readers if these could be combined into one. They are: draft-g= ont-predictable-numeric-ids, draft-irtf-pearg-numeric-ids-generation, and d= raft-irtf-pearg-numeric-ids-history. It's hard to imagine a reader of any o= ne of these who would not benefit from reading the others. Typos: p6 Section 4: "to be a predictable" -> "to be predictable" "identifiers in other context" -> "identifiers in another context" --Charlie --_000_MW2PR1901MB46833CA29CAF359CA145963CDFD40MW2PR1901MB4683_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG.  The= se comments were written primarily for the benefit of the security area dir= ectors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document (with intended status of BCP) offers (necessarily) vague= advice on what specs should say about the selection of transient numeric i= dentifiers used in networking protocols (like TCP sequence numbers, DNS TxI= Ds, IP Fragment Identifiers, etc.). It updates RFC 3552 ("Guidelines for Writing RFC Text on Security Con= siderations") in the sense that it offers additional guidance for info= rmation to be included in security considerations, though it more important= ly offers guidance on how the text prescribing how these transient identifiers are chosen should be specified. The securi= ty considerations might include a justification of why those algorithms are= appropriate.

Essentially, it says that when picking transient numeric identifiers, = beware of leaking information about other things going on at the node choos= ing the identifiers to either eavesdroppers or to the legitimate target of = the communication (or making it possible for someone off-path to guess the identifiers being used and forg= e packets). There is ample history of implementers making bad choices in th= is space to warrant getting the advice out there. My only reservation with = this document is that it would be nice if the advice could be somewhere more visible (e.g., in some future u= pdate to RFC3552).

There are three other I-Ds in process with closely related content; it= would be kind to readers if these could be combined into one. They are: dr= aft-gont-predictable-numeric-ids, draft-irtf-pearg-numeric-ids-generation, = and draft-irtf-pearg-numeric-ids-history. It's hard to imagine a reader of any one of these who would not benefit fr= om reading the others.


Typos:

p6 Section 4: "to be a predictable" -> "to be predic= table"
"identifiers in other context" -> "identifiers in an= other context"

--Charlie

--_000_MW2PR1901MB46833CA29CAF359CA145963CDFD40MW2PR1901MB4683_-- From nobody Sat Jan 2 18:57:41 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 D295F3A1355; Sat, 2 Jan 2021 18:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 qewlcGBbArNi; Sat, 2 Jan 2021 18:57:33 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5D203A1356; Sat, 2 Jan 2021 18:57:18 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id ACBF2283BB4; Sun, 3 Jan 2021 02:57:13 +0000 (UTC) To: Charlie Kaufman , "secdir@ietf.org" , "iesg@ietf.org" , "draft-gont-numeric-ids-sec-considerations.all@ietf.org" References: From: Fernando Gont Message-ID: <38b7232f-a516-dcee-e56c-43062357ecf8@si6networks.com> Date: Sat, 2 Jan 2021 23:51:57 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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-gont-numeric-ids-sec-considerations-06 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, 03 Jan 2021 02:57:37 -0000 Hello, Charlie, Thanks a lot for your comments! In-line.... On 2/1/21 19:25, Charlie Kaufman wrote: [....] > Essentially, it says that when picking transient numeric identifiers, > beware of leaking information about other things going on at the node > choosing the identifiers to either eavesdroppers or to the legitimate > target of the communication (or making it possible for someone off-path > to guess the identifiers being used and forge packets). There is ample > history of implementers making bad choices in this space to warrant > getting the advice out there. My only reservation with this document is > that it would be nice if the advice could be somewhere more visible > (e.g., in some future update to RFC3552). > > There are three other I-Ds in process with closely related content; it > would be kind to readers if these could be combined into one. They are: > draft-gont-predictable-numeric-ids, > draft-irtf-pearg-numeric-ids-generation, and > draft-irtf-pearg-numeric-ids-history. It's hard to imagine a reader of > any one of these who would not benefit from reading the others. FWIW, this effort originally started as a single document that combined the three documents you reference (draft-gont-predictable-numeric-ids). However, at the time, when presenting this effort at the SAAG meeting, there was agreement that the orginal document (draft-gont-predictable-numeric-ids) contained different kinds of information (Informational-ish vs. BCP-ish) and thus we were instructed to split the original document in three pieces. Since then, each of the resulting pieces were progressed on their own, with two of them eventually being adopted by the PEARG, and this one (draft-gont-numeric-ids-sec-considerations) being progressed as an AD-sponsored document. > Typos: > > p6 Section 4: "to be a predictable" -> "to be predictable" > "identifiers in other context" -> "identifiers in another context" Will fix this in the next rev. Thanks a lot! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jan 4 05:48: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 88C903A0D3A; Mon, 4 Jan 2021 05:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hcIHUPnsuJ8; Mon, 4 Jan 2021 05:48:32 -0800 (PST) Received: from p130.piuha.net (p226.piuha.net [193.234.219.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2CF3A0D39; Mon, 4 Jan 2021 05:48:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A9CBB66012A; Mon, 4 Jan 2021 15:48:29 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erltOKfLdTOz; Mon, 4 Jan 2021 15:48:27 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id D11D166019D; Mon, 4 Jan 2021 15:48:27 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <160702546541.14061.15940689920006174458@ietfa.amsl.com> Date: Mon, 4 Jan 2021 15:48:26 +0200 Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <160702546541.14061.15940689920006174458@ietfa.amsl.com> To: Brian Weis X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-core-dev-urn-08 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 Jan 2021 13:48:37 -0000 Brian:=20 Many thanks for your review. I=E2=80=99m going through the various = review comments and taking them into account. I agree with the three = points you made. A new version will be submitted soon, for the moment = you can see the changes in = https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--08.diff.html = and https://arkko.com/ietf/core/draft-ietf-core-dev-urn.txt Jari > On 3 Dec 2020, at 21.57, Brian Weis via Datatracker = wrote: >=20 > Reviewer: Brian Weis > Review result: Serious Issues >=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. >=20 > The summary of the review is Ready with nits. >=20 > This document generally defines a new URN namespace for hardware > device identifiers, and then further defines the URN body layout > for several types of devices, where devices are identified by a > global identity (e.g., a MAC address, organizational-specific serial > number, etc.). >=20 > Long-term identifiers have privacy considerations, and these are > well documented here. >=20 > Here are some things that ought to be thought about: >=20 > (1) The Security Considerations section seems to focus on concerns > around devices not allowing the device identifiers to be modified, > and gives rather broad advice about a DEV URN implementation > faithfully representing the device. It would be good for this section > to also warn implementors of the risks of a DEV URN being transmitted > without integrity protection. That is, if the device faithfully > represents itself, a man in the middle changing the DEV URN in a > protocol may cause the system using the device to not manage the > device properly, or in some manner inappropriately adjust the = privileges > allowed by the device within that system. >=20 > (2) Section 1 says about privacy =E2=80=9CNote that long-term stable = unique > identifiers are problematic for privacy reasons and should be used > with care or avoided as described in [RFC7721].=E2=80=9D Given the = later > guidance that =E2=80=9CThe DEV URN type SHOULD only be used for = persistent > identifiers=E2=80=9D, I think the =E2=80=9Cor avoided=E2=80=9D portion = of that sentence is > inappropriate for this document. >=20 > (3) Section 5 begins with =E2=80=9CThe following three examples = provide > examples of MAC-based, 1-Wire, and Cryptographic identifiers=E2=80=9D. = There=20 > are now more than three examples provided (thanks for that!), and=20 > it appears that cryptographic identifiers have ben removed in an > earlier draft. >=20 >=20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Mon Jan 4 06:10: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 ACCFB3A0D6A; Mon, 4 Jan 2021 06:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 4hhBsqqMMv6S; Mon, 4 Jan 2021 06:10:36 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04DAA3A0D69; Mon, 4 Jan 2021 06:10:32 -0800 (PST) Received: from [192.168.217.118] (p548dc939.dip0.t-ipconnect.de [84.141.201.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4D8cwQ2mHWzyrT; Mon, 4 Jan 2021 15:10:30 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Mon, 4 Jan 2021 15:10:30 +0100 Cc: Brian Weis , Last Call , draft-ietf-core-dev-urn.all@ietf.org, "core@ietf.org WG (core@ietf.org)" , secdir@ietf.org X-Mao-Original-Outgoing-Id: 631462229.9462039-8f8dc25ce089c46f5d6667f713835f73 Content-Transfer-Encoding: quoted-printable Message-Id: References: <160702546541.14061.15940689920006174458@ietfa.amsl.com> To: Jari Arkko X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-core-dev-urn-08 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 Jan 2021 14:10:39 -0000 On 2021-01-04, at 14:48, Jari Arkko wrote: >=20 > = https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--08.diff.html So you can=E2=80=99t have a number zero? Might be worth calling out alongside the fact that there are no leading = zeroes. (=46rom a maintainability POV, calling positive-only numbers = =E2=80=9Cnumber=E2=80=9D in the ABNF is a trap waiting for the next = extension. These are all PENs, no?) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jan 4 07:52:53 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 1939E3A0EB3; Mon, 4 Jan 2021 07:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 PZuQP1Lsmx3P; Mon, 4 Jan 2021 07:52:36 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2093.outbound.protection.outlook.com [40.107.243.93]) (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 83A123A0E6E; Mon, 4 Jan 2021 07:52:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bb3LnETjldsOiQZxAzf/4FwGPKwfs6/Pmg2OFi3O00ESMmXv4jA88SIGGAx/OT7slEHkSXMWAi1u0sqLzD/bBH8wJjVKKuZkLEGqMeKTAGfZefm5RNZQs0T3Nq7/mbNk9nfRi1xAWNPqI0FX8YaDzz4m22WPj4lM0pZ4qBwpTY6Ezscw1zWZQcWLdUszHGDKnIkNjS+Rby5y4V5qr7bcTOzap1RceunirPS7qiyLh2xhg4NSiKSDDuuCHoM+uaLaYhaMDKNfINdutxjAWhVMlZO9nb6+dTP5yfx3RctiLbtb+zoZQDgPQ2h2m2QLBqQkDNZRNhUoUe5ZoCCtDXM+Tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5s5qC/lVzXt45VEyVqnpRRPEzgiX4mQV/Oz5v4s4vK8=; b=TxAfDcUK9VecvFxCQX1hTxnOyOCgRwcQbagBRp5/uRvhi/DOKCWf1c9e0JyD5idMO9zrGOeqOnh6mwx2lJ2fzYGk+Vq+1fMUzLM7hVuCg+DTz+Pxs35TFi1pIPafIuXoTmpQip/nslv4QLvTPAd0CCdW7t7dK/n/0Ha1XArSNcfWrGmqobUXoC3/kigxGbcG8h6ZWKrYiNBWv+AYzuPxYeoOuZDJ15NkaeN/UeqSweppFlazCCtoXnykCo/V2nMfWiIKCI+a6hPzLyQTk3nAxaUkyJZuw9S3CEiLNMAAd0PhTQNUhGUPZoMhQB6dtS9CGEyYFd8QieJTXjxt8T5Bcw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.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=5s5qC/lVzXt45VEyVqnpRRPEzgiX4mQV/Oz5v4s4vK8=; b=ijGXQmNaOWxyDvZ5cySpp98/L39zjSOpyFuhwrp0TU9oe6dQMZqjocUTM5nGqK8p+9rV9P7l4fTazx+zD4srVrLY1hvdggM3fo8kfT8PzTrEoSCY2V/1GHAqjFg13o6twTbosl/fnfhrtPuHcqOR7DZ/OWvF6q8rbwCiWnHJRq4= Received: from MWHPR08MB3520.namprd08.prod.outlook.com (2603:10b6:301:61::15) by CO1PR08MB6595.namprd08.prod.outlook.com (2603:10b6:303:9f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.23; Mon, 4 Jan 2021 15:52:31 +0000 Received: from MWHPR08MB3520.namprd08.prod.outlook.com ([fe80::357c:9caf:ff2c:544e]) by MWHPR08MB3520.namprd08.prod.outlook.com ([fe80::357c:9caf:ff2c:544e%6]) with mapi id 15.20.3721.024; Mon, 4 Jan 2021 15:52:31 +0000 From: "Rabadan, Jorge (Nokia - US/Mountain View)" To: Russ Housley , "secdir@ietf.org" CC: "bess@ietf.org" , "draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-09 Thread-Index: AQHWzX4XRwsvPeXUXkaZZzXEpHZkSqoXv1GU Date: Mon, 4 Jan 2021 15:52:31 +0000 Message-ID: References: <160744443645.5849.4437345323739394566@ietfa.amsl.com> In-Reply-To: <160744443645.5849.4437345323739394566@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [96.88.75.205] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3b74ef02-0995-48ad-2510-08d8b0c8bed0 x-ms-traffictypediagnostic: CO1PR08MB6595: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +dIE8Jdc6wbjg3WSWsDoktBE5oDT7Nd4WCzZgkZVaLjoOTa5Jpd2qsB3VJCAlcKE3Sqpd3JSFrM5fooPdpM21xXeLg38CuDhh7BDnmUWIvYnt+jCfvRypw6pcAwQbCri4t8l/r+mYnTjhIjss1kcfBC5BdJlLNQjV9jtBL7teVFLWgHKsZiNNzMNt7ky0ZfMTemk9vNI8doLgqnoqPLM3k6hj9gad4EU+SHXZ1UsqasHUfQqMfJ7a+UpnZMlZHSkB9F2w2cruNt6GO4M/7l6iMB1uFfMbeDqFp2XOx6ybqZUAE3pgxT/3VOnbjQYvU8Jp47eBThAQuKRnssTlMOI61MTxrK3rDxuzsI96VcAGKvIGTZX40i6AndyJRKZtr3UQO5XLGhJ4hqr3pR5KHT4pQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR08MB3520.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(366004)(136003)(376002)(39860400002)(86362001)(8676002)(91956017)(66946007)(76116006)(64756008)(66446008)(66556008)(66476007)(478600001)(5660300002)(7696005)(26005)(186003)(9686003)(53546011)(9326002)(55016002)(316002)(83380400001)(6506007)(110136005)(4326008)(33656002)(54906003)(71200400001)(2906002)(8936002)(4001150100001)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?Bdp7J0+X5iExXT2cdRPE0oqbgEM3iKDIow7rR8SrePCdWo8G3eNttGmZzqia?= =?us-ascii?Q?jWJJ3WwdQ0csxreOIo9Ad2ctPO+8dcWZ8vxC524diD3Batu/rBVoa7EygN1T?= =?us-ascii?Q?doParTakAvHgns8PbLiRaVMmkQdJgkIXwNeGFFbqJq/m5Jp76EPV3T3z793J?= =?us-ascii?Q?U2LeZQMBBejkSklAgIQz/+Y5jFKKIMrS5MaLRWeoGFKTBYAOHV8u8FJLHKVe?= =?us-ascii?Q?BNXdaiykuAATVhiTIokCeqwR1WlfFPL2+42de2W83yjayIToNqDrcxcgV/QX?= =?us-ascii?Q?ODt4tgy3U7CrjrVmsMGx4ISUsQ9JJ2V47Ig87spFfQBVsFrrDHUhT/2L/19O?= =?us-ascii?Q?gbLP9Mbw3FhbWZ/42tqbs/bQsdcWmD/FPDrVMbz5lmZJ6caBMHVlJxM6ZOYl?= =?us-ascii?Q?//CR2LSuINIjFqhJRcXNZlXxLI1W/GXqQxRCDHPTE+dG+t+XGZqXNSwosY8S?= =?us-ascii?Q?1wm0S+LzhfA3tTHR4cbKKItNv39Xcdw1tslixfTZJXEBKWCvhGVuTJP0X/Eg?= =?us-ascii?Q?jkWf+49s3YnXaiSwxCHioxsJZg/ldDRY59LyJj8FYPg6iJgLzXbSe1DsH3Ml?= =?us-ascii?Q?Kvub9IRa5ZufDU14n178+aLYnj5Nx3E55Lg42qo/O/5aMBKvZA8k2uWDfxQ8?= =?us-ascii?Q?EXoxbiPeDSg8ZNPJcORSzplnWgvkgzTzAINfoCD8DyVRrjlrnc+3jNhyYovE?= =?us-ascii?Q?pFLL4GgX7ZaSs8MieHTWExWbTbOYft/CTblI8tKGucYE3TbV310EVEkM0T+R?= =?us-ascii?Q?zwdRtZCo3/lh79MxbIBBrPncFWCVh8WBWPmOsMuFSAloUucbjuhBJQ9uWkjy?= =?us-ascii?Q?baCUMj2ZQyJ0iiupPz458GGPlbtrWzAkwWnusJY2WbUkJlCQH0ka017OEjDe?= =?us-ascii?Q?bsxI246Eb4xx7DOgBA7NW2LYPgLLuyml33s63qJBOWLQz5HSLYAfwJLYHlmM?= =?us-ascii?Q?c06DiRiP2U+0aY1G3KnRJkppOWQibInhoUZFixs6zAwxvGdw+GaTQYg15Wk6?= =?us-ascii?Q?ZWdC?= Content-Type: multipart/alternative; boundary="_000_MWHPR08MB3520690D353D67440E72958AF7D20MWHPR08MB3520namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR08MB3520.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3b74ef02-0995-48ad-2510-08d8b0c8bed0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2021 15:52:31.3415 (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: 7KPMNnsSQKNGv/V+ezDdsE6/NUKUxviCHXbmtRykZk6cQ4vCLIMLEWx9ePqZdrgdGnRn5+Ag7P1jlL+94a/BnQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR08MB6595 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-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: Mon, 04 Jan 2021 15:52:44 -0000 --_000_MWHPR08MB3520690D353D67440E72958AF7D20MWHPR08MB3520namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Russ, The references to SEND are not needed. It was just an example. Since it is not appropriate, I removed the references to RFC 3971. I also addressed your other editorial comments in the other email. Thank you very much! Jorge From: Russ Housley via Datatracker Date: Tuesday, December 8, 2020 at 11:20 AM To: secdir@ietf.org Cc: bess@ietf.org , draft-ietf-bess-evpn-proxy-arp-nd.all@ie= tf.org , last-call@ietf.org= Subject: Secdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-09 Reviewer: Russ Housley Review result: Has Issues I 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 authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-bess-evpn-proxy-arp-nd-09 Reviewer: Russ Housley Review Date: 2020-12-08 IETF LC End Date: 2020-12-15 IESG Telechat date: unknown Summary: Has Issues Major Concerns: I worry about the reference to SEND (RFC 3971). The SEND protocol only supports digital signatures using RSA with SHA-1. While this still might be adequate for the time scales associated with ND, the 80-bit security offered by SHA-1 is not considered adequate for digital signatures in general. Is the reference to SEND really needed in this document? Minor Concerns: None Nits: The Gen-ART review by me includes some editorial suggestions. --_000_MWHPR08MB3520690D353D67440E72958AF7D20MWHPR08MB3520namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Russ,

 

The references to SEND are not needed. It was just an example.=

Since it is not appropriate, I removed the references to RFC 3971.

 

I also addressed your other editorial comments in the other email.

Thank you very much!

Jorge

 

 

From: Russ Housley via Datatracker <noreply= @ietf.org>
Date: Tuesday, December 8, 2020 at 11:20 AM
To: secdir@ietf.org <secdir@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>, draft-ietf-bess-evpn-proxy-= arp-nd.all@ietf.org <draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org>,= last-call@ietf.org <last-call@ietf.org>
Subject: Secdir last call review of draft-ietf-bess-evpn-proxy-arp-n= d-09

Reviewer: Russ Housley
Review result: Has Issues

I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG.  Thes= e
comments were written primarily for the benefit of the Security Area
Directors.  Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-bess-evpn-proxy-arp-nd-09
Reviewer: Russ Housley
Review Date: 2020-12-08
IETF LC End Date: 2020-12-15
IESG Telechat date: unknown

Summary: Has Issues


Major Concerns:  I worry about the reference to SEND (RFC 3971). = The
  SEND protocol only supports digital signatures using RSA with SHA-1.=
  While this still might be adequate for the time scales associated   with ND, the 80-bit security offered by SHA-1 is not considered
  adequate for digital signatures in general.  Is the reference t= o
  SEND really needed in this document?


Minor Concerns:  None


Nits:  The Gen-ART review by me includes some editorial suggestions.

--_000_MWHPR08MB3520690D353D67440E72958AF7D20MWHPR08MB3520namp_-- From nobody Tue Jan 5 01:02:36 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 204C33A10F5; Tue, 5 Jan 2021 01:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPen2S6k6oly; Tue, 5 Jan 2021 01:02:24 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 32AFF3A10B1; Tue, 5 Jan 2021 01:02:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 492306601EB; Tue, 5 Jan 2021 11:02:20 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta2NE9S--4Py; Tue, 5 Jan 2021 11:02:19 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 407DA66012A; Tue, 5 Jan 2021 11:02:19 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Tue, 5 Jan 2021 11:02:18 +0200 Cc: secdir@ietf.org, Last Call , draft-ietf-core-dev-urn.all@ietf.org, "core@ietf.org WG (core@ietf.org)" , Brian Weis Content-Transfer-Encoding: 7bit Message-Id: References: <160702546541.14061.15940689920006174458@ietfa.amsl.com> To: Carsten Bormann X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-core-dev-urn-08 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, 05 Jan 2021 09:02:28 -0000 Thanks Carsten. Will change it. Jari From nobody Tue Jan 5 01:45: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 9AD043A08B0; Tue, 5 Jan 2021 01:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 LBPSIvfS25-S; Tue, 5 Jan 2021 01:45:17 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB4F3A08AE; Tue, 5 Jan 2021 01:45:16 -0800 (PST) Received: from [192.168.217.118] (p548dc939.dip0.t-ipconnect.de [84.141.201.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4D96zt2kLqzydr; Tue, 5 Jan 2021 10:45:14 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Tue, 5 Jan 2021 10:45:13 +0100 Cc: Last Call , draft-ietf-core-dev-urn.all@ietf.org, Brian Weis , "core@ietf.org WG (core@ietf.org)" , secdir@ietf.org X-Mao-Original-Outgoing-Id: 631532712.975024-90f5b59b5fd1c4bfa4ad14dccfb4685d Content-Transfer-Encoding: quoted-printable Message-Id: <5B3A8129-2880-42CE-BB83-01F7F10A3DD5@tzi.org> References: <160702546541.14061.15940689920006174458@ietfa.amsl.com> To: Jari Arkko X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-core-dev-urn-08 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, 05 Jan 2021 09:45:21 -0000 On 2021-01-05, at 10:02, Jari Arkko wrote: >=20 > Thanks Carsten. Will change it. Thanks =E2=80=94 -09 looks good! (Inconsequential typo in Appendix A, though: s/ABN/ABNF/) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jan 5 05:08: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 A01963A0C70 for ; Tue, 5 Jan 2021 05:08:28 -0800 (PST) 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.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <160985210863.16943.17689381323081979054@ietfa.amsl.com> Date: Tue, 05 Jan 2021 05:08:28 -0800 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: Tue, 05 Jan 2021 13:08:29 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2021-01-07 Reviewer LC end Draft Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer-06 Tirumaleswar Reddy.K 2020-11-16 draft-ietf-quic-transport-33 Last calls: Reviewer LC end Draft Daniel Franke 2020-09-18 draft-ietf-jmap-mdn-16 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-11 Daniel Gillmor 2020-09-30 draft-ietf-ccamp-layer0-types-09 Phillip Hallam-Baker 2020-12-03 draft-ietf-tls-ticketrequests-07 Phillip Hallam-Baker 2020-09-30 draft-ietf-lwig-tcp-constrained-node-networks-13 Steve Hanna 2020-09-30 draft-ietf-ccamp-wson-yang-28 Dan Harkins None draft-ietf-rtgwg-policy-model-03 Leif Johansson None draft-ietf-netconf-crypto-types-18 Leif Johansson 2020-10-02 draft-ietf-lpwan-schc-over-lorawan-13 Watson Ladd None draft-ietf-rift-applicability-03 Russ Mundy 2020-07-20 draft-ietf-ace-dtls-authorize-14 Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer-06 Tirumaleswar Reddy.K 2020-11-16 draft-ietf-quic-transport-33 Rich Salz R2020-08-14 draft-ietf-suit-architecture-14 Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag-11 Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth-09 Christopher Wood R2021-01-18 draft-ietf-dtn-tcpclv4-24 Christopher Wood 2020-09-23 draft-ietf-6man-rfc4941bis-12 Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model-14 Liang Xia 2020-11-30 draft-ietf-spring-sr-yang-29 Early review requests: Reviewer Due Draft Dacheng Zhang 2020-12-07 draft-ietf-idr-eag-distribution-13 Next in the reviewer rotation: Chris Lonvick Aanchal Malhotra David Mandelberg Catherine Meadows Alexey Melnikov Daniel Migault Adam Montville Kathleen Moriarty Russ Mundy Sandra Murphy From nobody Tue Jan 5 08:19:01 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 970303A0E4C; Tue, 5 Jan 2021 08:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ZGXJMUe9vHVf; Tue, 5 Jan 2021 08:18:53 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD7D3A0E93; Tue, 5 Jan 2021 08:18:53 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4D9Hk35r3Qz5vk6; Tue, 5 Jan 2021 17:18:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1609863531; bh=VWy6K37PMYlzI+5yhvgmWfL1WRNtn20t3LIBTIvBEb4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=mT/T20JSyu5CfZ8daAxfAQkY/rqAXUc9rIIHmKYbyQ1x6ekrb9R5pShWbn5W1kg65 hhAqE5ce9X4lzD2D1Z4TwTCjG1JEFDEo8q3xjuXneilYbgtcECEhkDVC8RtJ6R8aQz 0ooBx6cTI2c6uUtpm3P994wbsgQSB6eBXRDHN6IW2r0GWvR+7Hx47YnyH3fgCnCLeZ oFbCMyzAFKIF+qpP8R/deK959N0U1lmF5P/J/WxRl3VDeM9gahcaY5QN6y7YSX+a3Z b5/6Kwg7efs7KnvsvGx51Ql4GFHGlwWtgteFUVLjRiv4yFgfCDieIzBKPK0z+uULXJ 2tv6Vd511r8Pw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 4D9Hk34jk9zCqkf; Tue, 5 Jan 2021 17:18:51 +0100 (CET) From: To: Steve Hanna , "secdir@ietf.org" CC: "draft-ietf-sfc-nsh-integrity.all@ietf.org" , "sfc@ietf.org" Thread-Topic: Secdir early review of draft-ietf-sfc-nsh-integrity-01 Thread-Index: AQHW2iGfyZergZl9c0m+HEhLWQWzAqoZEuiA Date: Tue, 5 Jan 2021 16:18:51 +0000 Message-ID: <32489_1609863531_5FF4916B_32489_106_1_787AE7BB302AE849A7480A190F8B9330315A77C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160883409674.11984.2680388131154961282@ietfa.amsl.com> In-Reply-To: <160883409674.11984.2680388131154961282@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: 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 early review of draft-ietf-sfc-nsh-integrity-01 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, 05 Jan 2021 16:18:56 -0000 SGkgU3RldmUsIA0KDQpNYW55IHRoYW5rcyBmb3IgdGhlIHJldmlldy4NCg0KUGxlYXNlIHNlZSBp bmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N Cj4gRGXCoDogU3RldmUgSGFubmEgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRm Lm9yZ10NCj4gRW52b3nDqcKgOiBqZXVkaSAyNCBkw6ljZW1icmUgMjAyMCAxOToyMg0KPiDDgMKg OiBzZWNkaXJAaWV0Zi5vcmcNCj4gQ2PCoDogZHJhZnQtaWV0Zi1zZmMtbnNoLWludGVncml0eS5h bGxAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZw0KPiBPYmpldMKgOiBTZWNkaXIgZWFybHkgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtc2ZjLW5zaC1pbnRlZ3JpdHktMDENCj4gDQo+IFJldmlld2VyOiBTdGV2 ZSBIYW5uYQ0KPiBSZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVzDQo+IA0KPiBJIGhhdmUgcmV2aWV3 ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzDQo+ IG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vz c2VkIGJ5IHRoZQ0KPiBJRVNHLiAgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmls eSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlDQo+IHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLg0KPiAg RG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50 cyBqdXN0DQo+IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4gDQo+IFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIGFkZHMgaW50ZWdyaXR5IGFuZCBvcHRpb25hbCBlbmNyeXB0aW9u IG9mDQo+IHNlbnNpdGl2ZSBtZXRhZGF0YSBkaXJlY3RseSB0byB0aGUgTmV0d29yayBTZXJ2aWNl IEhlYWRlciAoTlNIKQ0KPiBwcm90b2NvbCBkZWZpbmVkIGluIFJGQyA4MzAwLCB0aHVzIHJlZHVj aW5nIG9yIGVsaW1pbmF0aW5nIHNldmVyYWwNCj4gYXR0YWNrIHZlY3RvcnMgYWdhaW5zdCBTZXJ2 aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpLiBUaGUgZG9jdW1lbnQNCj4gaXMgd2VsbCB3cml0 dGVuIGFuZCBzZWVtcyBhZGVxdWF0ZSBmb3IgdGhlIGdvYWxzIGFydGljdWxhdGVkIGhlcmUNCj4g YW5kIGVsc2V3aGVyZSBpbiB0aGUgU0ZDIGRvY3VtZW50IHN1aXRlLg0KDQpbTWVkXSBUaGFua3Mu IA0KDQogSG93ZXZlciwgSSBoYXZlIHNvbWUNCj4gaXNzdWVzLCBxdWVzdGlvbnMsIGFuZCBuaXRz Lg0KDQpbTWVkXSBUaGlzIHdhcyBleGFjdGx5IHdoYXQgd2Ugd2VyZSBsb29raW5nIGZvciEgVGhh bmtzLiANCg0KPiANCj4gTm90ZSB0aGF0IEkgaGF2ZSBub3QgcHJldmlvdXNseSB3b3JrZWQgd2l0 aCBTRkMuIEluIHRoZSBsYXN0IGZldw0KPiBkYXlzLCBJIGhhdmUgcmVhZCB0aGUgZG9jdW1lbnRz IG9uIHRoaXMgZG9jdW1lbnQgc28gSSBhbSBmYWlybHkNCj4gY29uZmlkZW50IHRoYXQgSSB1bmRl cnN0YW5kIHRoZSByZWxldmFudCBzZWN1cml0eSBhc3BlY3RzLg0KPiANCj4gSVNTVUVTIGFuZCBR VUVTVElPTlM6DQo+IFdoeSBpbmNsdWRlIGEgTVVTVCBpbiBzZWN0aW9uIDkuMj8gSXNuJ3QgdGhh dCBhbHJlYWR5IGNvdmVyZWQNCj4gZWFybGllciAoaW4gdGhlIGxhc3Qgc2VudGVuY2Ugb2Ygc2Vj dGlvbiA3LjUpPw0KDQpbTWVkXSBGYWlyIHBvaW50LiBXaWxsIHJld29yZCB0byBhdm9pZCByZWR1 bmRhbnQgdXNlIG9mIG5vcm1hdGl2ZSBsYW5ndWFnZS4gDQoNCj4gDQo+IFRoZSBUaW1lc3RhbXAg ZmllbGQgaXMgc3VwcG9zZWQgdG8gaGFuZGxlIHJlcGxheSBhdHRhY2tzLiBIb3dldmVyLA0KPiB0 aGlzIHBlcm1pdHMgdW5saW1pdGVkIHJlcGxheXMgd2l0aGluIHRoZSBEZWx0YSBpbnRlcnZhbC4g SXMgdGhhdA0KPiBhY2NlcHRhYmxlPw0KDQpbTWVkXSBUaGlzIGlzIGEgZGlzY3Vzc2lvbiB3ZSBo YWQgYW1vbmcgdGhlIGF1dGhvcnMgYW5kIHdlIGJlbGlldmUgdGhhdCAyIHNlY29uZHMgaXMgYWNj ZXB0YWJsZSBlc3BlY2lhbGx5IHRoYXQgdGhlIHRpbWVzdGFtcCBpcyBzZXQgYnkgdGhlIGNsYXNz aWZpZXIgYW5kIGtlcHQgYWxvbmcgYW4gY2hhaW4gKGV4Y2VwdCwgaWYgcmVjbGFzc2lmaWNhdGlv biBoYXBwZW5zKS4gVGhhdCB2YWx1ZSBjYW4gYmUgZGVjcmVhc2VkIGlmIHJlcXVpcmVkIGFzIGEg ZnVuY3Rpb24gb2YgYSBsb2NhbCBkZXBsb3ltZW50Lg0KDQpGV1ksIHdlIGNvbnNpZGVyZWQgdGhl IHVzZSBvZiBzZXF1ZW5jZSBudW1iZXJzIGluIHRoZSAtMDAgYnV0IGFiYW5kb25lZCB0aGF0IGRl c2lnbiBiZWNhdXNlIHNvbWUgU0YgaW5zdGFuY2VzIG1heSBub3QgcmVjZWl2ZSBhbGwgdGhlIHBh Y2tldHMgb2YgYSBnaXZlbiBmbG93LiBUaGF0IGlzIHR5cGljYWxseSB0aGUgY2FzZSBvZiBsb2Fk LWJhbGFuY2luZyBvciB0aGUgc28tY2FsbGVkIFNGQyBPZmZsb2Fkcy4gDQoNCj4gDQo+IFdoYXQg aXMgdGhlID8gb3BlcmF0b3IgaW4gc2VjdGlvbiA3LjQgc3VwcG9zZWQgdG8gY29ubm90ZT8NCj4g U3VidHJhY3Rpb24gc2VlbXMgbGlrZSBhIGJldHRlciBjaG9pY2UuDQoNCltNZWRdIFdlIGFyZSBj YWxjdWxhdGluZyB0aGUgZGlmZiBiZXR3ZWVuIFRTIGFuZCBUU3J0LiBXaWxsIGNsYXJpZnkgaW4g dGhlIG5leHQgaXRlcmF0aW9uLiANCg0KPiANCj4gSXMgdGhlIFRpbWVzdGFtcCBmaWVsZCBvbmx5 IHNldCBieSB0aGUgZmlyc3QgaW1wb3NlciBpbiB0aGUgU0ZQIG9yDQo+IHNob3VsZCBpdCBiZSB1 cGRhdGVkIHdoZW5ldmVyIGFuIGltcG9zZXIgY2hhbmdlcyB0aGUgTUFDPyBUaGlzDQo+IHNob3Vs ZCBiZSBkb2N1bWVudGVkIHNvbWV3aGVyZSwgbWF5YmUgaW4gc2VjdGlvbiA3LjQuDQoNCltNZWRd IFRoZSB0aW1lc3RhbXAgaXMgbGVmdCB1bnRvdWNoZWQgYXMgbG9uZyBhIHBhY2tldCBwcm9ncmVz c2VzIGluIGEgc2VydmljZSBwYXRoLiBJdCB3aWxsIGJlIHVwZGF0ZWQgd2hlbiB3ZSBkbyByZWNs YXNzaWZpY2F0aW9uLCB0aG91Z2guIFdpbGwgYWRkIHRleHQgdG8gbWFrZSB0aGlzIGNsZWFyLiAN Cg0KPiANCj4gVGhlIHRocmVhdCBtb2RlbCBkZXNjcmliZWQgaW4gZHJhZnQtYXJra28tZmFycmVs bC1hcmNoLW1vZGVsLXQtMDQNCj4gaW5jbHVkZXMgY29tcHJvbWlzZWQgbm9kZXMuIFRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mDQo+IHRoaXMgZG9jdW1lbnQgc2hvdWxkIGRl c2NyaWJlIGhvdyBhbmQgdG8gd2hhdCBleHRlbnQgY29tcHJvbWlzZWQNCj4gbm9kZXMgYXJlIGhh bmRsZWQgYnkgdGhlIHByb3RlY3Rpb25zIHByb3ZpZGVkIGJ5IHRoaXMgZG9jdW1lbnQgYW5kDQo+ IHdoYXQgcmVzaWR1YWwgcmlza3MgcmVtYWluLg0KDQpbTWVkXSBBIGNvbXByb21pc2VkIGVudGl0 eSBjYW4gZHJvcCBwYWNrZXRzIG9yIGJ5cGFzcyBhbiBTRiBpcyBkaXNjdXNzZWQgaW4gdGhlIGRy YWZ0OiAgIA0KDQogICBUaGUgYXR0YWNrcyBkaXNjdXNzZWQgaW4gW0ktRC5uZ3V5ZW4tc2ZjLXNl Y3VyaXR5LWFyY2hpdGVjdHVyZV0gYXJlDQogICBoYW5kbGVkIG93aW5nIHRvIHRoZSBzb2x1dGlv biBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCwgZXhjZXB0IGZvcg0KICAgYXR0YWNrcyBkcm9w cGluZyBwYWNrZXRzLiAgU3VjaCBhdHRhY2tzIGNhbiBiZSBkZXRlY3RlZCByZWx5aW5nIHVwb24N CiAgIHN0YXRpc3RpY2FsIGFuYWx5c2lzOyBzdWNoIGFuYWx5c2lzIGlzIG91dCBvZiBzY29wZSBv ZiB0aGlzIGRvY3VtZW50Lg0KICAgQWxzbywgaWYgU0ZGcyBhcmUgbm90IGludm9sdmVkIGluIHRo ZSBpbnRlZ3JpdHkgY2hlY2tzLCBhIG1pc2JlaGF2aW5nDQogICBTRkYgd2hpY2ggZGVjcmVtZW50 cyBTSSB3aGlsZSB0aGlzIHNob3VsZCBiZSBkb25lIGJ5IGFuIFNGIChTRiBieXBhc3MNCiAgIGF0 dGFjaykgd2lsbCBiZSBkZXRlY3RlZCBieSBhbiB1cHN0cmVhbSBTRiBiZWNhdXNlIHRoZSBpbnRl Z3JpdHkNCiAgIGNoZWNrIHdpbGwgZmFpbC4NCg0KT3RoZXIgZGFtYWdlIG1heSBiZSBpbmR1Y2Vk IGJ5IGNvbXByb21pc2VkIGRldmljZXMuIFdpbGwgc2VlIHdoYXQgd2UgY2FuIGFkZCBtb3JlLiAg DQoNCj4gDQo+IFRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHNob3VsZCBleHBs aWNpdGx5IGFja25vd2xlZGdlDQo+IHRoYXQgYXV0aGVudGljYXRpb24gaXMgbm90IHByb3ZpZGVk IGJ5IHRoaXMgbWV0aG9kLg0KPiANCj4gV2hhdCBkb2VzIHRoaXMgc3RhdGVtZW50IG1lYW4/DQo+ ICAgICAgICAg4oCiIElmIEhNQUMgYWxnb3JpdGhtIGlzIHVzZWQsIElWIGxlbmd0aCBpcyBzZXQg dG8gemVyby4NCj4gRG9uJ3QgYWxsIHRoZSBjdXJyZW50IGFsZ29yaXRobXMgdXNlIEhNQUM/DQo+ IA0KDQpbTWVkXSBBY3R1YWxseSB3ZSB3YW50ZWQgdG8gcmVmZXIgdG8gdGhpcyBtb2RlOiANCg0K ICAgbyAgSWYgdGhlIENvbnRleHQgSGVhZGVycyBhcmUgbm90IGVuY3J5cHRlZCwgdGhlIEhhc2hl ZCBNZXNzYWdlDQogICAgICBBdXRoZW50aWNhdGlvbiBNb2RlIChITUFDKSBhbGdvcml0aG0gZGlz Y3Vzc2VkIGluIFtSRkM0ODY4XSBpcw0KICAgICAgdXNlZCB0byBpbnRlZ3JpdHkgcHJvdGVjdCB0 aGUgTlNIIGRhdGEuDQoNCj4gV2hhdCBpcyB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IgaWYgdGhlc2Ug Q29udGV4dCBIZWFkZXJzIGFyZSBtaXNzaW5nPw0KPiBUaGUgbGFzdCBwYXJhZ3JhcGggYXQgdGhl IGJvdHRvbSBvZiBwYWdlIDE4IHNlZW1zIHRvIGJlIGFtYmlndW91cyBvbg0KPiB0aGlzIHRvcGlj LCB3aXRoIHRoZSBmaXJzdCBzZW50ZW5jZSBzYXlpbmcgdGhhdCB0aGlzICJTSE9VTEQgYmUNCj4g bG9nZ2VkIGxvY2FsbHkiIA0KDQpbTWVkXSBUaGF0IG9uZSBpcyBmcm9tIHRoZSBwZXJzcGVjdGl2 ZSBvZiB0aGUgZW50aXR5IChlLmcuLCBjbGFzc2lmaWVyKSB0aGF0IGZhaWxzIHRvIGluamVjdCB0 aGUgaGVhZGVyIGF0IHRoZSBmaXJzdCBwbGFjZS4gDQoNCndoaWxlIHRoZSBsYXN0IHNlbnRlbmNl IHNheXMgdGhhdCB0aGlzICJNVVNUIGNhdXNlDQo+IHRoYXQgcGFja2V0IHRvIGJlIGRpc2NhcmRl ZCIuDQoNCltNZWRdIFRoaXMgb25lIGlzIHRoZSBiZWhhdmlvciBmb3Igb24tcGF0aCBlbnRpdGll cy4gDQoNCiBQcm9iYWJseSB0aGlzIGlzIGNsZWFyIHRvIHRoZSB3cml0ZXINCj4gYnV0IG5vdCB0 byB0aGlzIHJlYWRlciENCg0KW01lZF0gUG9pbnQgdGFrZW4uIFdpbGwgcmV3b3JkLiANCg0KPiAN Cj4gTklUUzoNCg0KW01lZF0gQWxsIGdvb2QgcG9pbnRzLiBXaWxsIGJlIGZpeGVkLiBUaGFua3Mu IA0KDQo+IEF0IHRoZSB0b3Agb2YgcGFnZSA2LCAidW5lY3J5cHRlZCIgc2hvdWxkIGJlICJ1bmVu Y3J5cHRlZCIuDQo+IA0KPiBJbiB0aGUgbGFzdCBsaW5lIG9mIHBhZ2UgMTgsICJkZXBlbmQiIHNo b3VsZCBiZSAiZGVwZW5kaW5nIi4NCj4gDQo+IEp1c3QgYmVsb3cgRmlndXJlIDkgb24gcGFnZSAy MCwgYSBjb21tYSBpcyBuZWVkZWQgYWZ0ZXIgImRvaW5nIHNvIi4NCj4gDQo+IEluIHRoZSBzZWNv bmQgcGFyYWdyYXBoIG9mIHNlY3Rpb24gNy41LCAic3VjY2Vzc2Z1bHkiIHNob3VsZCBiZQ0KPiBz cGVsbGVkICJzdWNjZXNzZnVsbHkiLg0KPiANCj4gQXQgdGhlIGVuZCBvZiB0aGUgZmlyc3QgcGFy YWdyYXBoIG9mIHNlY3Rpb24gOSwgY2hhbmdlIHRoZSBzZW50ZW5jZQ0KPiBmcm9tOg0KPiAgICAg ICAgIOKAoiBBbHNvLCB0aGF0IHNlY3Rpb24gaW5kaWNhdGVzIHRoYXQgbWV0YWRhdGEgY29uc2lk ZXJhdGlvbnMNCj4gdGhhdA0KPiAgICAgICAgIG9wZXJhdG9ycyBjYW4gdGFrZSBpbnRvIGFjY291 bnQgd2hlbiB1c2luZyBOU0ggYXJlIGRpc2N1c3NlZA0KPiBpbg0KPiAgICAgICAgIFtSRkM4MTY1 XS4NCj4gdG8NCj4gICAgICAgICDigKIgQWxzbywgdGhhdCBzZWN0aW9uIGluZGljYXRlcyB0aGF0 IFtSRkM4MTY1XSBkaXNjdXNzZXMNCj4gbWV0YWRhdGENCj4gICAgICAgICBjb25zaWRlcmF0aW9u cyB0aGF0IG9wZXJhdG9ycyBjYW4gdGFrZSBpbnRvIGFjY291bnQgd2hlbg0KPiB1c2luZyBOU0gu DQo+IA0KPiBUaGUgbGFzdCBzZW50ZW5jZSBvZiB0aGUgdGhpcmQgcGFyYWdyYXBoIG9mIHNlY3Rp b24gOSByZWNvbW1lbmRzDQo+IHRoYXQgInRoZSBuZXh0IGtleSBpZGVudGlmaWVyIiBiZSBkaXN0 cmlidXRlZCBsb25nIGJlZm9yZSB0aGUga2V5IGlzDQo+IGNoYW5nZWQuIFRoaXMgc2hvdWxkIHNh eSAidGhlIG5leHQga2V5IGlkZW50aWZpZXIgYW5kIGFzc29jaWF0ZWQNCj4ga2V5aW5nIG1hdGVy aWFsIi4NCj4gDQo+IEluIHRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIHNlY3Rpb24gOS4xLCAiZG9t YWluIGJlIGFibGUiIHNob3VsZCBiZQ0KPiAiZG9tYWluIHNob3VsZCBiZSBhYmxlIi4NCj4gDQo+ IA0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFp bnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0 YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3Bv bnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmll LiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl ZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Tue Jan 5 18:42:08 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 7E14F3A0418; Tue, 5 Jan 2021 18:41:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Franke via Datatracker To: Cc: draft-ietf-jmap-mdn.all@ietf.org, jmap@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160990091746.16663.18138161640943053349@ietfa.amsl.com> Reply-To: Daniel Franke Date: Tue, 05 Jan 2021 18:41:57 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-jmap-mdn-16 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, 06 Jan 2021 02:41:58 -0000 Reviewer: Daniel Franke Review result: Ready 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's Security Considerations section is appropriately brief because it doesn't introduce much in the way of new ones: the security model for JMAP MDN isn't essentially different from the security model for the analogous IMAP functionality. But had I reviewed RFC 8098, I would have urged some changes to the Privacy Considerations section of that document. It's not that anything is wrong or overlooked, but its emphasis is odd. It focuses mostly on leakage of impersonal details like OS version and network topology, with nothing but a parenthetical mention given to the significant personal intrusion of monitoring message read times. Every abusive boss knows this trick: send your subordinates an email at 5:00 AM on Saturday and watch when the delivery receipts come in. I wish that something in the corpus of MDN-related RFCs would do a better job of acknowledging this, even if this one in particular is not the most appropriate place for it. From nobody Tue Jan 5 18:57:52 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 5B7713A046B; Tue, 5 Jan 2021 18:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 qO8B3u2XFxlq; Tue, 5 Jan 2021 18:57:46 -0800 (PST) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (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 7F4B33A044A; Tue, 5 Jan 2021 18:57:42 -0800 (PST) Received: by mail-lf1-f49.google.com with SMTP id h205so3396295lfd.5; Tue, 05 Jan 2021 18:57:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/v3fpY9vMZLeAlGjJr13VEJtKXsmWn4fRROoYhd5i/E=; b=SOxMLhiyEIY7ZO1B1K6bI1G03UuqChzmTYxP3EfmrPFC+OvydzwLZGCwizzcJ+1lm6 khXyaoVhEwOy+bT3khLHjIaJmJkPcLHNtuhmT6GtZNjLRfiC7d10tVQyXw5vANpyzige 7MhFLluANLQGJ742a0A0KY4xcPPGvgncznc7wvcYlC8uqHdbMaj7wVqQRvuWyPubzAC5 4narxPubYTj6dkgWb9w9C81n2T3wE+weMIOQFmdZ9UXW6qHbODAqBXASYcnJeZEjHi2c noW626A8j5CqfC8VqP025+orlhcl9PgFtXx1VKdCioRKnIQW/RGi9BZ6mnbVzhpnpBVr 3GGg== X-Gm-Message-State: AOAM530EoTplNx4rXuquxByEtUIkfAISMBvuOB72YdxsZPwAiLZ+pV3y 7h+ls6B9ukZ0Jf3ywW88rfZ6nX4moDHc9VCf5mA= X-Google-Smtp-Source: ABdhPJxpAr6TPWoxzWRKYLFOJb7kucZUGOKayRtuijV9W20bzf2qqU2BbpZIPJ67rGnT1RC9qUI0vsgbEe5jfzQVrWU= X-Received: by 2002:a05:651c:28d:: with SMTP id b13mr1195248ljo.75.1609901860171; Tue, 05 Jan 2021 18:57:40 -0800 (PST) MIME-Version: 1.0 References: <160990091746.16663.18138161640943053349@ietfa.amsl.com> In-Reply-To: <160990091746.16663.18138161640943053349@ietfa.amsl.com> From: Barry Leiba Date: Tue, 5 Jan 2021 21:57:29 -0500 Message-ID: To: Daniel Franke Cc: draft-ietf-jmap-mdn.all@ietf.org, jmap@ietf.org, last-call@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="0000000000007fb36105b8327caa" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-mdn-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: Wed, 06 Jan 2021 02:57:47 -0000 --0000000000007fb36105b8327caa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Daniel, thanks for the review. And yes, MDNs themselves, no matter how they conveyed, are privacy-intrusive. That=E2=80=99s why I have them disab= led in my user agent, and most, if not all standards-compliant MUAs allow that. And that=E2=80=99s not accidental: it actually is written into the MDN spec= , RFC 2298. From Section 2.1: While Internet standards normally do not specify the behavior of user interfaces, it is strongly recommended that the user agent obtain the user's consent before sending an MDN. This consent could be obtained for each message through some sort of prompt or dialog box, or globally through the user's setting of a preference. The user might also indicate globally that MDNs are never to be sent or that a "denied" MDN is always sent in response to a request for an MDN. There=E2=80=99s more there, as well, and I think it covers things reasonabl= e well, even if it doesn=E2=80=99t explain what the threats are. If we should ever= do an update of the MDN spec, we would definitely add that. Barry, ART AD On Tue, Jan 5, 2021 at 9:41 PM Daniel Franke via Datatracker < noreply@ietf.org> wrote: > Reviewer: Daniel Franke > Review result: Ready > > 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's Security Considerations section is appropriately brief > because > it doesn't introduce much in the way of new ones: the security model for > JMAP > MDN isn't essentially different from the security model for the analogous > IMAP > functionality. But had I reviewed RFC 8098, I would have urged some > changes to > the Privacy Considerations section of that document. It's not that > anything is > wrong or overlooked, but its emphasis is odd. It focuses mostly on leakag= e > of > impersonal details like OS version and network topology, with nothing but= a > parenthetical mention given to the significant personal intrusion of > monitoring > message read times. Every abusive boss knows this trick: send your > subordinates > an email at 5:00 AM on Saturday and watch when the delivery receipts come > in. I > wish that something in the corpus of MDN-related RFCs would do a better > job of > acknowledging this, even if this one in particular is not the most > appropriate > place for it. > > > --0000000000007fb36105b8327caa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Daniel, thanks for the review.=C2=A0 And yes, MDNs themse= lves, no matter how they conveyed, are privacy-intrusive.=C2=A0 That=E2=80= =99s why I have them disabled in my user agent, and most, if not all standa= rds-compliant MUAs allow that.

And that=E2=80=99s not accidental: it actually is written into the M= DN spec, RFC 2298.=C2=A0 From Section 2.1:

   While Internet standards normally do not specify the behavior of us=
er
   interfaces, it is strongly recommended that the user agent obtain the
   user's consent before sending an MDN.  This consent could be obtaine=
d
   for each message through some sort of prompt or dialog box, or
   globally through the user's setting of a preference.  The user might
   also indicate globally that MDNs are never to be sent or that a
   "denied" MDN is always sent in response to a request for an MD=
N.

There=E2=80=99s more there, as well, and I think it covers th= ings reasonable well, even if it doesn=E2=80=99t explain what the threats a= re.=C2=A0 If we should ever do an update of the MDN spec, we would definite= ly add that.

Barry, ART = AD

On Tue, Jan 5, 2021 at 9:41 PM Daniel Franke via Datatracker <noreply@ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rg= b(204,204,204)">Reviewer: Daniel Franke
Review result: Ready

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.=C2=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chairs should
treat these comments just like any other last call comments.

This document's Security Considerations section is appropriately brief = because
it doesn't introduce much in the way of new ones: the security model fo= r JMAP
MDN isn't essentially different from the security model for the analogo= us IMAP
functionality. But had I reviewed RFC 8098, I would have urged some changes= to
the Privacy Considerations section of that document. It's not that anyt= hing is
wrong or overlooked, but its emphasis is odd. It focuses mostly on leakage = of
impersonal details like OS version and network topology, with nothing but a=
parenthetical mention given to the significant personal intrusion of monito= ring
message read times. Every abusive boss knows this trick: send your subordin= ates
an email at 5:00 AM on Saturday and watch when the delivery receipts come i= n. I
wish that something in the corpus of MDN-related RFCs would do a better job= of
acknowledging this, even if this one in particular is not the most appropri= ate
place for it.


--0000000000007fb36105b8327caa-- From nobody Wed Jan 6 08:14: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 306F53A0FAF; Wed, 6 Jan 2021 08:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=juniper.net header.b=hzoxrfp3; dkim=pass (1024-bit key) header.d=juniper.net header.b=PPDqK13l 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 8_k3Gt7HmVUk; Wed, 6 Jan 2021 08:14:36 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 A1D543A10B0; Wed, 6 Jan 2021 08:14:27 -0800 (PST) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 106FswY6023699; Wed, 6 Jan 2021 08:14:26 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=7AhwIS0kmJsdyjMYs6/vTTQWYjOTPnOiEfd+ivF5j9g=; b=hzoxrfp3AFIj5n784HPdLgeB4R9O11GEwWIX1f0XPUIV2N4QsHHFtjFY6BiuVmHE6GIy S3Rf8aZhiqASXpysmJTSa9JJzsPZ+CRPTE390/hkRQ1oxGzC7aOqZSUU+ZclgDxUk7NQ NSMq9UNnBRHn1L4Uzz9XtFwuZ7om5z2mtwQqyGeCQXP/Nm62QWb941HrBu2h5otphpUv cp7Kcc7jPoC9bt3B78Q/0DNDFGKurVuzmYf4HkW9RbtIxwlBeKDgy2X5frAbZNB+r9ju v+qF7mYqBP6W/xPjlM9D6WiqHfsD8SndsdekIm6jqBTcz9k4g9gvP7dT6ennDwVJL2/I LQ== Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2172.outbound.protection.outlook.com [104.47.57.172]) by mx0a-00273201.pphosted.com with ESMTP id 35vrg12734-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Jan 2021 08:14:26 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hf8cflQg+Zx9I80HlO+Hk5eRkypkw2W5e6ynSu6udzg0LK/YXIbA+AUqz9b3P+75P05/X3vVgiu2m3XAkB9BdNpy+x3Uw/xTjbbkTTv7smKbH4Cl6Dd98Mujc/SOQWx0VY6ol9QjzVocsvK+ZYcMiOY/CU9g1t8Wl8RuT/+UCqk4SDqPkTHMPR15YYr08ZjWo+yPtt8ZdszmVv/cG+iIk6suTHFrEdYTHwKXyYkZiH2zxxZ6QOJRin+AcovcKC319GmgVBR+JRgtXKI8/pXQhonOXQqE7gKlYUwI0XdM+aBH6H9SOjQMaVAObrTor7X+zFeDGtzCdeGXgJg8wZbz8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7AhwIS0kmJsdyjMYs6/vTTQWYjOTPnOiEfd+ivF5j9g=; b=KmyAnp/NBmrakMEM3O0S/c67D88Dmg8DsZ0IMnjlq26PcFNAaSmsUpry9lypWTrC5sFJe7eX6sqhA3yqNiIkgoZDvMbTKzElV9W+I05sk1dybRoJd0m1wRbj9M6144rUydX00hG0Arx7no6RcGhMTOn0RjGlRBUS/af2HfzUSceclEVFrI68R3X5fW7sl6shshII77SoNPROpne990AkE4QTj8nucGitxbz3GgBPFRNb2Th0GkTrwdIZlLFyGwqrs/SIgLBB2MQd8a92phl6UdOyOwYiKUrqEfpuPCz//3EXUQBn6fueF3zFmB1dbo2v0EyV8pwVi8ZF13Eyqu/2DA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7AhwIS0kmJsdyjMYs6/vTTQWYjOTPnOiEfd+ivF5j9g=; b=PPDqK13ln+ip9sCppNAzdR/a76A/UnzdZSSc8DNcO1PT4aEAwZox23mk5l90mxJlbtliLTms0aB+4v4ju/mjaikvrqpZ9T2WD9h4kocAcgjsgsfHAVIHsiItmwWiSwZpCOm3gFic26rw/jAgZV9db8hbS6Qt8Og/BTc8+CuduFA= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6527.namprd05.prod.outlook.com (2603:10b6:208:db::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.2; Wed, 6 Jan 2021 16:14:24 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::f91f:55f3:3130:d318]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::f91f:55f3:3130:d318%5]) with mapi id 15.20.3742.006; Wed, 6 Jan 2021 16:14:24 +0000 From: John Scudder To: Nancy Cam-Winget CC: "secdir@ietf.org" , "draft-ietf-idr-ext-opt-param.all@ietf.org" , "idr@ietf.org" Thread-Topic: Secdir early review of draft-ietf-idr-ext-opt-param-09 Thread-Index: AQHW1NyA2xFUuTL500iSEGlEv8ZZ0qoa5ESA Date: Wed, 6 Jan 2021 16:14:23 +0000 Message-ID: <4DF0A75A-8A23-40BA-AD43-B1B5BF0E29EB@juniper.net> References: <160825465125.21464.15874080718333007730@ietfa.amsl.com> In-Reply-To: <160825465125.21464.15874080718333007730@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.4) authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [162.225.191.192] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 7eb9c454-85b5-4a3b-feaf-08d8b25e2231 x-ms-traffictypediagnostic: MN2PR05MB6527: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JuvGjXLg0L/nYO97gFiwlxLMzgtWk4kiqeG+EUkH7piQO9OtcRn7EEN5rAfia4oyi6rmW8GSlGrzMilKMYSt4o1AjUxCULXXSGD6Pfhht+LJrhsQzCxcFG49r+GB5PMGAGnrQQNaSLK4PLSe3f1soEzMLVwQT8PTWy/KxyYn6RixunihwSBAZyBHRml+TZI2kgOd7SmnQFR8MDHUGOMFSXq952ry7g3fUd/o0H8C0jhNYoS8KJyovpQamKX4gM3+JDy/u7nPOwtSM1PsMKyyzMppI8vpWwjOy+7evML421sRKWwU4ypYXbVO6sceMEFqKmhhD+zHbCTv4rRoerL6JnSlTj/rfUL0DRpgk0QmlRvzn//EB+V1evctdHMrU2RXYnEDqR07u7ZtNOz+9TNSdu+nrn8Kmpduv5YmlWpvXyjmZr9KFb6LAB1QUmzQ+tLi x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(376002)(366004)(39860400002)(136003)(6486002)(4326008)(76116006)(6512007)(71200400001)(64756008)(8936002)(66476007)(66556008)(186003)(66446008)(91956017)(6916009)(66946007)(478600001)(2616005)(86362001)(8676002)(53546011)(83380400001)(316002)(26005)(36756003)(54906003)(6506007)(5660300002)(2906002)(33656002)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?MTRFeW9Rak5kdWtlUU90SkkyWnFEYVNjbkJsRHBXck8rZTBGb2V4Q1pvVXBW?= =?utf-8?B?R1I3aFRoOE8wbUQwLzFwUzEveGNqQlk1SlVWeC9yT29GUEtwYitETXhLUkw0?= =?utf-8?B?YkNtWUVKRHJ2bjVOS1pZN285djh1NU5LcVVWMlAxUlJzNFRjbFI3ekJaQTRu?= =?utf-8?B?TkhHKzgrcXMzckcyV3BHVjZETHF6NS8wWDBOWFI4WXo0N2NZZ3ZxWTgzLzMr?= =?utf-8?B?SVNnMTJRaXJQYkdwZDVHck1zcTNZR0RIUVZkd2RVTEhIRThPRGtIYThmbExG?= =?utf-8?B?UGwrREZNK1VEQzZQWmZTZllrOGhKRW8wTkdxWlE2c0xUeGdRb2JSRHpQQUFD?= =?utf-8?B?aWp3Qnl0TktjQnIxNmZvTW1JUXMxc2VuNUhSM0o2QnNCVkVjVFU0Q2tYbFpi?= =?utf-8?B?STdBYVJaY25LcVo0SEhLY3hia2hQVWd2QVdKT09WL0xSV3graUZzdjZZNkpM?= =?utf-8?B?STJ1OXBqNGtRTEszckhxSDkyeVFtWm96dWk3QmJVVHFhOG1TRmptRnZaUnU1?= =?utf-8?B?ODZRc0t2M1NtbWN2QkVES3hrWW9WRkYxZU5tR0w2RCt6NU9wVHVJZFZLVG92?= =?utf-8?B?RVMwL1JKY0JKYS9LbUIrYWRzVUF1cklXLzVrMVVNWnEwTzhhNE03RHZGOG8r?= =?utf-8?B?S0hjUnNqTjU1M05zQWwvZStVRVoyUjJsSHM4T1VyZURDRU9CRktIMmNFV3VD?= =?utf-8?B?QTBYQ2k1VTJxOUVjTDhQVlVjb3VweVc0M2ZBTGNsSURoUis3ekdYbDJrN2hq?= =?utf-8?B?ZUIxYkhjTHR4d3hvRzV1VXJpQVlyZmtUcDVtU05VZ1hNWXIxVDIxZC9rWC9j?= =?utf-8?B?dFF6UHlBS0tON2diYUV1N1dQVHpId0c2UWxWL0NJMzE5Z0wxYUwvUWF2a3Nm?= =?utf-8?B?ZUE4V1FWWCtVbU50THU0ZkJqTFBMOWdDbHhkTUVnTVl0RzFNM3ZlVWs4K2c1?= =?utf-8?B?WkV5eXlpWStEbUYwaDRFUFJGbkZyN2s2bWZmZnRJN3BhbTB4ME16bU1KalJD?= =?utf-8?B?TG9TM1B0VjcwWGFndDV3WDdNS3ZLK2Fibm5SbnJSRlJndDFnVHYrRHlMTlhY?= =?utf-8?B?MVhNVUxOdTc3STB3Mld4RldtbHJ4VkdGZ3FDWEVqYmVHYnUyR3hIbkZnVTE0?= =?utf-8?B?MHNMdGtKRThJNGpGd3ZjMUIydGRmTUVZWjlwVEh0VncyS28zR0QvYW5SSWNF?= =?utf-8?B?RWUrL0w1NGxiYU1NdStWRVdJc3BJeEpMaWFFKysxVUx2TVVpNGwrUk4zdUk3?= =?utf-8?B?dU11QVRwL0F4OExmK1A4V3c1OGdLSGc5R0ZiVElpN1AyOHpCZk02blQydVor?= =?utf-8?Q?6/pmD0q2NN58EXLM7TkWuVfp0VpveRcpu9?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_4DF0A75A8A2340BAAD43B1B5BF0E29EBjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7eb9c454-85b5-4a3b-feaf-08d8b25e2231 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2021 16:14:24.2087 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9BA/klDbrwwmVBrncJBdpKdby/KHe6rpx6OlwrQa+TYnLGaBanFeehgVcsF5aOra X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6527 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-06_09:2021-01-06, 2021-01-06 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 phishscore=0 mlxlogscore=999 spamscore=0 malwarescore=0 mlxscore=0 bulkscore=0 suspectscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101060098 Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-idr-ext-opt-param-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: Wed, 06 Jan 2021 16:14:38 -0000 --_000_4DF0A75A8A2340BAAD43B1B5BF0E29EBjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmFuY3ksDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcuIENvbW1lbnRzIGJlbG93Lg0KDQpP biBEZWMgMTcsIDIwMjAsIGF0IDg6MjQgUE0sIE5hbmN5IENhbS1XaW5nZXQgdmlhIERhdGF0cmFj a2VyIDxub3JlcGx5QGlldGYub3JnPG1haWx0bzpub3JlcGx5QGlldGYub3JnPj4gd3JvdGU6DQoN CltFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0NCg0KDQpSZXZpZXdlcjog TmFuY3kgQ2FtLVdpbmdldA0KUmV2aWV3IHJlc3VsdDogUmVhZHkNCg0KSSBoYXZlIHJldmlld2Vk IHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncw0Kb25n b2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQg YnkgdGhlDQpJRVNHLiAgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3Ig dGhlIGJlbmVmaXQgb2YgdGhlDQpzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVk aXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQNCnRoZXNlIGNvbW1lbnRzIGp1c3QgbGlr ZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpUaGlzIGRvY3VtZW50IGRlc2NyaWJl cyB0aGUgYWxsb3dhbmNlIGZvciB0aGUgZXh0ZW5kZWQgb3B0aW9uYWwgcGFyYW1ldGVycyBpbg0K QkdQIHRvIGJlIGdyZWF0ZXIgdGhhbiAyNTUuICBBcyB3cml0dGVuLCB0aGUgZG9jdW1lbnQgaXMg c3RyYWlnaHRmb3J3YXJkIGFuZCBvbg0KcG9pbnQuIEkgb25seSBoYXZlIGFuIGVkaXRvcmlhbCBu aXQgYW5kIGEgc3VnZ2VzdGlvbi4NCg0KTklUOg0KU2VjdGlvbiAyOiAxc3Qgc2VudGVuY2Ugb2Yg dGhlIDd0aCBwYXJhZ3JhcGggInRoYXQgaW4gdGhlLi4uIiBOZWVkcyB0byBiZSBmaXhlZC4NClNo b3VsZCBpdCBiZTogInRoYXQgaXMgaW4gdGhlLi4uIj8NCg0KVGhpcyBpcyB0aGUgcGFyYWdyYXBo Og0KDQoNCiAgIFRoZSBzdWJzZXF1ZW50IG9uZS1vY3RldCBmaWVsZCwgdGhhdCBpbiB0aGUgbm9u LWV4dGVuZGVkIGZvcm1hdCB3b3VsZA0KICAgYmUgdGhlIGZpcnN0IE9wdGlvbmFsIFBhcmFtZXRl ciBUeXBlIGZpZWxkLCBNVVNUIGJlIHNldCB0byAyNTUgb24NCiAgIHRyYW5zbWlzc2lvbi4gIE9u IHJlY2VpcHQsIGEgdmFsdWUgb2YgMjU1IGZvciB0aGlzIGZpZWxkIGlzIHRoZQ0KICAgaW5kaWNh dGlvbiB0aGF0IHRoZSBleHRlbmRlZCBmb3JtYXQgaXMgaW4gdXNlLg0KDQoNCkkgdGhpbmsgaXQg aXMgY29ycmVjdCBhcyB3cml0dGVuLCBidXQgSSBjYW4gc2VlIHdoeSBpdCBkb2VzbuKAmXQgc2Nh biB3ZWxsIGZvciBldmVyeW9uZS4gV2UgY291bGQgcmV3cml0ZSBhcyBzb21ldGhpbmcgbGlrZSDi gJxUaGUgc3Vic2VxdWVudCBvbmUtb2N0ZXQgZmllbGQgKHRoYXQgd291bGQgYmUgdGhlIGZpcnN0 IE9wdGlvbmFsIFBhcmFtZXRlciBUeXBlIGZpZWxkIGluIHRoZSBub24tZXh0ZW5kZWQgZm9ybWF0 KSBNVVNUIGJlIHNldCB0byAyNTUgb24gdHJhbnNtaXNzaW9uLuKAnQ0KDQpXaGF0IGRvIHlvdSB0 aGluaz8gQ2xlYXJlcj8NCg0KU3VnZ2VzdGlvbjoNCi0gQXMgbmV3IGRyYWZ0cyBuZWVkIHRvIGlu Y2x1ZGUgc2VjdXJpdHkgYW5kIHByaXZhY3kgY29uc2lkZXJhdGlvbnMsIEkgdGhpbmsgaXQNCndv dWxkIGJlIGdvb2QgdG8ganVzdCBhZGQgaW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24gKDUpIHRoYXQg aXQgZG9lc24ndCBjaGFuZ2UNCmJvdGggdW5kZXJseWluZyBzZWN1cml0eSBvciBwcml2YWN5IGlz c3VlcyBhcyBub3RlZCBpbiBSRkM1MjcyLg0KDQpJIHRoaW5rIHlvdSBtdXN0IG1lYW4gUkZDIDQy NzIuIEkgYWRkZWQg4oCcb3IgY29uZmlkZW50aWFsaXR54oCdIGluc3RlYWQgb2Yg4oCcb3IgcHJp dmFjeeKAnSwgc2luY2UgNDI3MiBkb2VzbuKAmXQgYWRkcmVzcyBwcml2YWN5IGJ5IG5hbWUgYXQg YWxsLiBSZWFzb25hYmxlPw0KDQpSZWdhcmRzLA0KDQrigJRKb2huDQo= --_000_4DF0A75A8A2340BAAD43B1B5BF0E29EBjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <7622162211AA5944BFFDE4F1DD219EA5@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIE5hbmN5LA0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzIGZvciB5b3VyIHJldmlldy4g Q29tbWVudHMgYmVsb3cuPGJyIGNsYXNzPSIiPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gRGVjIDE3LCAyMDIw LCBhdCA4OjI0IFBNLCBOYW5jeSBDYW0tV2luZ2V0IHZpYSBEYXRhdHJhY2tlciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmciIGNsYXNzPSIiPm5vcmVwbHlAaWV0Zi5vcmc8L2E+ Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5bRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRp b3VzIG9mIGNvbnRlbnRdPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KUmV2aWV3ZXI6IE5hbmN5IENhbS1XaW5nZXQ8YnIgY2xhc3M9IiI+DQpSZXZpZXcgcmVzdWx0 OiBSZWFkeTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgaGF2ZSByZXZpZXdlZCB0aGlz IGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3M8YnIgY2xhc3M9 IiI+DQpvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHBy b2Nlc3NlZCBieSB0aGU8YnIgY2xhc3M9IiI+DQpJRVNHLiAmbmJzcDtUaGVzZSBjb21tZW50cyB3 ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGU8YnIgY2xhc3M9IiI+ DQpzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gJm5ic3A7RG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cg Y2hhaXJzIHNob3VsZCB0cmVhdDxiciBjbGFzcz0iIj4NCnRoZXNlIGNvbW1lbnRzIGp1c3QgbGlr ZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBhbGxvd2FuY2UgZm9yIHRoZSBleHRlbmRl ZCBvcHRpb25hbCBwYXJhbWV0ZXJzIGluPGJyIGNsYXNzPSIiPg0KQkdQIHRvIGJlIGdyZWF0ZXIg dGhhbiAyNTUuICZuYnNwO0FzIHdyaXR0ZW4sIHRoZSBkb2N1bWVudCBpcyBzdHJhaWdodGZvcndh cmQgYW5kIG9uPGJyIGNsYXNzPSIiPg0KcG9pbnQuIEkgb25seSBoYXZlIGFuIGVkaXRvcmlhbCBu aXQgYW5kIGEgc3VnZ2VzdGlvbi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOSVQ6PGJy IGNsYXNzPSIiPg0KU2VjdGlvbiAyOiAxc3Qgc2VudGVuY2Ugb2YgdGhlIDd0aCBwYXJhZ3JhcGgg JnF1b3Q7dGhhdCBpbiB0aGUuLi4mcXVvdDsgTmVlZHMgdG8gYmUgZml4ZWQuPGJyIGNsYXNzPSIi Pg0KU2hvdWxkIGl0IGJlOiAmcXVvdDt0aGF0IGlzIGluIHRoZS4uLiZxdW90Oz88YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NClRoaXMgaXMgdGhlIHBhcmFncmFwaDo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2Pg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTMu MzMzMzMzMDE1NDQxODk1cHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBi cmVhay1iZWZvcmU6IHBhZ2U7Ij4gICBUaGUgc3Vic2VxdWVudCBvbmUtb2N0ZXQgZmllbGQsIHRo YXQgaW4gdGhlIG5vbi1leHRlbmRlZCBmb3JtYXQgd291bGQNCiAgIGJlIHRoZSBmaXJzdCBPcHRp b25hbCBQYXJhbWV0ZXIgVHlwZSBmaWVsZCwgTVVTVCBiZSBzZXQgdG8gMjU1IG9uDQogICB0cmFu c21pc3Npb24uICBPbiByZWNlaXB0LCBhIHZhbHVlIG9mIDI1NSBmb3IgdGhpcyBmaWVsZCBpcyB0 aGUNCiAgIGluZGljYXRpb24gdGhhdCB0aGUgZXh0ZW5kZWQgZm9ybWF0IGlzIGluIHVzZS4NCjwv cHJlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ SSB0aGluayBpdCBpcyBjb3JyZWN0IGFzIHdyaXR0ZW4sIGJ1dCBJIGNhbiBzZWUgd2h5IGl0IGRv ZXNu4oCZdCBzY2FuIHdlbGwgZm9yIGV2ZXJ5b25lLiBXZSBjb3VsZCByZXdyaXRlIGFzIHNvbWV0 aGluZyBsaWtlIOKAnFRoZSBzdWJzZXF1ZW50IG9uZS1vY3RldCBmaWVsZCAodGhhdCB3b3VsZCBi ZSB0aGUgZmlyc3QgT3B0aW9uYWwgUGFyYW1ldGVyIFR5cGUgZmllbGQgaW4gdGhlIG5vbi1leHRl bmRlZCBmb3JtYXQpIE1VU1QgYmUNCiBzZXQgdG8gMjU1IG9uIHRyYW5zbWlzc2lvbi7igJ08L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldo YXQgZG8geW91IHRoaW5rPyBDbGVhcmVyPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+U3VnZ2VzdGlvbjo8YnIgY2xhc3M9 IiI+DQotIEFzIG5ldyBkcmFmdHMgbmVlZCB0byBpbmNsdWRlIHNlY3VyaXR5IGFuZCBwcml2YWN5 IGNvbnNpZGVyYXRpb25zLCBJIHRoaW5rIGl0PGJyIGNsYXNzPSIiPg0Kd291bGQgYmUgZ29vZCB0 byBqdXN0IGFkZCBpbiB0aGUgc2VjdXJpdHkgc2VjdGlvbiAoNSkgdGhhdCBpdCBkb2Vzbid0IGNo YW5nZTxiciBjbGFzcz0iIj4NCmJvdGggdW5kZXJseWluZyBzZWN1cml0eSBvciBwcml2YWN5IGlz c3VlcyBhcyBub3RlZCBpbiBSRkM1MjcyLjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SSB0aGluayB5b3UgbXVz dCBtZWFuIFJGQyA0MjcyLiBJIGFkZGVkIOKAnG9yIGNvbmZpZGVudGlhbGl0eeKAnSBpbnN0ZWFk IG9mIOKAnG9yIHByaXZhY3nigJ0sIHNpbmNlIDQyNzIgZG9lc27igJl0IGFkZHJlc3MgcHJpdmFj eSBieSBuYW1lIGF0IGFsbC4gUmVhc29uYWJsZT88L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2PuKAlEpvaG48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4DF0A75A8A2340BAAD43B1B5BF0E29EBjunipernet_-- From nobody Wed Jan 6 17:13:08 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 3F09A3A1435; Wed, 6 Jan 2021 17:12:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christopher Wood via Datatracker To: Cc: draft-ietf-6man-rfc4941bis.all@ietf.org, ipv6@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160998197921.18103.15481726186693031049@ietfa.amsl.com> Reply-To: Christopher Wood Date: Wed, 06 Jan 2021 17:12:59 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-6man-rfc4941bis-12 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 Jan 2021 01:12:59 -0000 Reviewer: Christopher Wood Review result: Has Issues Document: draft-ietf-6man-rfc4941bis-12 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 issues High-level comments: This is a great document! I apologize for taking so long to review it. My main comments are on the details of the address generation logic and heuristics, and how it ties into the larger threat model. In general, a clear description of the threat model these temporary addresses aim to address might be worth including, perhaps by expanding the Security Considerations. Comments: Section 1. The default address selection for IPv6 has been specified in [RFC6724]. The determination as to whether to use stable versus temporary addresses can in some cases only be made by an application. For example, some applications may always want to use temporary addresses, while others may want to use them only in some circumstances or not at all. An Application Programming Interface (API) such as that specified in [RFC5014] can enable individual applications to indicate a preference for the use of temporary addresses. I wonder if this should mention TAPS, which has discussed APIs for this sort of selection in the past. See https://tools.ietf.org/html/draft-ietf-taps-interface-10#section-5.2.13. Section 1.2. The correlation can be performed by: This probably isn't exhaustive, so perhaps: "Correlation can be performed by a variety of attackers, including, though not limited to:" (or something to that effect). Section 2.1. One of the requirements for correlating seemingly unrelated activities is the use (and reuse) of an identifier that is recognizable over time within different contexts. IP addresses provide one obvious example, but there are more. For example, What about MAC addresses? As I understand it, most systems are moving towards MAC address randomization, though it's still probably worth mentioning. Likewise, similar to cookies, one could also mention TLS (or transport) layer identifiers, such as TLS session tickets. This is touched on somewhat in the Security Considerations. Section 2.2. To make it difficult to make educated guesses as to whether two different interface identifiers belong to the same host, the algorithm for generating alternate identifiers must include input that has an unpredictable component from the perspective of the outside entities that are collecting information. It seems like this "must" be normative, and should probably reference the RFC4086 [https://tools.ietf.org/html/rfc4086]. Section 3.1. 3. New temporary addresses are generated over time to replace temporary addresses that expire. I assume expiration here means that the address is deprecated, right? If so, that might be worth clarifying. 4. The lifetime of temporary addresses must be statistically different for different addresses, such that it is hard to predict or infer when a new temporary address is generated, or correlate a newly- generated address with an existing one. This "must" is not normative, right? I assume not, since the previous guideline in this item ("the lifetime of an address should be further reduced when privacy-meaningful events ... takes place") does not require all temporary addresses to cease working. It might be better to drop the "or correlate a newly-generated address with an existing one" bit. Moreover, what does "statistically different" mean, precisely? It might be more accurate to talk about this property from the perspective of the adversary. For example, I think this is trying to say that given two different temporary addresses, an adversary must have negligible probability in determining whether or not they correspond to the same or different sources. (That would match better with the Randomized Interface Identifier algorithms given in Section 3.3.) Section 3.2. This document also assumes that an API will exist that allows individual applications to indicate whether they prefer to use temporary or stable addresses and override the system defaults (see e.g. [RFC5014]). If a reference to TAPS is made for these APIs, it is probably also worth including here. Section 3.3. The algorithm specified in Section 3.3.1 benefits from a Pseudo-Random Number Generator (PRNG) available on the system. What does "benefits" mean here? If we're specifying an algorithm to generate random values, shouldn't a PRNG be *required*? Section 3.3.2. This section assumes a "hash-based" algorithm, but is specified using a PRF. Later, in the text, it reads: F() could be the result of applying a cryptographic hash over an encoded version of the function parameters. But a cryptographic hash is not a PRF. If the hash function is meant to be keyed, even that probably isn't sufficient. (Some constructions, like H(k || m) for secret k and input m, are vulnerable to length extensions.) I think it's probably safest to recommend a particular construction, such as HKDF with secret_key and output length equal to the number bytes needed for the interface identifier. Moreover, requirements for secret_key are not really strict enough. There's text about F(), e.g.,: F() MUST also be difficult to reverse, such that it resists attempts to obtain the secret_key And it is said that secret_key "SHOULD be of at least 128 bits," but what if it's less? What if it only has a single byte of entropy? Section 3.4. Constants here are used before defined. Moving Section 3.8 to somewhere before Section 3.4 might help. What happens if the constants are chosen such that the rule (5) is not possible to achieve? Section 3.6. The frequency at which temporary addresses change depends on how a device is being used (e.g., how frequently it initiates new communication) and the concerns of the end user. The most egregious privacy concerns appear to involve addresses used for long periods of time (weeks to months to years). The more frequently an address changes, the less feasible collecting or coordinating information keyed on interface identifiers becomes. Moreover, the cost of collecting information and attempting to correlate it based on interface identifiers will only be justified if enough addresses contain non-changing identifiers to make it worthwhile. Thus, having large numbers of clients change their address on a daily or weekly basis is likely to be sufficient to alleviate most privacy concerns. I don't disagree with the text, but is there anything we can cite here? Why do we think it's "sufficient," for example? Finally, when an interface connects to a new (different) link, existing temporary addresses for the corresponding interface MUST be eliminated, and new temporary addresses MUST be generated immediately for use on the new link. If the addresses are eliminated, how does one run DAD and ensure that the same (or similar) addresses are not used on the new link? Section 3.7. Devices implementing this specification MUST provide a way for the end user to explicitly enable or disable the use of temporary addresses. Why is this a MUST, rather than a SHOULD? Since this is effectively describing an API, I think this ought to be relaxed. Section 6. An implementation might want to keep track of which addresses are being used by upper layers so as to be able to remove a deprecated temporary address from internal data structures once no upper layer protocols are using it (but not before). It seems an application might also want to consider other information linkable to select addresses in the future. For example, TLS resumption may link clients across two different temporary addresses. (This goes back to my comment on Section 2.1 above.) From nobody Thu Jan 7 10:06:36 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 4041F3A0812; Thu, 7 Jan 2021 10:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 RzJtVOOXwprY; Thu, 7 Jan 2021 10:06:33 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD393A0475; Thu, 7 Jan 2021 10:06:32 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4DBZ1M3sfmz103b; Thu, 7 Jan 2021 19:06:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1610042791; bh=EBWu+QjOvwSjs9uIvdZUAy/SVWCII1GsDKRK7UazVjI=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=JwwIpLNV5E6bHXPyFZGgPdOVDKDqm1LsGMHGp8ojpZ0/eIDB4+uHkcGmxOaHuEfqd XXC8IPRYdvkUrTi56JD/UFbtY1vFIsfWQjs4SW1lgB/XncFGG3jVmnfkM+iwbAFvaa 9HZdMsMR2fK2kwPpEK6jvhO7Mh8//IYnKNs768kJx4b2tEFr/qbme1tThC5pojEcL8 mxz7cJO0bQOB+pJjW48KqAj7P9s6yvRe0UvjP/UHYhNVw3lJi1tTwYjJ5AUkMWvJit by5DKCQ3Fu0FW1D2AquoOJJlkrJj8+KhMnDq0/YlXsIxvrH8SPuDA8c9SyLrdLntPe pEcMrf0kCT2gQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 4DBZ1M31YrzDq7T; Thu, 7 Jan 2021 19:06:31 +0100 (CET) From: To: Steve Hanna , "secdir@ietf.org" CC: "draft-ietf-sfc-nsh-integrity.all@ietf.org" , "sfc@ietf.org" Thread-Topic: Secdir early review of draft-ietf-sfc-nsh-integrity-01 Thread-Index: AQHW2iGfyZergZl9c0m+HEhLWQWzAqoZEuiAgAN4NXA= Date: Thu, 7 Jan 2021 18:06:30 +0000 Message-ID: <25629_1610042791_5FF74DA7_25629_15_1_787AE7BB302AE849A7480A190F8B9330315B48D3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160883409674.11984.2680388131154961282@ietfa.amsl.com> <32489_1609863531_5FF4916B_32489_106_1_787AE7BB302AE849A7480A190F8B9330315A77C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <32489_1609863531_5FF4916B_32489_106_1_787AE7BB302AE849A7480A190F8B9330315A77C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: 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 early review of draft-ietf-sfc-nsh-integrity-01 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 Jan 2021 18:06:35 -0000 SGkgU3RldmUsIGFsbCwgDQoNCkZXSVcsIGFuIHVwZGF0ZWQgdmVyc2lvbiB0aGF0IHRha2VzIGlu dG8gYWNjb3VudCB5b3VyIHJldmlldyBpcyBhdmFpbGFibGUgb25saW5lOiANCg0KVVJMOiAgICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaWV0Zi1zZmMtbnNo LWludGVncml0eS0wMi50eHQgDQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zZmMtbnNoLWludGVncml0eS8gDQpIdG1saXplZDogICAg ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNmYy1u c2gtaW50ZWdyaXR5IA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5LTAyIA0KRGlmZjogICAgICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5 LTAyDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBE ZcKgOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+IFttYWlsdG86bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbV0NCj4gRW52b3nDqcKgOiBtYXJkaSA1IGphbnZpZXIgMjAyMSAxNzox OQ0KPiDDgMKgOiBTdGV2ZSBIYW5uYSA8c3RldmVAaGFubmFzLmNvbT47IHNlY2RpckBpZXRmLm9y Zw0KPiBDY8KgOiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5LmFsbEBpZXRmLm9yZzsgc2Zj QGlldGYub3JnDQo+IE9iamV0wqA6IFJFOiBTZWNkaXIgZWFybHkgcmV2aWV3IG9mIGRyYWZ0LWll dGYtc2ZjLW5zaC1pbnRlZ3JpdHktMDENCj4gDQo+IEhpIFN0ZXZlLA0KPiANCj4gTWFueSB0aGFu a3MgZm9yIHRoZSByZXZpZXcuDQo+IA0KPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gDQo+IENoZWVy cywNCj4gTWVkDQo+IA0KPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+IERlwqA6 IFN0ZXZlIEhhbm5hIHZpYSBEYXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+ IEVudm95w6nCoDoNCj4gPiBqZXVkaSAyNCBkw6ljZW1icmUgMjAyMCAxOToyMiDDgMKgOiBzZWNk aXJAaWV0Zi5vcmcgQ2PCoDoNCj4gPiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5LmFsbEBp ZXRmLm9yZzsgc2ZjQGlldGYub3JnIE9iamV0wqA6DQo+IFNlY2Rpcg0KPiA+IGVhcmx5IHJldmll dyBvZiBkcmFmdC1pZXRmLXNmYy1uc2gtaW50ZWdyaXR5LTAxDQo+ID4NCj4gPiBSZXZpZXdlcjog U3RldmUgSGFubmENCj4gPiBSZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVzDQo+ID4NCj4gPiBJIGhh dmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eQ0KPiBkaXJl Y3RvcmF0ZSdzDQo+ID4gb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50 cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlDQo+ID4gSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUg d3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mDQo+IHRoZQ0KPiA+IHNlY3VyaXR5 IGFyZWEgZGlyZWN0b3JzLg0KPiA+ICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hv dWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QNCj4gbGlrZQ0KPiA+IGFueSBvdGhlciBsYXN0 IGNhbGwgY29tbWVudHMuDQo+ID4NCj4gPiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhZGRzIGlu dGVncml0eSBhbmQgb3B0aW9uYWwgZW5jcnlwdGlvbiBvZg0KPiA+IHNlbnNpdGl2ZSBtZXRhZGF0 YSBkaXJlY3RseSB0byB0aGUgTmV0d29yayBTZXJ2aWNlIEhlYWRlciAoTlNIKQ0KPiA+IHByb3Rv Y29sIGRlZmluZWQgaW4gUkZDIDgzMDAsIHRodXMgcmVkdWNpbmcgb3IgZWxpbWluYXRpbmcgc2V2 ZXJhbA0KPiA+IGF0dGFjayB2ZWN0b3JzIGFnYWluc3QgU2VydmljZSBGdW5jdGlvbiBDaGFpbmlu ZyAoU0ZDKS4gVGhlDQo+IGRvY3VtZW50DQo+ID4gaXMgd2VsbCB3cml0dGVuIGFuZCBzZWVtcyBh ZGVxdWF0ZSBmb3IgdGhlIGdvYWxzIGFydGljdWxhdGVkIGhlcmUNCj4gYW5kDQo+ID4gZWxzZXdo ZXJlIGluIHRoZSBTRkMgZG9jdW1lbnQgc3VpdGUuDQo+IA0KPiBbTWVkXSBUaGFua3MuDQo+IA0K PiAgSG93ZXZlciwgSSBoYXZlIHNvbWUNCj4gPiBpc3N1ZXMsIHF1ZXN0aW9ucywgYW5kIG5pdHMu DQo+IA0KPiBbTWVkXSBUaGlzIHdhcyBleGFjdGx5IHdoYXQgd2Ugd2VyZSBsb29raW5nIGZvciEg VGhhbmtzLg0KPiANCj4gPg0KPiA+IE5vdGUgdGhhdCBJIGhhdmUgbm90IHByZXZpb3VzbHkgd29y a2VkIHdpdGggU0ZDLiBJbiB0aGUgbGFzdCBmZXcNCj4gZGF5cywNCj4gPiBJIGhhdmUgcmVhZCB0 aGUgZG9jdW1lbnRzIG9uIHRoaXMgZG9jdW1lbnQgc28gSSBhbSBmYWlybHkNCj4gY29uZmlkZW50 DQo+ID4gdGhhdCBJIHVuZGVyc3RhbmQgdGhlIHJlbGV2YW50IHNlY3VyaXR5IGFzcGVjdHMuDQo+ ID4NCj4gPiBJU1NVRVMgYW5kIFFVRVNUSU9OUzoNCj4gPiBXaHkgaW5jbHVkZSBhIE1VU1QgaW4g c2VjdGlvbiA5LjI/IElzbid0IHRoYXQgYWxyZWFkeSBjb3ZlcmVkDQo+IGVhcmxpZXINCj4gPiAo aW4gdGhlIGxhc3Qgc2VudGVuY2Ugb2Ygc2VjdGlvbiA3LjUpPw0KPiANCj4gW01lZF0gRmFpciBw b2ludC4gV2lsbCByZXdvcmQgdG8gYXZvaWQgcmVkdW5kYW50IHVzZSBvZiBub3JtYXRpdmUNCj4g bGFuZ3VhZ2UuDQo+IA0KPiA+DQo+ID4gVGhlIFRpbWVzdGFtcCBmaWVsZCBpcyBzdXBwb3NlZCB0 byBoYW5kbGUgcmVwbGF5IGF0dGFja3MuIEhvd2V2ZXIsDQo+ID4gdGhpcyBwZXJtaXRzIHVubGlt aXRlZCByZXBsYXlzIHdpdGhpbiB0aGUgRGVsdGEgaW50ZXJ2YWwuIElzIHRoYXQNCj4gPiBhY2Nl cHRhYmxlPw0KPiANCj4gW01lZF0gVGhpcyBpcyBhIGRpc2N1c3Npb24gd2UgaGFkIGFtb25nIHRo ZSBhdXRob3JzIGFuZCB3ZSBiZWxpZXZlDQo+IHRoYXQgMiBzZWNvbmRzIGlzIGFjY2VwdGFibGUg ZXNwZWNpYWxseSB0aGF0IHRoZSB0aW1lc3RhbXAgaXMgc2V0IGJ5DQo+IHRoZSBjbGFzc2lmaWVy IGFuZCBrZXB0IGFsb25nIGFuIGNoYWluIChleGNlcHQsIGlmIHJlY2xhc3NpZmljYXRpb24NCj4g aGFwcGVucykuIFRoYXQgdmFsdWUgY2FuIGJlIGRlY3JlYXNlZCBpZiByZXF1aXJlZCBhcyBhIGZ1 bmN0aW9uIG9mIGENCj4gbG9jYWwgZGVwbG95bWVudC4NCj4gDQo+IEZXWSwgd2UgY29uc2lkZXJl ZCB0aGUgdXNlIG9mIHNlcXVlbmNlIG51bWJlcnMgaW4gdGhlIC0wMCBidXQNCj4gYWJhbmRvbmVk IHRoYXQgZGVzaWduIGJlY2F1c2Ugc29tZSBTRiBpbnN0YW5jZXMgbWF5IG5vdCByZWNlaXZlIGFs bA0KPiB0aGUgcGFja2V0cyBvZiBhIGdpdmVuIGZsb3cuIFRoYXQgaXMgdHlwaWNhbGx5IHRoZSBj YXNlIG9mIGxvYWQtDQo+IGJhbGFuY2luZyBvciB0aGUgc28tY2FsbGVkIFNGQyBPZmZsb2Fkcy4N Cj4gDQo+ID4NCj4gPiBXaGF0IGlzIHRoZSA/IG9wZXJhdG9yIGluIHNlY3Rpb24gNy40IHN1cHBv c2VkIHRvIGNvbm5vdGU/DQo+ID4gU3VidHJhY3Rpb24gc2VlbXMgbGlrZSBhIGJldHRlciBjaG9p Y2UuDQo+IA0KPiBbTWVkXSBXZSBhcmUgY2FsY3VsYXRpbmcgdGhlIGRpZmYgYmV0d2VlbiBUUyBh bmQgVFNydC4gV2lsbCBjbGFyaWZ5DQo+IGluIHRoZSBuZXh0IGl0ZXJhdGlvbi4NCj4gDQo+ID4N Cj4gPiBJcyB0aGUgVGltZXN0YW1wIGZpZWxkIG9ubHkgc2V0IGJ5IHRoZSBmaXJzdCBpbXBvc2Vy IGluIHRoZSBTRlAgb3INCj4gPiBzaG91bGQgaXQgYmUgdXBkYXRlZCB3aGVuZXZlciBhbiBpbXBv c2VyIGNoYW5nZXMgdGhlIE1BQz8gVGhpcw0KPiBzaG91bGQNCj4gPiBiZSBkb2N1bWVudGVkIHNv bWV3aGVyZSwgbWF5YmUgaW4gc2VjdGlvbiA3LjQuDQo+IA0KPiBbTWVkXSBUaGUgdGltZXN0YW1w IGlzIGxlZnQgdW50b3VjaGVkIGFzIGxvbmcgYSBwYWNrZXQgcHJvZ3Jlc3NlcyBpbg0KPiBhIHNl cnZpY2UgcGF0aC4gSXQgd2lsbCBiZSB1cGRhdGVkIHdoZW4gd2UgZG8gcmVjbGFzc2lmaWNhdGlv biwNCj4gdGhvdWdoLiBXaWxsIGFkZCB0ZXh0IHRvIG1ha2UgdGhpcyBjbGVhci4NCj4gDQo+ID4N Cj4gPiBUaGUgdGhyZWF0IG1vZGVsIGRlc2NyaWJlZCBpbiBkcmFmdC1hcmtrby1mYXJyZWxsLWFy Y2gtbW9kZWwtdC0wNA0KPiA+IGluY2x1ZGVzIGNvbXByb21pc2VkIG5vZGVzLiBUaGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBvZg0KPiA+IHRoaXMgZG9jdW1lbnQgc2hvdWxkIGRl c2NyaWJlIGhvdyBhbmQgdG8gd2hhdCBleHRlbnQgY29tcHJvbWlzZWQNCj4gbm9kZXMNCj4gPiBh cmUgaGFuZGxlZCBieSB0aGUgcHJvdGVjdGlvbnMgcHJvdmlkZWQgYnkgdGhpcyBkb2N1bWVudCBh bmQgd2hhdA0KPiA+IHJlc2lkdWFsIHJpc2tzIHJlbWFpbi4NCj4gDQo+IFtNZWRdIEEgY29tcHJv bWlzZWQgZW50aXR5IGNhbiBkcm9wIHBhY2tldHMgb3IgYnlwYXNzIGFuIFNGIGlzDQo+IGRpc2N1 c3NlZCBpbiB0aGUgZHJhZnQ6DQo+IA0KPiAgICBUaGUgYXR0YWNrcyBkaXNjdXNzZWQgaW4gW0kt RC5uZ3V5ZW4tc2ZjLXNlY3VyaXR5LWFyY2hpdGVjdHVyZV0NCj4gYXJlDQo+ICAgIGhhbmRsZWQg b3dpbmcgdG8gdGhlIHNvbHV0aW9uIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50LCBleGNlcHQN Cj4gZm9yDQo+ICAgIGF0dGFja3MgZHJvcHBpbmcgcGFja2V0cy4gIFN1Y2ggYXR0YWNrcyBjYW4g YmUgZGV0ZWN0ZWQgcmVseWluZw0KPiB1cG9uDQo+ICAgIHN0YXRpc3RpY2FsIGFuYWx5c2lzOyBz dWNoIGFuYWx5c2lzIGlzIG91dCBvZiBzY29wZSBvZiB0aGlzDQo+IGRvY3VtZW50Lg0KPiAgICBB bHNvLCBpZiBTRkZzIGFyZSBub3QgaW52b2x2ZWQgaW4gdGhlIGludGVncml0eSBjaGVja3MsIGEN Cj4gbWlzYmVoYXZpbmcNCj4gICAgU0ZGIHdoaWNoIGRlY3JlbWVudHMgU0kgd2hpbGUgdGhpcyBz aG91bGQgYmUgZG9uZSBieSBhbiBTRiAoU0YNCj4gYnlwYXNzDQo+ICAgIGF0dGFjaykgd2lsbCBi ZSBkZXRlY3RlZCBieSBhbiB1cHN0cmVhbSBTRiBiZWNhdXNlIHRoZSBpbnRlZ3JpdHkNCj4gICAg Y2hlY2sgd2lsbCBmYWlsLg0KPiANCj4gT3RoZXIgZGFtYWdlIG1heSBiZSBpbmR1Y2VkIGJ5IGNv bXByb21pc2VkIGRldmljZXMuIFdpbGwgc2VlIHdoYXQgd2UNCj4gY2FuIGFkZCBtb3JlLg0KPiAN Cj4gPg0KPiA+IFRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHNob3VsZCBleHBs aWNpdGx5IGFja25vd2xlZGdlDQo+IHRoYXQNCj4gPiBhdXRoZW50aWNhdGlvbiBpcyBub3QgcHJv dmlkZWQgYnkgdGhpcyBtZXRob2QuDQo+ID4NCj4gPiBXaGF0IGRvZXMgdGhpcyBzdGF0ZW1lbnQg bWVhbj8NCj4gPiAgICAgICAgIOKAoiBJZiBITUFDIGFsZ29yaXRobSBpcyB1c2VkLCBJViBsZW5n dGggaXMgc2V0IHRvIHplcm8uDQo+ID4gRG9uJ3QgYWxsIHRoZSBjdXJyZW50IGFsZ29yaXRobXMg dXNlIEhNQUM/DQo+ID4NCj4gDQo+IFtNZWRdIEFjdHVhbGx5IHdlIHdhbnRlZCB0byByZWZlciB0 byB0aGlzIG1vZGU6DQo+IA0KPiAgICBvICBJZiB0aGUgQ29udGV4dCBIZWFkZXJzIGFyZSBub3Qg ZW5jcnlwdGVkLCB0aGUgSGFzaGVkIE1lc3NhZ2UNCj4gICAgICAgQXV0aGVudGljYXRpb24gTW9k ZSAoSE1BQykgYWxnb3JpdGhtIGRpc2N1c3NlZCBpbiBbUkZDNDg2OF0gaXMNCj4gICAgICAgdXNl ZCB0byBpbnRlZ3JpdHkgcHJvdGVjdCB0aGUgTlNIIGRhdGEuDQo+IA0KPiA+IFdoYXQgaXMgdGhl IGV4cGVjdGVkIGJlaGF2aW9yIGlmIHRoZXNlIENvbnRleHQgSGVhZGVycyBhcmUNCj4gbWlzc2lu Zz8NCj4gPiBUaGUgbGFzdCBwYXJhZ3JhcGggYXQgdGhlIGJvdHRvbSBvZiBwYWdlIDE4IHNlZW1z IHRvIGJlIGFtYmlndW91cw0KPiBvbg0KPiA+IHRoaXMgdG9waWMsIHdpdGggdGhlIGZpcnN0IHNl bnRlbmNlIHNheWluZyB0aGF0IHRoaXMgIlNIT1VMRCBiZQ0KPiBsb2dnZWQNCj4gPiBsb2NhbGx5 Ig0KPiANCj4gW01lZF0gVGhhdCBvbmUgaXMgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIGVu dGl0eSAoZS5nLiwNCj4gY2xhc3NpZmllcikgdGhhdCBmYWlscyB0byBpbmplY3QgdGhlIGhlYWRl ciBhdCB0aGUgZmlyc3QgcGxhY2UuDQo+IA0KPiB3aGlsZSB0aGUgbGFzdCBzZW50ZW5jZSBzYXlz IHRoYXQgdGhpcyAiTVVTVCBjYXVzZQ0KPiA+IHRoYXQgcGFja2V0IHRvIGJlIGRpc2NhcmRlZCIu DQo+IA0KPiBbTWVkXSBUaGlzIG9uZSBpcyB0aGUgYmVoYXZpb3IgZm9yIG9uLXBhdGggZW50aXRp ZXMuDQo+IA0KPiAgUHJvYmFibHkgdGhpcyBpcyBjbGVhciB0byB0aGUgd3JpdGVyDQo+ID4gYnV0 IG5vdCB0byB0aGlzIHJlYWRlciENCj4gDQo+IFtNZWRdIFBvaW50IHRha2VuLiBXaWxsIHJld29y ZC4NCj4gDQo+ID4NCj4gPiBOSVRTOg0KPiANCj4gW01lZF0gQWxsIGdvb2QgcG9pbnRzLiBXaWxs IGJlIGZpeGVkLiBUaGFua3MuDQo+IA0KPiA+IEF0IHRoZSB0b3Agb2YgcGFnZSA2LCAidW5lY3J5 cHRlZCIgc2hvdWxkIGJlICJ1bmVuY3J5cHRlZCIuDQo+ID4NCj4gPiBJbiB0aGUgbGFzdCBsaW5l IG9mIHBhZ2UgMTgsICJkZXBlbmQiIHNob3VsZCBiZSAiZGVwZW5kaW5nIi4NCj4gPg0KPiA+IEp1 c3QgYmVsb3cgRmlndXJlIDkgb24gcGFnZSAyMCwgYSBjb21tYSBpcyBuZWVkZWQgYWZ0ZXIgImRv aW5nDQo+IHNvIi4NCj4gPg0KPiA+IEluIHRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIHNlY3Rpb24g Ny41LCAic3VjY2Vzc2Z1bHkiIHNob3VsZCBiZQ0KPiA+IHNwZWxsZWQgInN1Y2Nlc3NmdWxseSIu DQo+ID4NCj4gPiBBdCB0aGUgZW5kIG9mIHRoZSBmaXJzdCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiA5 LCBjaGFuZ2UgdGhlDQo+IHNlbnRlbmNlDQo+ID4gZnJvbToNCj4gPiAgICAgICAgIOKAoiBBbHNv LCB0aGF0IHNlY3Rpb24gaW5kaWNhdGVzIHRoYXQgbWV0YWRhdGENCj4gY29uc2lkZXJhdGlvbnMN Cj4gPiB0aGF0DQo+ID4gICAgICAgICBvcGVyYXRvcnMgY2FuIHRha2UgaW50byBhY2NvdW50IHdo ZW4gdXNpbmcgTlNIIGFyZQ0KPiBkaXNjdXNzZWQNCj4gPiBpbg0KPiA+ICAgICAgICAgW1JGQzgx NjVdLg0KPiA+IHRvDQo+ID4gICAgICAgICDigKIgQWxzbywgdGhhdCBzZWN0aW9uIGluZGljYXRl cyB0aGF0IFtSRkM4MTY1XSBkaXNjdXNzZXMNCj4gPiBtZXRhZGF0YQ0KPiA+ICAgICAgICAgY29u c2lkZXJhdGlvbnMgdGhhdCBvcGVyYXRvcnMgY2FuIHRha2UgaW50byBhY2NvdW50IHdoZW4NCj4g dXNpbmcNCj4gPiBOU0guDQo+ID4NCj4gPiBUaGUgbGFzdCBzZW50ZW5jZSBvZiB0aGUgdGhpcmQg cGFyYWdyYXBoIG9mIHNlY3Rpb24gOSByZWNvbW1lbmRzDQo+IHRoYXQNCj4gPiAidGhlIG5leHQg a2V5IGlkZW50aWZpZXIiIGJlIGRpc3RyaWJ1dGVkIGxvbmcgYmVmb3JlIHRoZSBrZXkgaXMNCj4g PiBjaGFuZ2VkLiBUaGlzIHNob3VsZCBzYXkgInRoZSBuZXh0IGtleSBpZGVudGlmaWVyIGFuZCBh c3NvY2lhdGVkDQo+ID4ga2V5aW5nIG1hdGVyaWFsIi4NCj4gPg0KPiA+IEluIHRoZSBzZWNvbmQg cGFyYWdyYXBoIG9mIHNlY3Rpb24gOS4xLCAiZG9tYWluIGJlIGFibGUiIHNob3VsZCBiZQ0KPiA+ ICJkb21haW4gc2hvdWxkIGJlIGFibGUiLg0KPiA+DQo+ID4NCj4gDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiANCj4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p ciBkZXMgaW5mb3JtYXRpb25zDQo+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jIHBhcyBldHJlDQo+IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdQ0KPiBjZSBtZXNzYWdlIHBhciBl cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlDQo+IGRldHJ1 aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx dWVzDQo+IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlDQo+IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91IGZhbHNpZmllLiBNZXJjaS4NCj4gDQo+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0KPiBwcml2aWxlZ2VkIGluZm9ybWF0aW9u IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdA0KPiBiZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXINCj4gYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdA0KPiBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiBUaGFu ayB5b3UuDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv dGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Fri Jan 8 19:37: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 B0B6E3A09ED; Fri, 8 Jan 2021 19:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=IyE0QYj0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=pBuD2HKH 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 07z5ddRE9t05; Fri, 8 Jan 2021 19:37:34 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71473A09E9; Fri, 8 Jan 2021 19:37:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4832; q=dns/txt; s=iport; t=1610163452; x=1611373052; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=H6UBytmC8Ec1Hzd2PEC2tbPgS5pcnGGbp3C9X8nn+/c=; b=IyE0QYj0cdsF1tU0ysutIe2rMLA5EKjXnIW1aRBQ8l5QAyUpt3PR0H3h YwUyE5g4LcgxCa6LVrJM14NqhSwEIFtUuumUvd+7UaDGEBLdiLoUp3xk5 UyhN9c7AXnAZ3MEGiFi2H9wBsJMwa1z7wO5V1srpJLSGEau6ulMxqUh8t o=; IronPort-PHdr: =?us-ascii?q?9a23=3AuDk+XhVfMKO/AiVks1j64c/iyZrV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyHuf1BguvS9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7dp3Sz6XgZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdBQAEJPlf/5ldJa1iHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+BU1EHdlsvLgqENYNIA41LJQOZEoJTA1QLAQEBDQEBIwo?= =?us-ascii?q?CBAEBhEoCF4FZAiU4EwIDAQELAQEFAQEBAgEGBHGFYQyFdAEFIxEMAQE3AQ8?= =?us-ascii?q?CAQgYAgImAgICMBUQAgQBDQWDJgGCVQMuAQ6jCwKKJXaBMoMEAQEGgTcCg2k?= =?us-ascii?q?YghADBoEOKoJ1g3yGOiYbggCBEScMEIFYfj6CXQEBA4FcF4MBNIIsgkIGYAE?= =?us-ascii?q?DIhkWAjCBJwovARiLMIgEpCJ9CoJ2iSqMJYYPAx+DKYoulQeUEYsWkVwYhDU?= =?us-ascii?q?CBAIEBQIOAQEGgSVII4FXcBVlAYI+UBcCDY4hg3GFFIVEdDcCBgEJAQEDCXy?= =?us-ascii?q?KNQEwYAEB?= X-IronPort-AV: E=Sophos;i="5.79,333,1602547200"; d="scan'208";a="835960762" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Jan 2021 03:37:30 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 1093bWTf027682 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 9 Jan 2021 03:37:32 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 Jan 2021 21:37:31 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 Jan 2021 21:37:31 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 8 Jan 2021 22:37:30 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bNwWmv/rRvVDg7C+rR6AIcRIYK5YASIpNBQgIx2QiJhQ4aHUACHZxAbJxzBl6V9HQYunLS0Bws+011JUIGXMAQrR8NHAE3oxKpuf4cReFDs45HmcIzc5waDH8iSoV6JvpWulV8df/uU1Gp7uG0R43hg+0EsjY0N8r6k1jt0xfsm3Axvy8Wfb2ybWUDhIziO2AmUc7zb+ES1nrghnRi3oILi9lKyAEHWbnfRuDajam294jlvllIpbAKMsNJ4j6Q+DMGgEpL15XvJZOAYbOYHUHTj0AEUk104xPuv++uMuOy8jE3KgL3LHt7+y/2A4GzsA1sl+yfrGfpIqe7bTpjMklA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H6UBytmC8Ec1Hzd2PEC2tbPgS5pcnGGbp3C9X8nn+/c=; b=kTiwxrzhHz52BP8LuWIeb9FhnktarMCrt9EdnUsU+CvCnAvdvDQNeiiyno4Xrg+2LoPw1CqZen7l7wAFZRScAD3Ue7lh32Hk74BBRDx/uS7/M1UPfK4X0/7jjTzncATD21FPqzsqnJwN1Bpaxkq4xEXhi/D4x9YOQ1ubdO5yqYQ3yT18vNcSOptt4lwhUBNlQaDSO5AdcbUo01Xt9xcfcOqEMA9zL7QNqy7UE6SQ9ruqJI+XnLo03UWESqNG51yM6HeDzrvyF/QpjtgxhsJ8Ygo3U3UpM1heMBeZ5d11LG6V4ua3vzLo42+e9h3cjWXZ+PJj+2jGur2WVPTcUrUSWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H6UBytmC8Ec1Hzd2PEC2tbPgS5pcnGGbp3C9X8nn+/c=; b=pBuD2HKHWHACe5zvKIeY4UGRsPZmGamwtWloSL16bbcLTrrl1EC7IUAZUSZBJXxgZlVX8yrucUZpJwXaMneCmamFY+E2MkZMiqCtdb3ixgDHrWHMdsu4Z3GLV6dMqHUu2QwsTJ6GNTl6gAEKOqmPUHZ1NK1InVqyfQUgwnk8SXs= Received: from BY5PR11MB4273.namprd11.prod.outlook.com (2603:10b6:a03:1c9::32) by BYAPR11MB3719.namprd11.prod.outlook.com (2603:10b6:a03:fa::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.10; Sat, 9 Jan 2021 03:37:28 +0000 Received: from BY5PR11MB4273.namprd11.prod.outlook.com ([fe80::a926:a1cd:c970:99f8]) by BY5PR11MB4273.namprd11.prod.outlook.com ([fe80::a926:a1cd:c970:99f8%3]) with mapi id 15.20.3742.009; Sat, 9 Jan 2021 03:37:28 +0000 From: "Alberto Rodriguez-Natal (natal)" To: Chris Lonvick , "Joel M. Halpern" CC: "secdir@ietf.org" , "draft-ietf-lisp-pubsub.all@ietf.org" , "lisp@ietf.org" Thread-Topic: SECDIR review of draft-ietf-lisp-pubsub-06 Thread-Index: AQHWl+9PLxIjCp6uzUyWBT8sMqgoD6mDG8aA///yLoCAm62RgA== Date: Sat, 9 Jan 2021 03:37:28 +0000 Message-ID: References: <54e37d9a-8daf-c582-cb43-73114345843b@joelhalpern.com> <4EDE4838-BA3A-4181-9CE4-521963AB62AB@cisco.com> In-Reply-To: <4EDE4838-BA3A-4181-9CE4-521963AB62AB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.44.20121301 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [24.5.88.59] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 80a7bf01-e363-49e3-bf5d-08d8b44fe366 x-ms-traffictypediagnostic: BYAPR11MB3719: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KH5CGUuKMkwf/k7cWUUj589lbSMrsADxx0fRFjL0Qh0xFfnbRPssuH6z04mFyIG8zLatMMHa0+hvVkCTgvBs2hsjXIjIwBv4WBuu6FYTp8ZPNE322Qmqk9pxIbmfmfZgnmq6XjHrGG9KznbPIUtcuIDby1mrmNziViPmowzN31hC4zTQFZd/z9iLW2vRFXEsnaD8SUvEXfko1XBol/hc1JoHHz0iWCr95HyQNw/gCo+DOebbVeiDFPEKuarY/rOOVg2rllZDq9SsVvmrfBPM1cwwNzexawe8yhyVsJf/RF7KCgKQFubsSo869SDheDWwOoeETpdUTU41/pca226qU6LY2T2/IiGOJgq2cdMQ5spO0WlWnMZ91NYoQeDQoxQDYZkjR+GL8XfOs/IkTpTCtOwjE2qAkcpx++q65m80VubIn/Nza/Me3jICztqQLGcEIa7H5wkn2tj0O4rVBvgTAGcYU8HurZE4Orfe8XGwH35wH2SpqLv/vnY6QdE2PnYglSa5aSDagPfJsC3RRdi81w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4273.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(366004)(396003)(376002)(136003)(86362001)(6506007)(64756008)(5660300002)(316002)(54906003)(8676002)(53546011)(6486002)(83380400001)(26005)(478600001)(76116006)(110136005)(36756003)(66476007)(66556008)(66446008)(186003)(8936002)(66946007)(2906002)(966005)(33656002)(6512007)(4326008)(71200400001)(2616005)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Sll6Sms2a0tFSDdqdUxFY1ZmVU5mMVVtNjZxTGtSZmdEcmNrYzN3V1FRZDk5?= =?utf-8?B?S3FCK0FhUTNpSm55bS9zNGh6anArakZ6bktnWlFCL3k4bXBHanBHSm1KQ1py?= =?utf-8?B?TW9PQUEvYlZTUzNQcXprY0N1dkFQU2tQWk1qUTZ5dklQS1J6djVsR2IwOSs2?= =?utf-8?B?OEh3OWY1UEtUNFFiTWdhU3d6blBoc0E1UkJsdG1QQndKSXV4K2todU5jeHNG?= =?utf-8?B?NmgxaVZkZlFNb01wZEMzVnlmSHlyN0JDeUxhZ1lTTTBrQ0g1azJjbWIzR1dr?= =?utf-8?B?d1FDWmVycEhhL0t6eXF4TERTS1dGb0d3WjhtbWxjbEJYTnVCRlR1cCswTUlr?= =?utf-8?B?czRIUmR0Y3psR0hIRFFTSUlyQ0grbzNFcW5nWnlicXV1dDFGZDlHU0pFb0FC?= =?utf-8?B?dTd2RlRWcXhpN09UeU9tT2F5UGhrUjc4N3ZXYUpZRzdnc2FUSGprTUxETkJ6?= =?utf-8?B?M3lSYVBFMXp5V1Vtb2s5bFFKL1praUVGU1M4aUJEVy9lZENFRXRaQjlFSXlv?= =?utf-8?B?UnhJWEx0V0pWeTlSQ0lXL1hYWkR1T1BhKzRyY1BQbEdDT25yZmxuTlZpcHV1?= =?utf-8?B?Y2R2bW5ZdXB6VXVkU2tFV1FSQUwxK240RndkbEw3Nlh6OFJFSzhNSnVKK0xh?= =?utf-8?B?UnowQUx3UWhlZkduQ3FORkd5RVo4QXVaUzloeU91Y1R0WFFxZ2FpT01wMURy?= =?utf-8?B?NmRiRDNWeTVUaFdLVzBGb2RDdzNsM00wdXNuWExVWnVDeFNneG9pMHpHbHNN?= =?utf-8?B?NGgvVzVwbnFvOFh3QmVENG5lZ3FqOWFaZEkxWmdkNjJlVGdPSjV1YlpCei90?= =?utf-8?B?VHl0L0ZNSmlaenhiamRLYVdFQXVjTjBoaHZjbTdYKzRxMHBHRy9NRXRzbHhN?= =?utf-8?B?K0p1TEJ5Qkxpc25YV0ttR3JOcWg4OEJ3dXo5WW5lZWxIdEliejJPcXZNS2tX?= =?utf-8?B?ai9pdmpkRzNVVzdaa0VEclFaSjFCeGVkNUtjQUVWRTdyQ2hiUk16VFQrVVQr?= =?utf-8?B?TytnUVVOZTEwdGw3a2FVakxpMWlKZ2hab3Q1WCt2bENnU0dqZ0lZWnh4cERn?= =?utf-8?B?eW83Mm1NeE9yVTRUckZJUms3Ulc4T2tod1JBN290ODNMZ2h0TmJsMTAyQ3dq?= =?utf-8?B?Z0NXNlgvRkRCWHVTYyt0Tk9GRjhHRUNJendzL2U0OVlhMkxGYnB2dVZ0R0lR?= =?utf-8?B?L3lJVHBINDF1cXVkTHRKbkpZK05uZU0zNE5ORGNybkZBTlRLUnlCUlFnOHBL?= =?utf-8?B?NzZPTlZ2TTBiK0xrdjEwYlpUSWhVVzlKeGkzQnFSa1Y3SU1sVXUvd2kzU2dt?= =?utf-8?Q?379OGUZ+/BjYZ/rTUubQeHRLWCtbBw2KzX?= Content-Type: text/plain; charset="utf-8" Content-ID: <7EDCA26B7A7C1D41BD5E556F2DF41790@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4273.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 80a7bf01-e363-49e3-bf5d-08d8b44fe366 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2021 03:37:28.2533 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ml7ixOxHa1XCEaxgrcFujYkjh4mfb7jZ2QmaEK9oAFuMJzy5AptKo4lEAwZqg++/ X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3719 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-lisp-pubsub-06 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, 09 Jan 2021 03:37:36 -0000 SGkgQ2hyaXMsDQoNClRoYW5rcyBhZ2FpbiBmb3IgdGhlIHJldmlldyBvZiB0aGUgTElTUCBQdWJT dWIgZG9jdW1lbnQsIGl0IHdhcyBtb3N0IGhlbHBmdWwhIFdlIGJyb3VnaHQgdGhlIFNFQ0RJUiBj b21tZW50cyB0byB0aGUgYXR0ZW50aW9uIG9mIHRoZSBMSVNQIFdHIGR1cmluZyB0aGUgbGFzdCBJ RVRGIGluIE5vdmVtYmVyIGFuZCBnYXRoZXJlZCBzb21lIGNvbnNlbnN1cyBmcm9tIHRoZSBXRyBv biBob3cgdG8gbW92ZSBmb3J3YXJkLg0KDQpSZWdhcmRpbmcgdGhlIHVzZSBvZiB0aGUgdGVybSAi bm9uY2UiLCB0aGUgb3BpbmlvbiBvZiB0aGUgV0cgd2FzIHRvIGtlZXAgdGhlIHRlcm0gZm9yIGNv bnNpc3RlbmN5IHdpdGggdGhlIHJlc3Qgb2YgdGhlIExJU1AgZG9jdW1lbnRzLiBUaGUgdGVybSBu b25jZSBoYXMgYmVlbiB1c2VkIHRoaXMgd2F5IGluIHRoZSBMSVNQIGxpdGVyYXR1cmUgZm9yIHNv IGxvbmcgdGhhdCB0aGUgV0cgYmVsaWV2ZXMgaXQgd291bGQgYmUgdmVyeSBjaGFsbGVuZ2luZyB0 byBjaGFuZ2UgaXQgbm93LiANCg0KQXMgcGVyIHdoYXQgaGFwcGVucyB3aGVuIHRoZSBub25jZSBm aWVsZHMgZXhjZWVkcyB0aGUgZmllbGQgc3BhY2UsIHdlIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZl cnNpb24gb2YgdGhlIGRyYWZ0ICgtMDcpIHdpdGggYSBub3RlIHRvIGNsYXJpZnkgdGhhdCBpdCBp cyBub3QgZXhwZWN0ZWQgdG8gaGFwcGVuIGR1cmluZyBub3JtYWwgb3BlcmF0aW9uIG9mIHRoZSBw cm90b2NvbCBkdWUgdG8gdGhlIGxhcmdlIGZpZWxkIHNpemUuDQoNClBsZWFzZSBmZWVsIGZyZWUg dG8gdGFrZSBhIGxvb2sgYXQgdGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCBhbmQga2lu ZGx5IGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFueSBmdXJ0aGVyIGNvbW1lbnQuDQoNCmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWxpc3AtcHVic3ViLTA3DQoNClRoYW5r cyBhZ2FpbiBmb3IgeW91ciB0aW1lIGFuZCBncmVhdCBmZWVkYmFjayENCg0KQWxiZXJ0bw0KDQrv u79PbiAxMC8xLzIwLCA2OjE1IFBNLCAiQWxiZXJ0byBSb2RyaWd1ZXogTmF0YWwgKG5hdGFsKSIg PG5hdGFsQGNpc2NvLmNvbT4gd3JvdGU6DQoNCiAgICBUaGFua3MgYSBsb3QgZm9yIHRoZSByZXZp ZXcgQ2hyaXMsIHRoaXMgaXMgbXVjaCBhcHByZWNpYXRlZCBmZWVkYmFjay4gV2Ugd2lsbCBzdWJt aXQgYSBuZXcgaXRlcmF0aW9uIG9mIHRoZSBkb2N1bWVudCBhZGRyZXNzaW5nIHlvdXIgY29tbWVu dHMuDQoNCiAgICBUaGFua3MgYWxzbyBKb2VsIGZvciBmYWNpbGl0YXRpbmcgdGhlIHJldmlldy4N Cg0KICAgIEJlc3QsDQogICAgQWxiZXJ0bw0KDQogICAgT24gMTAvMS8yMCwgMTI6MDYgUE0sICJK b2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCg0KICAgICAgICBU aGFuayB5b3UgQ2hyaXMuICAgVGhhdCBpcyBoZWxwZnVsLCBhbmQgSSBhbSBjb25maWRlbnQgdGhl IGF1dGhvcnMgd2lsbCANCiAgICAgICAgY2xlYW4gdXAgdGhlIHRlcm1pbm9sb2d5Lg0KDQogICAg ICAgIFlvdXJzLA0KICAgICAgICBKb2VsDQoNCiAgICAgICAgT24gMTAvMS8yMDIwIDg6MzQgQU0s IENocmlzIExvbnZpY2sgd3JvdGU6DQogICAgICAgID4gSGksDQogICAgICAgID4gDQogICAgICAg ID4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkg ZGlyZWN0b3JhdGUncyANCiAgICAgICAgPiBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElF VEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gDQogICAgICAgID4gVGhl c2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhl IHNlY3VyaXR5IA0KICAgICAgICA+IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFu ZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIA0KICAgICAgICA+IGNvbW1lbnRzIGp1c3Qg bGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KICAgICAgICA+IA0KICAgICAgICA+ IFRoaXMgaXMgYW4gIkVhcmx5IFJldmlldyBSZXF1ZXN0IiBzbyBJJ20gZ29pbmcgdG8gbWFyayB0 aGUgZHJhZnQgYXMgDQogICAgICAgID4gUkVBRFkgV0lUSCBOSVRTLg0KICAgICAgICA+IA0KICAg ICAgICA+IEl0IGFwcGVhcnMgdGhhdCB0aGVyZSdzIGEgcmFmdCBvZiBkcmFmdHMgb2YgTElTUCBk b2N1bWVudHMgcHJvZ3Jlc3NpbmcgDQogICAgICAgID4gdG9nZXRoZXIgdGhyb3VnaCB0aGUgV0cg dGhhdCBjcm9zcy1yZWZlcmVuY2UgZWFjaCBvdGhlciBpbiB0aGF0IHRoZXkgYWxsIA0KICAgICAg ICA+IHByb3ZpZGUgZm91bmRhdGlvbiBhbmQgc3VwcG9ydCBmb3IgdGhlaXIgY29sbGVjdGl2ZSBm ZWF0dXJlcy4gKEknbGwgDQogICAgICAgID4gYWRtaXQgdGhhdCBJIGhhdmVuJ3QgYmVlbiBrZWVw aW5nIHVwLikgU28gaWYgbXkgbml0cyBoYXZlIGJlZW4gYWRkcmVzc2VkIA0KICAgICAgICA+IGlu IGFub3RoZXIgZG9jdW1lbnQsIHRoYXQganVzdCBtZWFucyB0aGF0IEkgZGlkbid0IGRpZyBmYXIg b3IgZGVlcCANCiAgICAgICAgPiBlbm91Z2ggc28gcGxlYXNlIGNvbnNpZGVyIGdpdmluZyBhIHBv aW50ZXIgaW4gdGhlIFNlY3VyaXR5IA0KICAgICAgICA+IENvbnNpZGVyYXRpb25zIG9mIHRoaXMg ZG9jdW1lbnQgc28gb3RoZXJzIHdvbid0IHNpbWlsYXJseSBiZSBsZWZ0IGFkcmlmdC4NCiAgICAg ICAgPiANCiAgICAgICAgPiBJbiB0aGlzIGRvY3VtZW50LCBhbmQgdGhlIGFzc29jaWF0ZWQgb3Ro ZXJzIHRoYXQgSSBwZWVyZWQgaW50bywgdGhlIHRlcm0gDQogICAgICAgID4gIm5vbmNlIiBzZWVt cyB0byBiZSB1c2VkIG1vcmUgYXMgYSAidG9rZW4iIHRoYW4sIHdlbGwsIHdoYXQgSSBjb25zaWRl ciANCiAgICAgICAgPiB0byBiZSBhIG5vbmNlLiBJbiBvbmUgY2FzZSBpdCBtYXkgYmUgYSByYW5k b20gdmFsdWUsIGJ1dCBpbiBzZXZlcmFsIA0KICAgICAgICA+IG90aGVycyB0aGUgdmFsdWUgaXMg c3RvcmVkLCBjb21wYXJlZCwgYW5kIHJldXNlZC4gIFRoaXMgaXMgaW5jb25zaXN0ZW50IA0KICAg ICAgICA+IHdpdGggdGhlIElFVEYncyBTZWN1cml0eSBHbG9zc2FyeSBSRkMgNDk0OS4NCiAgICAg ICAgPiANCiAgICAgICAgPiBBbHNvLCB0aGVyZSBpcyBhIHJlZmVyZW5jZSB0byBpbmNyZWFzaW5n IHRoZSBub25jZSBmb3IgYSBwYXJ0aWN1bGFyIHVzZS4gDQogICAgICAgID4gSG93ZXZlciwgSSBz YXcgbm8gZGlzY3Vzc2lvbiBvZiB3aGF0IHRvIGRvIHdoZW4gdGhlIHZhbHVlIGV4Y2VlZHMgdGhl IA0KICAgICAgICA+IGZpZWxkIHNwYWNlLg0KICAgICAgICA+IA0KICAgICAgICA+IE90aGVyIHRo YW4gdGhhdCwgdGhlIGRvY3VtZW50IGFwcGVhcnMgdG8gYmUgd2VsbCB3cml0dGVuIGFuZCB3ZWxs IA0KICAgICAgICA+IHRob3VnaHQgb3V0Lg0KICAgICAgICA+IA0KICAgICAgICA+IEJlc3QgcmVn YXJkcywNCiAgICAgICAgPiANCiAgICAgICAgPiBDaHJpcw0KICAgICAgICA+IA0KDQoNCg== From nobody Mon Jan 11 14:33:47 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 1DC9B3A1407; Mon, 11 Jan 2021 14:33:45 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8FQk9mVej-P; Mon, 11 Jan 2021 14:33:43 -0800 (PST) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 9AB763A1405; Mon, 11 Jan 2021 14:33:43 -0800 (PST) Received: by mail-pj1-x1029.google.com with SMTP id w1so572329pjc.0; Mon, 11 Jan 2021 14:33:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=M4I8jtnv7xImYwsSozsiDQCEtoVbYkVdJ8KfBhKhMpo=; b=DnBcmwYtV/w649vGM2r5cTWBzhlflEWuaKWMyIh47Zqjs73a11Rq2gnExFDYveFcdM 7rsieSqJKas+4MeGdFhnrynq6eVhCu73YWSLKO6oofDCONZGwLkS2Noj0FnYTLFVIlZd 1PuDUCCjc42KJVRChCvVf3X0Sj/pMEbXsjMukivmnPukFRhmV9DO91qg9SxgXyETGWRX A55o44zYRshRFGwN3sqRd+hqw0ahd6vx5sod+/X3S9IEkc9m8BtXalKjhInJZ2QA6rKQ mRsw0oQQCPmWsJbxfx2aFsD3wczEhf2nJx/p6kiYy8+Prskr04dHpxZ89cYevNtPfb4Y RE4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=M4I8jtnv7xImYwsSozsiDQCEtoVbYkVdJ8KfBhKhMpo=; b=sH31XNby7A1o4675NKfqX5wuynJridT8v9yr+otUo+WE1jgahDSSMJPOTP57mhFpGq eCiNfcu/Uz8cYuhKgI+yIqfX0eWFqnpcXpO/DCQWzfnVbNBV6oHj9oQAB+zBlffq+7gz noNyl67CwVGryE+hPW6Yl2O/2Mbd/1kl/Nya3P6AG2Kt+xf5GrelTmqg/g8DFAFgO/0T TcAS8omq0dLPCvPUS6vyScJOrUVrMCjiSkA9fDm3+0kx//hma5d6FMKjdYxz1aVcepX9 8AUyfJ2fnGOdrlPx++HyW8vJCHdskolixefnaOTETw7CO1Mt/ywVl7eCeEEMsoFUr2Lw WJqQ== X-Gm-Message-State: AOAM533RuMAaADKAm9CdryclW2/hNPr9+AwvbHrHkKKnQGzg2USOJ7Uo 4SmPCgMy7/YNBLH1sP1HVMg+sOUDHflGlg== X-Google-Smtp-Source: ABdhPJyrlYP/BQpj58EvzXBWK8ngPcxRsMH/RTzOKmL1GHEr7ZPVo9eJ8jIRijjHeO6Z9ExxfDXvfQ== X-Received: by 2002:a17:90a:77c1:: with SMTP id e1mr1083231pjs.141.1610404422715; Mon, 11 Jan 2021 14:33:42 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:e175:6fe0:4eec:fb3f? ([2601:647:5600:5020:e175:6fe0:4eec:fb3f]) by smtp.gmail.com with ESMTPSA id g202sm610844pfb.196.2021.01.11.14.33.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jan 2021 14:33:42 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_47549E24-45E9-43DB-8866-52AC301DE797" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <83EC60B7-4D1E-4FD2-8A00-7FB38B496F9B@gmail.com> Date: Mon, 11 Jan 2021 14:33:40 -0800 Cc: ops-dir@ietf.org, netconf-chairs To: secdir@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [secdir] SecDir review 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 Jan 2021 22:33:45 -0000 --Apple-Mail=_47549E24-45E9-43DB-8866-52AC301DE797 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi SecDir, I had requested a SecDir review of three documents back in July of last = year. This is for: - draft-ietf-netconf-crypto-types-18 = - draft-ietf-netconf-keystore-20 = - draft-ietf-netconf-trust-anchors-13 = While some have had a review each, the last call review is missing in = one case. And where the review has been done, and the author has = responded to the comments, there has been no follow-up on that thread. = Would it possible to have the LC review done for = draft-ietf-netconf-crypto-types, and finish up with a yes/no/more = comments on the changes proposed for the other two drafts. Thanks. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_47549E24-45E9-43DB-8866-52AC301DE797 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi SecDir,

I had requested a SecDir review of = three documents back in July of last year. This is for:

- draft-ietf-netconf-crypto-types-18
- draft-ietf-netconf-keystore-20
- draft-ietf-netconf-trust-anchors-13

While some have had a = review each, the last call review is missing in one case. And where the = review has been done, and the author has responded to the comments, = there has been no follow-up on that thread. Would it possible to have = the LC review done for draft-ietf-netconf-crypto-types, and finish up = with a yes/no/more comments on the changes proposed for the other two = drafts.

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_47549E24-45E9-43DB-8866-52AC301DE797-- From nobody Mon Jan 11 14:44: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 DAF7A3A142D; Mon, 11 Jan 2021 14:44:27 -0800 (PST) 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 UfvLqz_KRwRk; Mon, 11 Jan 2021 14:44:26 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 67DC63A142B; Mon, 11 Jan 2021 14:44:26 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id i7so117336pgc.8; Mon, 11 Jan 2021 14:44:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vmnXqmIuNHUE7/HaXg/W+nKoZJJp2QDJQcPi5K1E8rg=; b=QAh0EZBcWyL7Ep6Y+6XMzzf2/5n4qT2kFDvyY39ZzarBfpWqbTt9gjWZRSSjpGfW+P BXjhK+ZDo/iTjRpX2FqDTQWrX4Sg4R02gshzM2pP3tGCR6ovAffTMC/OiWIs9Z3IcrTZ 3r9IMs6Ne5HNPutVD4rFQvMnXCBvgR0/3Gb3cBT4C5AweytDUMC0V6vfzX5FZeW7GjgO 4wqpwYC7IjkyARw7txrN+muRPIv4KjUZKhiyJR4GuS5LL9izAOZQwzByyrFQMASU1bXL GgBUdzRz1+H5QGrl1G9XVgWjzR4d2u2VxuG8acfWWd584G5bDzi6tlAjWNGUagk/uu8E hcfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vmnXqmIuNHUE7/HaXg/W+nKoZJJp2QDJQcPi5K1E8rg=; b=uT//bBtPWBr9kCOHayZP5zEkLeXIGDIVwAZ9qFmC5+22dqSRCYTpVaqW+ryTU4e/LM 1mHiK67sIFPkI40nte+GdvQh2yC1X9xZxndV9N9aiNw7BPOm8j4YLzB65otaweQurPc0 y+cIK87D6TBILG1iS7OFdRRdZVY49hfpAvYWto5BHROn9JRsN8yknhyP1zRqCKWyx1Ss lvJ0RSOySVeWXo+VL9zEZAvZGtSrTPQ/nAsfhpSfUiQj1J681Hv11H+eHZrkcyv3tsma 8zrTO1lYzwY7/vDukrfkC3vJSvHJHIwSPsjRwfqPgaFrpII0Hzc+asMl/6iTiXs5IPIA j5Mw== X-Gm-Message-State: AOAM530h2NtE+MkgPVgZXDmdMknf9+7KuzDkkLbMOoyjDWtFflZFJp// zEyfNOvoEFIS47fAcC/abRlW0wnzckKSpw== X-Google-Smtp-Source: ABdhPJxSjRpbhw/L+a88XeAMqXx+Pk+592sok3mJSs3NBZstgmsbCZeqJKNOIKQLaQevT2ODO0RKkw== X-Received: by 2002:a63:ec4f:: with SMTP id r15mr1638865pgj.344.1610405065657; Mon, 11 Jan 2021 14:44:25 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:e175:6fe0:4eec:fb3f? ([2601:647:5600:5020:e175:6fe0:4eec:fb3f]) by smtp.gmail.com with ESMTPSA id p17sm661553pfn.52.2021.01.11.14.44.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jan 2021 14:44:24 -0800 (PST) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1CBC5712-D68E-4E4F-A387-E9E59D132649" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 11 Jan 2021 14:44:23 -0800 In-Reply-To: <83EC60B7-4D1E-4FD2-8A00-7FB38B496F9B@gmail.com> Cc: netconf-chairs , ops-ads@ietf.org To: secdir@ietf.org References: <83EC60B7-4D1E-4FD2-8A00-7FB38B496F9B@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [secdir] SecDir review 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 Jan 2021 22:44:28 -0000 --Apple-Mail=_1CBC5712-D68E-4E4F-A387-E9E59D132649 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Oops! This was meant to be Cc=E2=80=99ed to ops-ads. > On Jan 11, 2021, at 2:33 PM, Mahesh Jethanandani = wrote: >=20 > Hi SecDir, >=20 > I had requested a SecDir review of three documents back in July of = last year. This is for: >=20 > - draft-ietf-netconf-crypto-types-18 = > - draft-ietf-netconf-keystore-20 = > - draft-ietf-netconf-trust-anchors-13 = >=20 > While some have had a review each, the last call review is missing in = one case. And where the review has been done, and the author has = responded to the comments, there has been no follow-up on that thread. = Would it possible to have the LC review done for = draft-ietf-netconf-crypto-types, and finish up with a yes/no/more = comments on the changes proposed for the other two drafts. >=20 > Thanks. >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_1CBC5712-D68E-4E4F-A387-E9E59D132649 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Oops!= This was meant to be Cc=E2=80=99ed to ops-ads.

On Jan = 11, 2021, at 2:33 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Hi SecDir,

I had requested a SecDir review of = three documents back in July of last year. This is for:

- draft-ietf-netconf-crypto-types-18
- draft-ietf-netconf-keystore-20
- draft-ietf-netconf-trust-anchors-13

While some have had a = review each, the last call review is missing in one case. And where the = review has been done, and the author has responded to the comments, = there has been no follow-up on that thread. Would it possible to have = the LC review done for draft-ietf-netconf-crypto-types, and finish up = with a yes/no/more comments on the changes proposed for the other two = drafts.

Thanks.

Mahesh = Jethanandani
mjethanandani@gmail.com






Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_1CBC5712-D68E-4E4F-A387-E9E59D132649-- From nobody Wed Jan 13 11:06:34 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 C70AF3A129C; Wed, 13 Jan 2021 11:05:08 -0800 (PST) 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_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=nlnetlabs.nl 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 De8CxfKoBB09; Wed, 13 Jan 2021 11:05:06 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.218]) (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 720ED3A1298; Wed, 13 Jan 2021 11:05:05 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 891606028A; Wed, 13 Jan 2021 19:05:00 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1610564699; bh=Mxe129hQJFv+sChVkhMd+7WcVF4/V8UmokJVa5TkIYQ=; h=To:References:Cc:From:Subject:Date:In-Reply-To:From; b=ZwUpnUGeh16d090UfPInzS6NTg7AcjhLP5kPHoOTTRFe4LcEno6kifdOoeikLDMS1 qPAqa3qx403xOc7Ck87a0Aw7mhNUbHLhQOrlgXHJgta+DOHxXplTnWYt68Zc8dOoKF 5FBGNiZVhDfqpc6A+yIoLN5cj6wmwxq43ijAx0bidX8YUy8byBB3ZYUC6UTPCCkGIN xZBqnjufDYKjYV303NebtPGREVsQdMCBPDPuEe3B18mUrthfl7x7CbYZriCrQEEhkF c3R75eFM26LJD6fYVdYfcEjrE9nNCd0CNzKh+HTjibaQqkqUd8ftsV4iNLG3dRE2fx sSALrPVAqAZ8w== To: dnsop@ietf.org, secdir@ietf.org, The IESG References: <161054840211.9855.15826016027793522887@ietfa.amsl.com> Cc: Tim Wicinski , Stephen Farrell , Benjamin Kaduk From: Willem Toorop Message-ID: <7e12557e-985a-6139-2ac9-feeed32b9035@nlnetlabs.nl> Date: Wed, 13 Jan 2021 20:04:56 +0100 MIME-Version: 1.0 In-Reply-To: <161054840211.9855.15826016027793522887@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-05.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: Wed, 13 Jan 2021 19:05:09 -0000 Dear DNSOP, Stephen and Benjamin, After IESG evaluation it was decided that we needed to post a revised version of the DNS Server Cookies draft, with the DISCUSS position resolved. Also SECDIR review had a "Has Issues" result. This is that revised version. To resolve the SECDIR review issues and DISCUSS positions, this version has timing recommendations in section 4.3 and section 5 aligned, and has more/better text on the properties and requirements of the Server Cookie and the pseudorandom function used in its calculation. The document also has extra text around timestamp compares. Besides these blocking issues IESG provided a *lot* of COMMENTs and suggestions which we have (almost) all addressed. Below I have included a log of those changes. Stephen and Benjamin, could you please review and see if your Issues and DISCUSS positions are resolved, and if so, change those statuses? Thanks! Changes ======= Comments from Stephen Farrell: * Remove "strong" in "strong cookie" in section 1 * Point out more explicitly the Timestamp field is **unsigned** and tell RFC1982 handles difference in the future even in case of wrap-arounds. * Use an authoritative citation for SipHash-2-4 Comments from Benjamin Kaduk: * Fix timing inconsistency of section 4.3 and section 5 * Motivate the use of SipHash-2-4 as pseudorandom function * Consolidate everything after the first paragraph in the Abstract into a single second paragraph * Single implementation no anycast services also benefit for a well- studies algorithm * Avoid the word 'nonce' with Client Cookies * Language style improvements in "tracking of Client Cookies prevention" description * Make the single server case more explicit in Server Cookie construction description * A DNS Server MAY generate a new Server Cookie more often than every half hour * Length verification of Server Cookies so byte string input into SipHash-2-4 is injective and not susceptible to data substitution \ attacks. * Explain how different Client Cookie for each server provides minimal authentication (in Section 3) * Provide Security Considerations for Server Cookies * Mention Timestamp values in test vector examples * Miscellaneous other minor editorial suggestions Comments from Erik Kline: * Section 1: s/in a Client protecting fashion/in a privacy protecting fashion/ * Section 8: s/five minute/five minutes/ * Mention that "tracking of the public IP of a NAT" is beyond the scope of this document Comments from Roman Danyliw: * Use an authoritative citation for SipHash-2-4 * Be clear on the notation of SipHash-2-4 (with dashes) Comments from Murray Kucherawy: * Fix linebreaks in section 7 * Remove Section 1.1 "Contents of this document" Comments from Barry Leiba: * Suggest implementation-defined period of time to renew Client Cookie (with one year as the maximum limit) * Implementations MUST set reserved bits to 0 when constructing a cookie (but not when verifying!) Comments from Éric Vyncke: * Fix capitalization of "client" and "server" * More consistent summary of the types of attacks * Mention that "tracking of the public IP of a NAT" is beyond the scope of this document Comments from Robert Wilton: * Suggest implementation-defined period of time to renew Client Cookie (with one year as the maximum limit) * Repeat that "Changing the Server Secret regularly is RECOMMENDED" in Section 5 Cheers, -- Willem Op 13-01-2021 om 15:33 schreef internet-drafts@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : Interoperable Domain Name System (DNS) Server Cookies > Authors : Ondrej Sury > Willem Toorop > Donald E. Eastlake 3rd > Mark Andrews > Filename : draft-ietf-dnsop-server-cookies-05.txt > Pages : 18 > Date : 2021-01-13 > > Abstract: > DNS Cookies, as specified in [RFC7873], are a lightweight DNS > transaction security mechanism that provide limited protection to DNS > servers and clients against a variety of amplification denial of > service, forgery, or cache poisoning attacks by off-path attackers. > > This document updates [RFC7873] with precise directions for creating > Server Cookies so that an anycast server set including diverse > implementations will interoperate with standard clients, suggestions > for constructing Client Cookies in a privacy preserving fashion, and > suggestions on how to update a Server Secret. An IANA registry > listing the methods and associated pseudo random function suitable > for creating DNS Server Cookies is created, with the method described > in this document as the first and as of yet only entry. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dnsop-server-cookies-05.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-server-cookies-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From nobody Fri Jan 15 02:00:54 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 998F83A0A2C; Fri, 15 Jan 2021 02:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Q72lozbTpWyD; Fri, 15 Jan 2021 02:00:43 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D77B3A0B5B; Fri, 15 Jan 2021 02:00:38 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 4DHGs04QpHz1yQd; Fri, 15 Jan 2021 11:00:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1610704836; bh=TzL80jkRxx1oi7RX02gj0AW4k6tMqcs1DIh117P+MEc=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=NTF9XXqUHmYlQOaFkAYSCSitwMg1rUmgQRTUc4ZG0GxYNwkNALJ9TydB/B1jcEOdN uKi3YAPuI5WCJge/d5+rIeX6R9R1FCneqcs38oejQvCmZFucPch3ZP/aHzfZ+9jlUB r/nsnYMRXNHMlKwsketHvMuFaoT/MMtk/lEwhHcjjcFPAXOmgwRJ4W+kzjkWzZrPlE 0zcRmDeXjBtWcuLOwjzHBLlfvvTzOezHHZC2eHTud4ebnDJEQ/UAOaHhiCZNq6VnPi T+r6W/8QadBPCs+2YgyPAJ7EXF4WcaQ8YNnxVlWesZKvm+PxYSxVoiT1YncMuQbjCI 0ecCq8eoa0CVg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4DHGs03Z6tzDq7q; Fri, 15 Jan 2021 11:00:36 +0100 (CET) From: To: Linda Dunbar CC: "idr@ietf.org" , "draft-ietf-idr-bgp-optimal-route-reflection.all@ietf.org" , "secdir@ietf.org" Thread-Topic: Secdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21 Thread-Index: AQHW05nMtPHeXE3QG0yBotQbgi8tFqn51+8QgC681mA= Date: Fri, 15 Jan 2021 10:00:35 +0000 Message-ID: <4946_1610704836_600167C4_4946_353_17_53C29892C857584299CBF5D05346208A49094589@OPEXCAUBM43.corporate.adroot.infra.ftgroup> References: <160806937175.20796.7391460851134145603@ietfa.amsl.com> <19398_1608116052_5FD9E754_19398_452_23_53C29892C857584299CBF5D05346208A49056412@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21 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, 15 Jan 2021 10:00:52 -0000 SGkgTGluZGEsDQoNCg0KPiBGcm9tOiBMaW5kYSBEdW5iYXIgW21haWx0bzpsaW5kYS5kdW5iYXJA ZnV0dXJld2VpLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxNiwgMjAyMCA0OjM4 IFBNDQo+IA0KPiBCcnVubywNCj4gDQo+IFllcywgeW91ciBleHBsYW5hdGlvbiBtYWtlcyBzZW5z ZS4gSXQgd291bGQgYmUgdXNlZnVsIHRvIGFkZCB5b3VyDQo+IGV4cGxhbmF0aW9uIHRvIHRoZSBT ZWN1cml0eSBDb25zaWRlcmF0aW9uLg0KDQoNCkFzIGEgZm9sbG93IHVwLCBGWUksIHdlIGhhdmUg anVzdCBwdWJsaXNoZWQgcmV2aXNpb24gLTIyLg0KDQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0 YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWlkci1iZ3Atb3B0aW1hbC1yb3V0ZS1yZWZsZWN0aW9uLw0KPiBBIGRp ZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6IGh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWlkci1iZ3Atb3B0aW1hbC1yb3V0ZS1y ZWZsZWN0aW9uLTIyDQoNCk5vdGUgdGhhdCAtMjIsIGhlbmNlIHRoZSBkaWZmLCBhbHNvIGluY2x1 ZGVzIG90aGVyIGNvbW1lbnRzLg0KDQpGb2xsb3dpbmcgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRz LCB3ZSBzZWVtIHRvIGJlIGluIHN5bmMgd2l0aCByZWdhcmRzIHRvIHRoZSBhbmFseXNpcy4gKGRp c2N1c3NlZCBvbiB0aGUgbGlzdCBhbmQgY29waWVkIGJlbG93KS4gaS5lLiB0aGF0IHRoZSB1c2Ug b2YgYSBkaWZmZXJlbnQgSUdQIGxvY2F0aW9uICB0byBjb21wdXRlIHRoZSBpbnRlcmlvciBjb3N0 IHRvd2FyZCB0aGUgQkdQIG5leHQtaG9wIGRvZXMgbm90IGNoYW5nZSB0aGUgdW5kZXJseWluZyBz ZWN1cml0eSBpc3N1ZSBjb21wYXJlZCB0byB1c2luZyBCR1AgUm91dGUgUmVmbGVjdGlvbi4NCllv dSBwcm9wb3NlZCB0byBpbmNsdWRlIHRoYXQgc3BlY2lmaWMgYW5hbHlzaXMgaW4gdGhlIHNlY3Vy aXR5IHNlY3Rpb24gaW4gdGhlIGRyYWZ0Lg0KVGhlIG1haW4gcG9pbnQgaXMgdGhhdCBpZiBhbiBh dHRhY2tlciBjYW4gbW9kaWZ5IHRoZSBjb25maWd1cmF0aW9uIG9mIHRoZSByb3V0ZXIsIGJhZCB0 aGluZ3MgbWF5IGhhcHBlbi4NClRoYXQgcG9pbnQgc2VlbSBnZW5lcmFsbHkgdmFsaWQgZm9yIGFs bCBmZWF0dXJlcyBhbGxvd2luZyBjb25maWd1cmF0aW9uIG9mIHBhcmFtZXRlcnMsIGluIHBhcnRp Y3VsYXIgdG8gQkdQIGFuZCBCR1AgUlIsIHNvIGluIG90aGVyIHdvcmQgbm90IHNwZWNpZmljIHRv IHRoaXMgZG9jdW1lbnQuDQpXZSBkaXNjdXNzZWQgdGhhdCBzdWdnZXN0aW9uIGFtb25nIGF1dGhv cnMsIGFuZCBhdCB0aGlzIHBvaW50IHdlIGRvbid0IGZlZWwgdGhhdCB0aGlzIHRleHQgc3BlY2lm aWNhbGx5IGJlbG9uZ3MgdG8gdGhpcyBkb2N1bWVudC4gDQpXZSdsbCB3YWl0IGZvciBtb3JlIGZl ZWRiYWNrIG9uIHRoaXMgcG9pbnQuIA0KDQpUaGFua3MgYWdhaW4gZm9yIHlvdXIgcmV2aWV3IGFu ZCBjb21tZW50cy4NCg0KLS1CcnVubw0KDQogDQo+IFRoYW5rIHlvdS4NCj4gDQo+IExpbmRhDQo+ IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBicnVuby5kZWNyYWVuZUBv cmFuZ2UuY29tIDxicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPg0KPiBTZW50OiBXZWRuZXNkYXks IERlY2VtYmVyIDE2LCAyMDIwIDQ6NTQgQU0NCj4gVG86IExpbmRhIER1bmJhciA8bGluZGEuZHVu YmFyQGZ1dHVyZXdlaS5jb20+OyBzZWNkaXJAaWV0Zi5vcmcNCj4gQ2M6IGlkckBpZXRmLm9yZzsg ZHJhZnQtaWV0Zi1pZHItYmdwLW9wdGltYWwtcm91dGUtcmVmbGVjdGlvbi5hbGxAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUkU6IFNlY2RpciBlYXJseSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pZHItYmdw LW9wdGltYWwtcm91dGUtDQo+IHJlZmxlY3Rpb24tMjENCj4gDQo+IEhpIExpbmRhLA0KPiANCj4g VGhhbmtzIGZvciB5b3VyIHJldmlldy4NCj4gUGxlYXNlIHNlZSBjb21tZW50cyBpbiBsaW5lDQo+ IA0KPiA+IEZyb206IExpbmRhIER1bmJhciB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5 QGlldGYub3JnXQ0KPiA+DQo+ID4gUmV2aWV3ZXI6IExpbmRhIER1bmJhcg0KPiA+IFJldmlldyBy ZXN1bHQ6IEhhcyBOaXRzDQo+ID4NCj4gPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBh cyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzDQo+ID4gb25nb2luZyBlZmZvcnQg dG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlDQo+ID4g SUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5l Zml0IG9mIHRoZQ0KPiA+IHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLg0KPiA+ICBEb2N1bWVudCBl ZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlr ZQ0KPiA+IGFueSBvdGhlciAgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPiA+DQo+ID4gVGhpcyBkb2N1 bWVudCBhbHRlcnMgaG93ICBCR1AgUm91dGUgUmVmbGVjdG9yIGNvbXB1dGVzIHRoZSBvcHRpbWFs DQo+ID4gcm91dGVzIG9uIGJlaGFsZiBvZiBjbGllbnRzLiBJbnN0ZWFkIHVzaW5nIGl0cyBvd24g SUdQIGNvc3QgdG8gdGhlIEFTDQo+ID4gRXhpdCBwb2ludHMsIHRoZSBkb2N1bWVudCBkZXNjcmli ZXMgdGhlIHN0ZXBzIGZvciBSUiB0byBjb21wdXRlIHRoZQ0KPiA+IG9wdGltYWwgcm91dGUgYnkg dXNpbmcgQ2xpZW50cycgcG9zaXRpb24gdG8gdGhlIEFTIEV4aXQgcG9pbnRzLiBUaGUNCj4gPiBk ZXNjcmliZWQgbWV0aG9kIGlzIHVzZWZ1bCB3aGVuIFJSIGlzIGNlbnRyYWxpemVkLiAgRm9yIGRl cGxveW1lbnQNCj4gPiB3aXRoIGRpc3RyaWJ1dGVkIFJSIGNsb3NlciB0byB0aGUgY2xpZW50cywg dGhlIGRlc2NyaWJlZCBtZXRob2QNCj4gPiBkb2Vzbid0IGhhdmUgYW55IGJlbmVmaXRzLg0KPiA+ DQo+ID4gU2VjdXJpdHkgQ29uY2VybjoNCj4gPiBJZiBSUidzIGluZm9ybWF0aW9uIG9mIGl0cyBj bGllbnRzIHRvcG9sb2d5IGlzIGNvbXByb21pc2VkLCB0aGVuIHRoZQ0KPiA+IG9wdGltYWwgcGF0 aHMgc2VsZWN0ZWQgYnkgdGhlIFJSIG1pZ2h0IG5vdCBiZSBhY2N1cmF0ZSBhbnltb3JlLg0KPiAN Cj4gSSBhZ3JlZSB3aXRoIHRoZSBhbmFseXNpcy4NCj4gQnV0IGl0J3Mgbm90IGNsZWFyIHRvIG1l IHdoZXRoZXIgeW91IGFyZSBhc2tpbmcgc29tZXRoaW5nIHRvIGJlIGFkZGVkIGluIHRoZQ0KPiBk cmFmdC4NCj4gSSdtIHNlZWluZyB0d28gY2FzZXM6DQo+IC0gSWYgdGhlIHNlbGVjdGVkIElHUCBs b2NhdGlvbiBpcyBjb25maWd1cmVkIG9uIHRoZSByb3V0ZXIgKFJSKSwgdGhlIGF0dGFjaw0KPiBy ZXF1aXJlcyB0aGUgYWJpbGl0eSB0byBjaGFuZ2UgdGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIHJv dXRlci4gSWYgYW4gYXR0YWNrZXINCj4gY2FuIGRvIHRoaXMsIGl0IGNhbiBkbyB2aXJ0dWFsbHkg YW55dGhpbmcgKHdpdGhpbiB0aGUgcm91dGVyIGNhcGFiaWxpdHkpLiBJIGRvbid0DQo+IGZlZWwg dGhhdCAic2VjdXJpbmcgYWNjZXNzIHRvIHRoZSByb3V0ZXIgY29uZmlndXJhdGlvbiIgaXMgYSB0 eXBpY2FsIHBvaW50IGFkZGVkDQo+IGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIGFsdGhv dWdoIGl0IHByb2JhYmx5IGFwcGxpZXMgdG8gbWFueQ0KPiBkb2N1bWVudHMuDQo+IC0gSWYgdGhl IHNlbGVjdGVkIElHUCBsb2NhdGlvbiBpcyBpbXBsaWNpdCBieSB1c2luZyB0aGUgSVAgYWRkcmVz cyBvZiB0aGUgY2xpZW50DQo+IElCR1Agc2Vzc2lvbiB0aGVyZSBpcyBubyBuZXcgdGhpbmcgdG8g Y29tcHJvbWlzZS4NCj4gDQo+IA0KPiA+IE1pbm9yIG5pdHM6DQo+ID4gUGFnZSA3OiBTZWN0aW9u IDMuMi4NCj4gPg0KPiA+ICJJZiB0aGUgcm91dGluZyByb3V0aW5nIG9wdGltaXphdGlvbiByZXF1 aXJlcyAuLi4iDQo+ID4gSXMgaXQgYSB0eXBvPyBkdXBsaWNhdGVkIHdvcmQgInJvdXRpbmciPw0K PiA+DQo+ID4gTGFzdCBzZW50ZW5jZTogIlRoaXMgbmVlZGVkIGZvciB1c2UgY2FzZXMgLi4uIg0K PiA+IERvIHlvdSBtZWFuICJUaGlzIGlzIG5lZWRlZCBmb3IgdXNlIGNhc2VzIC4uLiINCj4gDQo+ IFRoYW5rcyBmb3IgdGhlIG5pdHMuDQo+IENvcnJlY3RlZCBpbiBteSBsb2NhbCB2ZXJzaW9uLg0K PiANCj4gIENoZWVycywNCj4gLS1CcnVubw0KPiANCj4gPiBDaGVlcnMsDQo+ID4gTGluZGEgRHVu YmFyDQo+ID4NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gX19fX18NCj4gDQo+IENlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPiBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRy ZSBkaWZmdXNlcywgZXhwbG9pdGVzDQo+IG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleg0KPiBsZSBzaWdu YWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMNCj4gbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZQ0KPiByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+IA0K PiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZA0KPiBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsDQo+IHVzZWQgb3IgY29waWVkIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUNCj4gdGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuDQo+IG1vZGlmaWVk LCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gVGhhbmsgeW91Lg0KPiANCj4gDQo+IDxwPjwvcD4N CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl bmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBu ZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwg dmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1l cmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5 IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo b3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3Qg bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Fri Jan 15 14:54:18 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 C98783A12BD; Fri, 15 Jan 2021 14:54:12 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 Dtbi-B2_seHY; Fri, 15 Jan 2021 14:54:11 -0800 (PST) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 89F403A12B9; Fri, 15 Jan 2021 14:54:08 -0800 (PST) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QMZ02L4MZM840@wwwlocal.goatley.com>; Fri, 15 Jan 2021 16:54:08 -0600 (CST) Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QMZ001DCZJQYA@trixy.bergandi.net>; Fri, 15 Jan 2021 14:52:39 -0800 (PST) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Fri, 15 Jan 2021 14:52:39 -0800 Date: Fri, 15 Jan 2021 14:54:06 -0800 From: Dan Harkins To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-rtgwg-policy-model.all@ietf.org Message-id: <840eec63-03f7-2358-418a-0f42589b746f@lounge.org> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_6h1GXm5e84u8NJltAwQyzw)" Content-language: en-US User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local) X-PMAS-Software: PreciseMail V3.3 [210112b] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: [secdir] secdir review of draft-ietf-rtgwg-policy-model-27 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, 15 Jan 2021 22:54:13 -0000 This is a multi-part message in MIME format. --Boundary_(ID_6h1GXm5e84u8NJltAwQyzw) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 8BIT Hello! I have reviewed draft-ietf-rtgwg-policy-model-027 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 draft defines a YANG model for routing policy configuration. It does not attempt to define every possible configuration but, instead, some common policy configurations that are used presently. I am not a YANG guy and will defer to the relevant doctors on that matter but the draft looks like it adequately describes the subset it set out to. The security considerations note that data defined in the document are to be accessed using either SSH or TLS (1.3!). Kudos to authors for pointing out data nodes that are sensitive and need special attention. The language should be adequate for an implementer to take heed.   The summary of the review is READY. regards, Dan. -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius --Boundary_(ID_6h1GXm5e84u8NJltAwQyzw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: 8BIT 
  Hello!

  I have reviewed draft-ietf-rtgwg-policy-model-027 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 draft defines a YANG model for routing policy configuration. It
does not attempt to define every possible configuration but, instead, 
some common policy configurations that are used presently. I am not a
YANG guy and will defer to the relevant doctors on that matter but the
draft looks like it adequately describes the subset it set out to. 

  The security considerations note that data defined in the document are
to be accessed using either SSH or TLS (1.3!). Kudos to authors for
pointing out data nodes that are sensitive and need special attention.
The language should be adequate for an implementer to take heed. 

  The summary of the review is READY.

  regards,

  Dan.

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius
--Boundary_(ID_6h1GXm5e84u8NJltAwQyzw)-- From nobody Fri Jan 15 15:08: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 9919D3A12E8 for ; Fri, 15 Jan 2021 15:08:57 -0800 (PST) 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.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <161075213760.25134.9417452761006264840@ietfa.amsl.com> Date: Fri, 15 Jan 2021 15:08:57 -0800 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, 15 Jan 2021 23:08:58 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2021-01-21 Reviewer LC end Draft Russ Housley R2020-12-15 draft-ietf-bess-evpn-proxy-arp-nd Tero Kivinen R2020-01-06 draft-foudil-securitytxt Brian Weis R2020-12-02 draft-ietf-core-dev-urn Liang Xia 2020-11-30 draft-ietf-spring-sr-yang Last calls: Reviewer LC end Draft Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping Daniel Gillmor 2020-09-30 draft-ietf-ccamp-layer0-types Phillip Hallam-Baker 2020-12-03 draft-ietf-tls-ticketrequests Phillip Hallam-Baker 2020-09-30 draft-ietf-lwig-tcp-constrained-node-networks Steve Hanna 2020-09-30 draft-ietf-ccamp-wson-yang Dan Harkins None draft-ietf-rtgwg-policy-model Russ Housley R2020-12-15 draft-ietf-bess-evpn-proxy-arp-nd Leif Johansson None draft-ietf-netconf-crypto-types Leif Johansson 2020-10-02 draft-ietf-lpwan-schc-over-lorawan Tero Kivinen R2020-01-06 draft-foudil-securitytxt Watson Ladd None draft-ietf-rift-applicability Chris Lonvick 2021-01-29 draft-ietf-pce-association-bidir Aanchal Malhotra 2021-01-26 draft-ietf-mpls-lsp-ping-registries-update David Mandelberg 2021-01-26 draft-ietf-mpls-rfc6374-sfl Catherine Meadows 2021-01-25 draft-ietf-dime-group-signaling Daniel Migault 2021-01-20 draft-ietf-extra-imap4rev2 Russ Mundy 2020-07-20 draft-ietf-ace-dtls-authorize Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Tirumaleswar Reddy.K 2020-11-16 draft-ietf-quic-transport Rich Salz R2020-08-14 draft-ietf-suit-architecture Brian Weis R2020-12-02 draft-ietf-core-dev-urn Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Christopher Wood R2021-01-18 draft-ietf-dtn-tcpclv4 Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model Liang Xia 2020-11-30 draft-ietf-spring-sr-yang Early review requests: Reviewer Due Draft Alexey Melnikov 2021-02-01 draft-ietf-idr-bgp-open-policy Dacheng Zhang 2020-12-07 draft-ietf-idr-eag-distribution Next in the reviewer rotation: Adam Montville Kathleen Moriarty Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Francesca Palombini Radia Perlman Derrell Piper From nobody Sun Jan 17 12:34: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 2012A3A138F for ; Sun, 17 Jan 2021 12:34:36 -0800 (PST) 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.org 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 4BgumN-2Ryfv for ; Sun, 17 Jan 2021 12:34:33 -0800 (PST) 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 8829E3A1390 for ; Sun, 17 Jan 2021 12:34:33 -0800 (PST) Received: by mail-pg1-x563.google.com with SMTP id g15so9646596pgu.9 for ; Sun, 17 Jan 2021 12:34:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:to:from:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=jh6rYDe2ZSMXBrw/SwwZ3UxCJexON66RhyWYAXXsMb8=; b=forsPbkwFJY7wj4H3kEC9NowfLTFMf0e8fAu96LGpiolSmOieEuVY1Y9YzE5DrpSUu 7Xn0r6/HraePK8n5T+7hwyElzGG0iAU3uzOLt9y1wl/Birhi+YXylWbFbRvgMEeNg9lb rPxRThbtGi4wevoUqHfZzvRyX/h4M4nkebYxg0PzFM2V/oOtTHu5YL7H9U3F9DOA/0Ma HLRT3Bqe0a0jsK5Jjk7/GtDn9i3S+OlRZwi5YdYShwHvQuin4xPTZFO8qdFlBiZMKXzI UMqARop7bvaPojABPGCEBbeGyRVXcTtgYxIBQvd6uM33pWIlXPp8ZLILH9U4//gnKAdI tGvg== X-Gm-Message-State: AOAM533TykxP5ZBBt6tCZbVMMRroI0OqDnX+R2AIWBHPCDVC3m0Dc0K5 EMIJzXWt9FiU4xM9qIVpDOBze7yNLLQGAaBk5bXDMJvv1nPXAg== X-Google-Smtp-Source: ABdhPJz6os5IwdBSwwZn2e8khRJwsBBEv1Nwbzf9IMHeL6ape5MH2hvocXc4yF3+5TkTMzIvxbTPkJfPJ5p0 X-Received: by 2002:a63:f013:: with SMTP id k19mr2458022pgh.151.1610915672882; Sun, 17 Jan 2021 12:34:32 -0800 (PST) Received: from uriel.mandelberg.org (pool-100-0-196-177.bstnma.fios.verizon.net. [100.0.196.177]) by smtp-relay.gmail.com with ESMTPS id t15sm1539068pjg.1.2021.01.17.12.34.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 17 Jan 2021 12:34:32 -0800 (PST) X-Relaying-Domain: mandelberg.org Received: from [192.168.1.162] (nevia [192.168.1.2]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 0ED4E1C605D; Sun, 17 Jan 2021 15:34:30 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=202009; t=1610915670; bh=7o937Nz2pZblSYXPsun2IFzh2cgrahaarp/knZlj/uo=; h=To:From:Subject:Date:From; b=iN/2ouhk3qvUOXgEKonQwGxQ5Ked049es0TzallMAgid0Sv0FIEFYyMFuXLe3RKZh Yo7xA9/N55TxeOs7EAqPvPErd3JkLstOlYpzXilEQz2AEMv110LbZ0swoL43wbRq56 0bxjXCBsT/PLFporSyEbj+dUzKyshanIN5eV8FxGePA9yvZHJywNnoBYPpF/VhByPh XGnlgPi89rgFYFq6GVqMv+2hMkXhxT3FCVfwZpghVcgscaWmWdgEiIjRA35+B/R+dz pA1XhaCMKv6khSsxyRQiLac6zJYmvKhzxv/SqsJV5Rr7KZIg2sldIOTOk05BSo9bbs Vd1Z7mjwgDtTQ== To: secdir@ietf.org, iesg@ietf.org, draft-ietf-mpls-rfc6374-sfl.all@ietf.org From: David Mandelberg Message-ID: <294add23-36e3-6587-312f-9d385e3c8f1b@mandelberg.org> Date: Sun, 17 Jan 2021 15:34:28 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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-mpls-rfc6374-sfl-08 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, 17 Jan 2021 20:34:36 -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. I'm not particularly familiar with many of the things referenced in the document, but I also didn't notice any security issues. From nobody Mon Jan 18 09:01:38 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 54DB73A0AFB; Mon, 18 Jan 2021 09:01:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley via Datatracker To: Cc: bess@ietf.org, draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161098928828.20265.4017617272159119319@ietfa.amsl.com> Reply-To: Russ Housley Date: Mon, 18 Jan 2021 09:01:28 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-bess-evpn-proxy-arp-nd-11 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 Jan 2021 17:01:29 -0000 Reviewer: Russ Housley Review result: Ready I 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 authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-bess-evpn-proxy-arp-nd-09 Reviewer: Russ Housley Review Date: 2021-01-18 IETF LC End Date: 2020-12-15 IESG Telechat date: 2021-01-21 Thank you for addressing my comments from the previous review. Summary: Ready Major Concerns: None Minor Concerns: None From nobody Mon Jan 18 18:08: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 4484A3A0F7F; Mon, 18 Jan 2021 18:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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 KffbXcWXpNq3; Mon, 18 Jan 2021 18:08:25 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3523A0C36; Mon, 18 Jan 2021 18:08:22 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id D4A0A28B003D; Mon, 18 Jan 2021 21:08:19 -0500 (EST) Received: from [127.0.0.1] (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id F3DE91F8051; Mon, 18 Jan 2021 21:08:16 -0500 (EST) From: Russ Mundy Content-Type: text/plain; charset=us-ascii X-Mao-Original-Outgoing-Id: 632714893.8317111-de1a95e47afac8a31a437be01a721229 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Message-Id: <4BED04D6-5BB6-4F7A-A0E5-3CC718E55169@tislabs.com> Date: Mon, 18 Jan 2021 21:08:15 -0500 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ace-dtls-authorize.all@ietf.org X-Mailer: Apple Mail (2.3445.9.7) Archived-At: Subject: [secdir] secdir review of draft-ietf-ace-dtls-authorize-14 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 Jan 2021 02:08:28 -0000 Datagram Transport Layer Security (DTLS) Profile for Authentication and = Authorization for Constrained Environments (ACE) draft-ietf-ace-dtls-authorize I apologize for the lateness of the review but 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 one issue: The draft-ietf-ace-dtls-authorize document is well written and provides = a very good profile for use of the ACE framework with a client and a = resource server use CoAP [RFC7252] over DTLS version 1.2 [RFC6347] to = communicate. The document provides the necessary specification details = to use Authentication and Authorization for Constrained Environments = (ACE) using the OAuth 2.0 Framework (ACE-OAuth) = [I-D.ietf-ace-oauth-authz] with one single exception. Since the document under review is a profile for = [I-D.ietf-ace-oauth-authz], it must meet the requirements for a profile = contained in [I-D.ietf-ace-oauth-authz]. Section 6.2 of = [I-D.ietf-ace-oauth-authz] specifically requires that "Profiles MUST = specify how communication security according to the requirements in = Section 5 is provided." The document under review does provide this = detail for use of CoAP and DTLS however the current wording of this = profile document does not require that CoAP and DTLS be used for this = profile. Quoting a part of 6. "The use of CoAP and DTLS for this = communication is RECOMMENDED in this profile, other protocols (such as = HTTP and TLS, or CoAP and OSCORE [RFC8613]) MAY be used instead." =20 Since use of other protocols (besides CoAP and DTLS) is clearly = permitted by current wording and there is no information about how = communication security will be provided by these other protocols, = section 6 of this profile does not appear to meet the MUST requirement = of 6.2 of [I-D.ietf-ace-oauth-authz]. The simplest resolution of this inconsistency appears to be to require = use of CoAP and DTLS for compliance with this profile and revise the = wording relating to the other currently listed protocols to define = additional profile specifications. For example, current wording:=20 "The use of CoAP and DTLS for this communication is RECOMMENDED in this = profile, other protocols (such as HTTP and TLS, or CoAP and OSCORE = [RFC8613]) MAY be used instead."=20 could be changed to:=20 "The use of CoAP and DTLS for this communication is REQUIRED in this = profile. Other protocols (such as HTTP and TLS, or CoAP and OSCORE = [RFC8613]) will require specification of additional profile(s)." Another possible resolution of the inconsistency would be to include = additional details in this specification to define how communication = security requirements will be met by these other protocols. From nobody Mon Jan 18 19:11: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 CB66F3A1092; Mon, 18 Jan 2021 19:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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=ericsson.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 jjpik2WU96yu; Mon, 18 Jan 2021 19:11:11 -0800 (PST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2072.outbound.protection.outlook.com [40.107.223.72]) (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 EC8053A0CBD; Mon, 18 Jan 2021 19:11:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kyRXfphVvc+fh85ye/tmY4R6tJx6TDC2og6bQsZ701XuNFFkELDZ4jelYwkEuYyKkD/jLHxgSLoUZHcxsFEhWcU0S398s41wzMs7iXbc7dT7w9e0isgfVBK/lddLF/h8hRKEt5lOWmoMVdZ2qG4v5BgtTJL2X6ygm2G2VUffR6uH45QPcQcqNGXiw4UMmJugCzyDoi7pkIjwkPkLvSue51NChPhKlzVvAWSL5BSHzOe9xmizaK4t2DKwurNNrXa/4O2BqDjcX8nszY+otVzANa8yf6juFiK0tCgJfbiggp7dtXfbNlYT+90xSCOY9NrVSPVtOOGAKeD03ro4fos/jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ka0urmNHLMSBRgRp7WuaBx7Bzh90x5okmxBZxiRTOe0=; b=dSfVIDNVaLBDOnDLNrsef/l+pV4/n5jClPsgb3qL7rYw0/EAD8y9XDCg+k2+TCc2j+o0ij59gj9d/oLsowbZgk09R8JqQM1RmGg43zGrq0iS/UUpfIZShm9jCpn5BiMhwYJSXS0cKfEc42iU2IuMbrl2maf5PJ17E9O1pRwLmVe0pu/svfjzI6CycJXgy9ahQ17abNX7Gvp++KFDQg8cLqBA07hXZ5n0yrpxgdRGZkiCX+M7lR95dTkUN3Hj5M/05ni/HITdcCw0M4w2yyId2d700CpnT5G9XWlC3FZRyj713NAjpKQgpgxYK9P8ESl04/BNwIjC38YhnozDavh63g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ka0urmNHLMSBRgRp7WuaBx7Bzh90x5okmxBZxiRTOe0=; b=ViKctnJkmBTb0AyorlcZigQxKjN6nFw+C4datrQlApy1ybVb9+vaXAWZd61hRCp9i03DPZ4wvBK5tOZtXxUI3PHlfMlzb743G5RPoQAiru+LEwCEpbtZ8zcy0fhsKCf9BwAB8tqFHg7fr7viLzy0z+56cc83v4HiIRjNuKI6CKA= Received: from DM6PR15MB2379.namprd15.prod.outlook.com (2603:10b6:5:8a::16) by DM5PR1501MB2136.namprd15.prod.outlook.com (2603:10b6:4:a3::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.9; Tue, 19 Jan 2021 03:11:06 +0000 Received: from DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::a9f9:326f:8cfb:157b]) by DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::a9f9:326f:8cfb:157b%7]) with mapi id 15.20.3763.014; Tue, 19 Jan 2021 03:11:06 +0000 From: Daniel Migault To: Russ Mundy , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-ace-dtls-authorize.all@ietf.org" Thread-Topic: secdir review of draft-ietf-ace-dtls-authorize-14 Thread-Index: AQHW7ggDkr/onBsVAESCM1Xz/nYaZ6ouRE3A Date: Tue, 19 Jan 2021 03:11:05 +0000 Message-ID: References: <4BED04D6-5BB6-4F7A-A0E5-3CC718E55169@tislabs.com> In-Reply-To: <4BED04D6-5BB6-4F7A-A0E5-3CC718E55169@tislabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tislabs.com; dkim=none (message not signed) header.d=none;tislabs.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [96.22.11.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5cc2f6b5-37d2-4384-68ce-08d8bc27dc68 x-ms-traffictypediagnostic: DM5PR1501MB2136: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ljXx2kL4rCLJuVWzOhBGhwS1eYchL7mQHzb5w0ZjHfi5jagADPz2F4ggUvg47NgJff/es0Pa4UllF33Qojuvtz/8Q1RHNB9Czon8S+NhhtHCh56EZjD/H/95PnRclHoOAPmN2cukN/qMNT4YhiHbszYBhfsnmYMCmm76z5Qr0PWKFlFNvGWVbRAop6zrMcTFLwsauwQpS+pS5aCi/gfSUijt4PsOmtwCXR6xWhOZ2Z0w8HwZDkC8wxnF27t5mKzdp0hT1Ly7K0TCFgoCfq9jSrNcu9o8mz20L+5UQiAo45l5n+7TUa9UFDMky/5+LAHmGmC9pcx6P7DrPNlzObXCHEt7oEwt0819MLkzeLyAV5YImPmDeYcNNNl8YraA7y3hFycafmLv+YcwxZd8Z4T8IA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR15MB2379.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(366004)(376002)(396003)(346002)(478600001)(86362001)(55016002)(19627405001)(2906002)(83380400001)(9686003)(26005)(6506007)(53546011)(7696005)(44832011)(186003)(110136005)(76116006)(91956017)(71200400001)(8936002)(66476007)(66556008)(64756008)(66946007)(52536014)(5660300002)(316002)(8676002)(66446008)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?p7B/FlaHHWaqSAOfCtmZcWEf8ZbIXHjpqnC1LWpr+YpdR/LY9LjoIaMzYKAq?= =?us-ascii?Q?tzwAlSF9YNvVM5aVQZej74EbrMVmG9D1kMbuNgDbul0huj4qVMnY2VzS7u8K?= =?us-ascii?Q?9bB8AHuABdb0bVHB7KU6qM0LQefNTKqq/tiQsVpZE3feMDCRgwwqcdAZFZcH?= =?us-ascii?Q?I330th2QmfHJotpAyPy/RUmjN0fOLS5yXpsbls8wStHHNjh7izELkiit02uL?= =?us-ascii?Q?rRCHwnefj3itYIS8t65upLvu1HK4jxfYsImwwrnqzrlaN+8D5MtsUJjG7Cem?= =?us-ascii?Q?/0WiSqRAlrBNzuEyyc4wnUL26f+mRKpJvRrJJ7QEsswa8m8tpTpLHdavKmNe?= =?us-ascii?Q?NVQ+ZrelpdciqYUMd+trXoLtbMYDtGYIRym5X9x1Y7SpiO7QNrsv0IqTKRwU?= =?us-ascii?Q?g4OBterMuTq469kDGZ53RUPMrdwxMv02R+0E9Wg4qURgMwhEnE/r81PVYpr8?= =?us-ascii?Q?cpG0g+GV4rakQyqz8sdQAPrBWkmEcwSAGmj67GrvBXKrPqWC93Jq4m7Mu1B1?= =?us-ascii?Q?HPd0m6XC4QriRtEEYKvOI3e9Kdd1nxEoCMsEaC+bqgbF6huCI8edj4RfI2qE?= =?us-ascii?Q?idYtpurytndAwTCO6NO5rT5rZyh4IpseQ1qDA4kTCe946I14s82ZUbJ2uB3m?= =?us-ascii?Q?kIZxyqK9Hm3M25Nyw+cVzQmIi+PX+snVgx9GjA4XiO2m3tbUHvUf8NhGuxK2?= =?us-ascii?Q?Pdt26hn0PlqmGnda0UDB/a1zkVo47UyYn48IfpnreOOcLuNGdh88oQpidQL+?= =?us-ascii?Q?pSqgG5qZJTQOgh6++JMH3ADIgr05VoyMisMlgSLhiusQqX6kclj0IwmFcYne?= =?us-ascii?Q?8uQdATVWDYjH2Q9DubjwIXNKBcwvgH4XONG/cTyxRp/RZODlkrasA86PuY15?= =?us-ascii?Q?I3VVMEyYFAWgLCl0t5eYDwPCKPTHkIb/OUjKEtEmnuk0nU9FEpCGWYpb1oLn?= =?us-ascii?Q?hK31vX63GN2D4ypxVwvsvdyGBB5gDLaeZqiaJ9tjv/U=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR15MB237984B44F9E6E407341BD0FE3A30DM6PR15MB2379namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR15MB2379.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5cc2f6b5-37d2-4384-68ce-08d8bc27dc68 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2021 03:11:05.9592 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RJ4+LvZaqvAiFAVlKiYHLtec44ltp9p2d2zvTDkqXKF7amFEwBqFMePGeE+VJZYrM18XYsLCHq0LFf1ZcQkLXHytNVfCcH45GYFJa23roRY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1501MB2136 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-ace-dtls-authorize-14 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 Jan 2021 03:11:13 -0000 --_000_DM6PR15MB237984B44F9E6E407341BD0FE3A30DM6PR15MB2379namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Russ for the review. I do get your comment - and had a similar comme= nt for the oscore profile. I will let the co-author to address your concern so the documents can be mo= ved forward shortly. Yours, Daniel ________________________________ From: Russ Mundy Sent: Monday, January 18, 2021 9:08 PM To: iesg@ietf.org ; secdir@ietf.org ; draft= -ietf-ace-dtls-authorize.all@ietf.org Cc: Russ Mundy Subject: secdir review of draft-ietf-ace-dtls-authorize-14 Datagram Transport Layer Security (DTLS) Profile for Authentication and Aut= horization for Constrained Environments (ACE) draft-ietf-ace-dtls-authorize I apologize for the lateness of the review but I have reviewed this documen= t as part of the security directorate's ongoing effort to review all IETF d= ocuments being processed by the IESG. These comments were written primaril= y 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 one issue: The draft-ietf-ace-dtls-authorize document is well written and provides a v= ery good profile for use of the ACE framework with a client and a resource = server use CoAP [RFC7252] over DTLS version 1.2 [RFC6347] to communicate. = The document provides the necessary specification details to use Authentica= tion and Authorization for Constrained Environments (ACE) using the OAuth 2= .0 Framework (ACE-OAuth) [I-D.ietf-ace-oauth-authz] with one single excepti= on. Since the document under review is a profile for [I-D.ietf-ace-oauth-authz]= , it must meet the requirements for a profile contained in [I-D.ietf-ace-oa= uth-authz]. Section 6.2 of [I-D.ietf-ace-oauth-authz] specifically require= s that "Profiles MUST specify how communication security according to the r= equirements in Section 5 is provided." The document under review does provi= de this detail for use of CoAP and DTLS however the current wording of this= profile document does not require that CoAP and DTLS be used for this prof= ile. Quoting a part of 6. "The use of CoAP and DTLS for this communication = is RECOMMENDED in this profile, other protocols (such as HTTP and TLS, or C= oAP and OSCORE [RFC8613]) MAY be used instead." Since use of other protocols (besides CoAP and DTLS) is clearly permitted b= y current wording and there is no information about how communication secur= ity will be provided by these other protocols, section 6 of this profile do= es not appear to meet the MUST requirement of 6.2 of [I-D.ietf-ace-oauth-au= thz]. The simplest resolution of this inconsistency appears to be to require use = of CoAP and DTLS for compliance with this profile and revise the wording re= lating to the other currently listed protocols to define additional profile= specifications. For example, current wording: "The use of CoAP and DTLS for this communication is RECOMMENDED in this pro= file, other protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) = MAY be used instead." could be changed to: "The use of CoAP and DTLS for this communication is REQUIRED in this profil= e. Other protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) wil= l require specification of additional profile(s)." Another possible resolution of the inconsistency would be to include additi= onal details in this specification to define how communication security req= uirements will be met by these other protocols. --_000_DM6PR15MB237984B44F9E6E407341BD0FE3A30DM6PR15MB2379namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks Russ for the review. I do get your comment - and had a similar comme= nt for the oscore profile.
I will let the co-author to address your concern so the documents can be= moved forward shortly.

Yours, 
Daniel
From: Russ Mundy <mundy@= tislabs.com>
Sent: Monday, January 18, 2021 9:08 PM
To: iesg@ietf.org <iesg@ietf.org>; secdir@ietf.org <secdir@= ietf.org>; draft-ietf-ace-dtls-authorize.all@ietf.org <draft-ietf-ace= -dtls-authorize.all@ietf.org>
Cc: Russ Mundy <mundy@tislabs.com>
Subject: secdir review of draft-ietf-ace-dtls-authorize-14
 
Datagram Transport Layer Security (DTLS) Profile f= or Authentication and Authorization for Constrained Environments (ACE)

draft-ietf-ace-dtls-authorize

I apologize for the lateness of the review but I have reviewed this documen= t as part of the security directorate's ongoing effort to review all IETF d= ocuments being processed by the IESG.  These comments were written pri= marily for the benefit of the security area directors.  Document editors and WG chairs should treat these co= mments just like any other last call comments.

The summary of the review is Ready with one issue:

The draft-ietf-ace-dtls-authorize document is well written and provides a v= ery good profile for use of the ACE framework with a client and a resource = server use CoAP [RFC7252] over DTLS version 1.2 [RFC6347] to communicate.&n= bsp; The document provides the necessary specification details to use Authentication and Authorization for Constrai= ned Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) [I-D.ietf-= ace-oauth-authz] with one single exception.

Since the document under review is a profile for [I-D.ietf-ace-oauth-authz]= , it must meet the requirements for a profile contained in [I-D.ietf-ace-oa= uth-authz].  Section 6.2 of [I-D.ietf-ace-oauth-authz] specifically re= quires that "Profiles MUST specify how communication security according to the requirements in Section 5 is provi= ded." The document under review does provide this detail for use of Co= AP and DTLS however the current wording of this profile document does not r= equire that CoAP and DTLS be used for this profile. Quoting a part of 6. "The use of CoAP and DTLS for this= communication is RECOMMENDED in this profile, other protocols (such as HTT= P and TLS, or CoAP and OSCORE [RFC8613]) MAY be used instead." 

Since use of other protocols (besides CoAP and DTLS) is clearly permitted b= y current wording and there is no information about how communication secur= ity will be provided by these other protocols, section 6 of this profile do= es not appear to meet the MUST requirement of 6.2 of [I-D.ietf-ace-oauth-authz].

The simplest resolution of this inconsistency appears to be to require use = of CoAP and DTLS for compliance with this profile and revise the wording re= lating to the other currently listed protocols to define additional profile= specifications.

For example, current wording:
"The use of CoAP and DTLS for this communication is RECOMMENDED in thi= s profile, other protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC86= 13]) MAY be used instead."

could be changed to:
"The use of CoAP and DTLS for this communication is REQUIRED in this p= rofile. Other protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]= ) will require specification of additional profile(s)."

Another possible resolution of the inconsistency would be to include additi= onal details in this specification to define how communication security req= uirements will be met by these other protocols.


--_000_DM6PR15MB237984B44F9E6E407341BD0FE3A30DM6PR15MB2379namp_-- From nobody Mon Jan 18 20:12: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 8AB123A1101; Mon, 18 Jan 2021 20:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 m01A-e4Gdy5E; Mon, 18 Jan 2021 20:12:02 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D0983A10FC; Mon, 18 Jan 2021 20:12:01 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 9D62D28B003B; Mon, 18 Jan 2021 23:11:58 -0500 (EST) Received: from [127.0.0.1] (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id 3DA5F1F8051; Mon, 18 Jan 2021 23:11:55 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3ABB02E3-3496-46E9-8F64-06A92EFC84A6" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) From: Russ Mundy In-Reply-To: Date: Mon, 18 Jan 2021 23:11:54 -0500 Cc: Russ Mundy , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-ace-dtls-authorize.all@ietf.org" X-Mao-Original-Outgoing-Id: 632722313.075123-3af266a50c6261dbfb4a78a7516294e9 Message-Id: References: <4BED04D6-5BB6-4F7A-A0E5-3CC718E55169@tislabs.com> To: Daniel Migault X-Mailer: Apple Mail (2.3445.9.7) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-ace-dtls-authorize-14 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 Jan 2021 04:12:05 -0000 --Apple-Mail=_3ABB02E3-3496-46E9-8F64-06A92EFC84A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Daniel, sounds good to me. Russ > On Jan 18, 2021, at 10:11 PM, Daniel Migault = > = wrote: >=20 > Thanks Russ for the review. I do get your comment - and had a similar = comment for the oscore profile. > I will let the co-author to address your concern so the documents can = be moved forward shortly. >=20 > Yours,=20 > Daniel > From: Russ Mundy > > Sent: Monday, January 18, 2021 9:08 PM > To: iesg@ietf.org >; secdir@ietf.org = >; = draft-ietf-ace-dtls-authorize.all@ietf.org = = > > Cc: Russ Mundy > > Subject: secdir review of draft-ietf-ace-dtls-authorize-14 > =20 > Datagram Transport Layer Security (DTLS) Profile for Authentication = and Authorization for Constrained Environments (ACE) >=20 > draft-ietf-ace-dtls-authorize >=20 > I apologize for the lateness of the review but 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. >=20 > The summary of the review is Ready with one issue: >=20 > The draft-ietf-ace-dtls-authorize document is well written and = provides a very good profile for use of the ACE framework with a client = and a resource server use CoAP [RFC7252] over DTLS version 1.2 [RFC6347] = to communicate. The document provides the necessary specification = details to use Authentication and Authorization for Constrained = Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) = [I-D.ietf-ace-oauth-authz] with one single exception. >=20 > Since the document under review is a profile for = [I-D.ietf-ace-oauth-authz], it must meet the requirements for a profile = contained in [I-D.ietf-ace-oauth-authz]. Section 6.2 of = [I-D.ietf-ace-oauth-authz] specifically requires that "Profiles MUST = specify how communication security according to the requirements in = Section 5 is provided." The document under review does provide this = detail for use of CoAP and DTLS however the current wording of this = profile document does not require that CoAP and DTLS be used for this = profile. Quoting a part of 6. "The use of CoAP and DTLS for this = communication is RECOMMENDED in this profile, other protocols (such as = HTTP and TLS, or CoAP and OSCORE [RFC8613]) MAY be used instead." =20 >=20 > Since use of other protocols (besides CoAP and DTLS) is clearly = permitted by current wording and there is no information about how = communication security will be provided by these other protocols, = section 6 of this profile does not appear to meet the MUST requirement = of 6.2 of [I-D.ietf-ace-oauth-authz]. >=20 > The simplest resolution of this inconsistency appears to be to require = use of CoAP and DTLS for compliance with this profile and revise the = wording relating to the other currently listed protocols to define = additional profile specifications. >=20 > For example, current wording:=20 > "The use of CoAP and DTLS for this communication is RECOMMENDED in = this profile, other protocols (such as HTTP and TLS, or CoAP and OSCORE = [RFC8613]) MAY be used instead."=20 >=20 > could be changed to:=20 > "The use of CoAP and DTLS for this communication is REQUIRED in this = profile. Other protocols (such as HTTP and TLS, or CoAP and OSCORE = [RFC8613]) will require specification of additional profile(s)." >=20 > Another possible resolution of the inconsistency would be to include = additional details in this specification to define how communication = security requirements will be met by these other protocols. --Apple-Mail=_3ABB02E3-3496-46E9-8F64-06A92EFC84A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks Daniel, sounds good to me.  Russ

On Jan 18, 2021, at 10:11 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Thanks Russ for the review. I = do get your comment - and had a similar comment for the oscore = profile.
I will let = the co-author to address your concern so the documents can be moved = forward shortly.

Yours, 
Daniel
From: Russ Mundy <mundy@tislabs.com>
Sent: Monday, January 18, 2021 = 9:08 PM
To: iesg@ietf.org <iesg@ietf.org>; secdir@ietf.org <secdir@ietf.org>; draft-ietf-ace-dtls-authorize.all@ietf.org <draft-ietf-ace-dtls-authorize.all@ietf.org>
Cc: Russ Mundy <mundy@tislabs.com>
Subject: secdir review of = draft-ietf-ace-dtls-authorize-14
 
Datagram Transport Layer Security (DTLS) Profile for = Authentication and Authorization for Constrained Environments (ACE)

draft-ietf-ace-dtls-authorize

I apologize for the lateness of the review but 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 one issue:

The draft-ietf-ace-dtls-authorize document is = well written and provides a very good profile for use of the ACE = framework with a client and a resource server use CoAP [RFC7252] over = DTLS version 1.2 [RFC6347] to communicate.  The document provides = the necessary specification details to use Authentication and = Authorization for Constrained Environments (ACE) using the OAuth 2.0 = Framework (ACE-OAuth) [I-D.ietf-ace-oauth-authz] with one single = exception.

Since the document under review = is a profile for [I-D.ietf-ace-oauth-authz], it must meet the = requirements for a profile contained in = [I-D.ietf-ace-oauth-authz].  Section 6.2 of = [I-D.ietf-ace-oauth-authz] specifically requires that "Profiles MUST = specify how communication security according to the requirements in = Section 5 is provided." The document under review does provide this = detail for use of CoAP and DTLS however the current wording of this = profile document does not require that CoAP and DTLS be used for this = profile. Quoting a part of 6. "The use of CoAP and DTLS for this = communication is RECOMMENDED in this profile, other protocols (such as = HTTP and TLS, or CoAP and OSCORE [RFC8613]) MAY be used = instead."  

Since use of other protocols (besides CoAP and = DTLS) is clearly permitted by current wording and there is no = information about how communication security will be provided by these = other protocols, section 6 of this profile does not appear to meet the = MUST requirement of 6.2 of [I-D.ietf-ace-oauth-authz].

The simplest resolution of this inconsistency appears to be = to require use of CoAP and DTLS for compliance with this profile and = revise the wording relating to the other currently listed protocols to = define additional profile specifications.

For= example, current wording: 
"The use of = CoAP and DTLS for this communication is RECOMMENDED in this profile, = other protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) MAY = be used instead." 

could be changed to: 
"The use of = CoAP and DTLS for this communication is REQUIRED in this profile. Other = protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) will = require specification of additional profile(s)."

Another possible resolution of the inconsistency would be to = include additional details in this specification to define how = communication security requirements will be met by these other = protocols.

= --Apple-Mail=_3ABB02E3-3496-46E9-8F64-06A92EFC84A6-- From nobody Tue Jan 19 00:55:59 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 2CFA93A1354; Tue, 19 Jan 2021 00:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 KntSzdXuN7hU; Tue, 19 Jan 2021 00:55:51 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7CE3A134E; Tue, 19 Jan 2021 00:55:49 -0800 (PST) Received: from wangari.tzi.org (p54bdeb8f.dip0.t-ipconnect.de [84.189.235.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DKjDM0Tqbz10Ck; Tue, 19 Jan 2021 09:55:47 +0100 (CET) From: Olaf Bergmann To: Daniel Migault , Russ Mundy Cc: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-ace-dtls-authorize.all@ietf.org" References: <4BED04D6-5BB6-4F7A-A0E5-3CC718E55169@tislabs.com> Date: Tue, 19 Jan 2021 09:55:46 +0100 In-Reply-To: (Daniel Migault's message of "Tue, 19 Jan 2021 03:11:05 +0000") Message-ID: <87bldl5mr1.fsf@wangari> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-ace-dtls-authorize-14 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 Jan 2021 08:55:54 -0000 Thank you, Russ, very much for your review. I am perfectly happy with your suggested change to make CoAP over DTLS REQUIRED for this profile. Best regards Olaf On 2021-01-19, Daniel Migault wrote: > Thanks Russ for the review. I do get your comment - and had a similar comment for the > oscore profile. > I will let the co-author to address your concern so the documents can be moved forward > shortly. > > Yours, > Daniel > --------------------------------------------------------------------------------- > From: Russ Mundy > Sent: Monday, January 18, 2021 9:08 PM > To: iesg@ietf.org ; secdir@ietf.org ; > draft-ietf-ace-dtls-authorize.all@ietf.org > Cc: Russ Mundy > Subject: secdir review of draft-ietf-ace-dtls-authorize-14 > > Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for > Constrained Environments (ACE) > > draft-ietf-ace-dtls-authorize > > I apologize for the lateness of the review but 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 one issue: > > The draft-ietf-ace-dtls-authorize document is well written and provides a very good profile > for use of the ACE framework with a client and a resource server use CoAP [RFC7252] over > DTLS version 1.2 [RFC6347] to communicate. The document provides the necessary > specification details to use Authentication and Authorization for Constrained Environments > (ACE) using the OAuth 2.0 Framework (ACE-OAuth) [I-D.ietf-ace-oauth-authz] with one > single exception. > > Since the document under review is a profile for [I-D.ietf-ace-oauth-authz], it must meet the > requirements for a profile contained in [I-D.ietf-ace-oauth-authz]. Section 6.2 of > [I-D.ietf-ace-oauth-authz] specifically requires that "Profiles MUST specify how > communication security according to the requirements in Section 5 is provided." The > document under review does provide this detail for use of CoAP and DTLS however the > current wording of this profile document does not require that CoAP and DTLS be used for > this profile. Quoting a part of 6. "The use of CoAP and DTLS for this communication is > RECOMMENDED in this profile, other protocols (such as HTTP and TLS, or CoAP and OSCORE > [RFC8613]) MAY be used instead." > > Since use of other protocols (besides CoAP and DTLS) is clearly permitted by current > wording and there is no information about how communication security will be provided by > these other protocols, section 6 of this profile does not appear to meet the MUST > requirement of 6.2 of [I-D.ietf-ace-oauth-authz]. > > The simplest resolution of this inconsistency appears to be to require use of CoAP and DTLS > for compliance with this profile and revise the wording relating to the other currently listed > protocols to define additional profile specifications. > > For example, current wording: > "The use of CoAP and DTLS for this communication is RECOMMENDED in this profile, other > protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) MAY be used instead." > > could be changed to: > "The use of CoAP and DTLS for this communication is REQUIRED in this profile. Other > protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) will require specification > of additional profile(s)." > > Another possible resolution of the inconsistency would be to include additional details in > this specification to define how communication security requirements will be met by these > other protocols. > From nobody Tue Jan 19 06:52:07 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 E07413A1574; Tue, 19 Jan 2021 06:52:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault via Datatracker To: Cc: draft-ietf-extra-imap4rev2.all@ietf.org, extra@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161106792581.26552.4563982290675643872@ietfa.amsl.com> Reply-To: Daniel Migault Date: Tue, 19 Jan 2021 06:52:05 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-extra-imap4rev2-24 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, 19 Jan 2021 14:52:06 -0000 Reviewer: Daniel Migault Review result: Has Nits 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 summary of the review is: Ready though I found some nits in the security consideration. Please find my comments/ questions below. Yours, Daniel Internet Message Access Protocol (IMAP) - Version 4rev2 draft-ietf-extra-imap4rev2-24 [ ... ] $Phishing The $Phishing keyword can be used by a delivery agent to mark a message as highly likely to be a phishing email. An email that's determined to be a phishing email by the delivery agent should also be considered a junk email and have the appropriate junk filtering applied, including setting the $Junk flag and placing in the \Junk special-use mailbox (see Section 7.2.3) if available. If both the $Phishing flag and the $Junk flag are set, the user agent should display an additional warning message to the user. User agents should not use the term "phishing" in their warning message as most users do not understand this term. Phrasing of the form "this message may be trying to steal your personal information" is recommended. Additionally the user agent may display a warning when clicking on any hyperlinks within the message. I tend to believe that phishing is now (unfortunately) known by most users. I have the impression that UI is always a difficult problem, and I am wondering if such recommendations are still valid or if that is a legacy statement. I do not have strong feeling about what to do, so I leave it to you, but is interested in your opinion. [ ... ] 6.2.3. LOGIN Command Arguments: user name password Responses: no specific responses for this command Result: OK - login completed, now in authenticated state NO - login failure: user name or password rejected BAD - command unknown or arguments invalid The LOGIN command identifies the client to the server and carries the plaintext password authenticating this user. A server MAY include a CAPABILITY response code in the tagged OK response to a successful LOGIN command in order to send capabilities automatically. It is unnecessary for a client to send a separate CAPABILITY command if it recognizes these automatic capabilities. Melnikov & Leiba Expires July 9, 2021 [Page 32] Internet-Draft IMAP4rev2 January 2021 Example: C: a001 LOGIN SMITH SESAME S: a001 OK LOGIN completed Note: Use of the LOGIN command over an insecure network (such as the Internet) is a security risk, because anyone monitoring network traffic can obtain plaintext passwords. The LOGIN command SHOULD NOT be used except as a last resort, and it is recommended that client implementations have a means to disable any automatic use of the LOGIN command. For my personal information. It is unclear to me why the LOGIN command is SHOULD NOT and not MUST NOT. I am mostly likely missing something, but my impression was so far that STARTTLS was mandatory. I suppose that "a configuration" means that it is not always the case, but then it becomes unclear to me why we would have STARTTLS in one configuration but not the other. This sounds to me that we are sort of allowing a vulnerable configuration as long the server may be accessed with a secure configuration. I think I am missing some dots. Unless either the client is accessing IMAP service on IMAPS port [RFC8314], the STARTTLS command has been negotiated or some other mechanism that protects the session from password snooping has been provided, a server implementation MUST implement a configuration in which it advertises the LOGINDISABLED capability and does NOT permit the LOGIN command. Server sites SHOULD NOT use any configuration which permits the LOGIN command without such a protection mechanism against password snooping. A client implementation MUST NOT send a LOGIN command if the LOGINDISABLED capability is advertised. [... ] 11. Security Considerations IMAP4rev2 protocol transactions, including electronic mail data, are sent in the clear over the network unless protection from snooping is negotiated. This can be accomplished either by the use of IMAPS service, STARTTLS command, negotiated privacy protection in the AUTHENTICATE command, or some other protection mechanism. 11.1. STARTTLS Security Considerations IMAP client and server implementations MUST comply with relevant TLS recommendations from [RFC8314]. Melnikov & Leiba Expires July 9, 2021 [Page 143] Internet-Draft IMAP4rev2 January 2021 Clients and servers MUST implement TLS 1.2 [TLS-1.2] or newer. Use of TLS 1.3 [TLS-1.3] is RECOMMENDED. TLS 1.2 may be used only in cases where the other party has not yet implemented TLS 1.3. Additionally, when using TLS 1.2, IMAP implementations MUST implement TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite, and SHOULD implement the TLS_RSA_WITH_AES_128_CBC_SHA [TLS-1.2] cipher suite. I suspect there is an issue and that TLS_RSA_WITH_AES_128_CBC_SHA is instead TLS_RSA_WITH_AES_128_CBC_SHA256. However, these suites are not set as "recommended" on the IANA registry. Note that the term recommended may be misleading as it does not necessarily means the cipher is weak. It means instead that the cipher suite has not been through a standard process. This could mean, for example, the cipher suite may correspond to a specific use case. If that is the case, I believe that should be mentioned. However, I believe that in this case, the motivation for the community is that RSA authentication suffers from a significant number of attacks - [1], no forward secrecy - and I tend to believe its support may not be recommended. RFC7525 for example mentions it as SHOULD NOT. [1] https://www.usenix.org/conference/usenixsecurity18/presentation/bock In order to defer the cryptographic recommendations to RFC8447, and ensure these recommendations to be update to date, I would reference that the TLS client and server are expected to follow RFC8447 for their cryptographic recommendations. Currently RFC8847 sets a cipher suite as recommended when it has received a wide support from the community and it intend is as far as I think to remove ciphers that will become weak. RFC8447 works for TLS 1.2 and 1.3 keeps the number of cipher suites relatively low, so if the motivation to mandate TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and LS_RSA_WITH_AES_128_CBC_SHA256 was to keep the number of cipher suites low. If that is the case, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 may be a better fit at least in my opinion. This is important as it assures that any two compliant implementations can be configured to interoperate. Other TLS cipher suites recommended in RFC 7525 are RECOMMENDED: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. All other cipher suites are OPTIONAL. Note that this is a change from section 2.1 of [IMAP-TLS]. I believe this is good to mention RFC7525 for TLS 1.2. There might small overlap concerning cipher recommendations with RFC8447, but RFC7525 recommendations go beyond and is not limited to cipher suites recommendations. Regarding the RSA versus ECDSA it seems to me that RSA is a bit behind. [1] mentions ECDSA and RSA in their intermediate profile with ECDSA recommended. I would maybe avoid explicitly recommend these cipher suites, and if that is needed, I would explain why these are recommended. [1] https://wiki.mozilla.org/Security/Server_Side_TLS The list of mandatory-to-implement TLS 1.3 cipher suites is described in Section 9.1 of [TLS-1.3]. During the TLS negotiation [TLS-1.3][TLS-1.2], the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. This procedure is described in [RFC7817]. I think it would be good to mention DANE as well as certificate checks. In addition, when TLS 1.3 is used, the client and the server MAY also enabled the ticket_pinning extension [RFC8672] to further prevent and detect man-in-the-middle attacks. The ticket_pinning extensions provides evidence that after an initial TLS session, the subsequent TLS sessions are performed with the same TLS server, as well as - when such attacks occurs - detect them on both client or server side. For full disclosure I am co-authoring identity pinning. Both the client and server MUST check the result of the STARTTLS command and subsequent TLS ([TLS-1.3][TLS-1.2]) negotiation to see whether acceptable authentication and/or privacy was achieved. This is a bit unclear to me as I do not expect to have a server / client accepting cipher_suites, or being configured to establish a TLS session that does not achieve what we expect. In other word, I understand the paragraph as saying after the session establishment, we recheck that parameters chosen are appropriated. I suppose I am missing something, but if not I would have expected it to be the other way around. 11.2. COPYUID and APPENDUID response codes The COPYUID and APPENDUID response codes return information about the mailbox, which may be considered sensitive if the mailbox has permissions set that permit the client to COPY or APPEND to the mailbox, but not SELECT or EXAMINE it. Consequently, these response codes SHOULD NOT be issued if the client does not have access to SELECT or EXAMINE the mailbox. 11.3. LIST command and Other Users' namespace In response to a LIST command containing an argument of the Other Users' Namespace prefix, a server SHOULD NOT list users that have not granted list access to their personal mailboxes to the currently authenticated user. Providing such a list, could compromise security by potentially disclosing confidential information of who is located on the server, or providing a starting point of a list of user accounts to attack. Melnikov & Leiba Expires July 9, 2021 [Page 144] Internet-Draft IMAP4rev2 January 2021 11.4. Other Security Considerations A server error message for an AUTHENTICATE command which fails due to invalid credentials SHOULD NOT detail why the credentials are invalid. Use of the LOGIN command sends passwords in the clear. This can be avoided by using the AUTHENTICATE command with a [SASL] mechanism that does not use plaintext passwords, by first negotiating encryption via STARTTLS or some other protection mechanism. A server implementation MUST implement a configuration that, at the time of authentication, requires: (1) The STARTTLS command has been negotiated. OR (2) Some other mechanism that protects the session from password snooping has been provided. OR (3) The following measures are in place: (a) The LOGINDISABLED capability is advertised, and [SASL] mechanisms (such as PLAIN) using plaintext passwords are NOT advertised in the CAPABILITY list. AND (b) The LOGIN command returns an error even if the password is correct. AND (c) The AUTHENTICATE command returns an error with all [SASL] mechanisms that use plaintext passwords, even if the password is correct. A server error message for a failing LOGIN command SHOULD NOT specify that the user name, as opposed to the password, is invalid. A server SHOULD have mechanisms in place to limit or delay failed AUTHENTICATE/LOGIN attempts. Additional security considerations are discussed in the section discussing the AUTHENTICATE (see Section 6.2.2) and LOGIN (see Section 6.2.3) commands. Another concern regarding authentication with IMAP is user have usually one account and one login/password for a cloud account as well as an IMAP account. In many cases, the cloud account provides 2FA which makes possession of the login password not sufficient to gain access. However, IMAP authentication hardly provide 2FA, and mail may not benefit from the same protection and could be used to escape 2FA. I believe this could be mentioned as well as known mechanisms to provide 2FA with IMAP - if there are some. Note that 2FA may not necessarily prevent to guess the correspondence between login and password. The section mentions that repeated attempts for a password associated is detected, somehow prevented. It may also worth mentioning that with a large number of login (known or guessed), an attacker may try to guess a login associated to a small number of commonly known weak passwords ( password spraying). I believe it might worth being mentioned, that correlating failed attempts worth also being mentioned. Maybe that goes a bit too far in the purpose of recommendations, but it might may sense to recommend strong random passwords used in conjunction of passwords wallets or the use of mutually authenticate TLS. One question I would have - and with very little opinion on it - is how vulnerable IMAP parsing is to injection. I usually see the use of JSON as a big advantage toward this, but I would be happy to known your opinion on it. I also have the impression that injections can be performed via the web interface, so a web front end should be carefully considered and IMAP server may not believe they are always immune behind a web front end and still require to follow the best practises. From nobody Tue Jan 19 09:46:24 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 ED8ED3A0C94; Tue, 19 Jan 2021 09:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 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.262, 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 3YhHrRVAnQFd; Tue, 19 Jan 2021 09:46:11 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id E81C43A0C01; Tue, 19 Jan 2021 09:46:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1611078370; d=isode.com; s=june2016; i=@isode.com; bh=DWOsnrEG2NC9YHA14olWazW99fCroSLtvUaLrUOuJ1w=; 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=snOQyPfIybGTjJLYW/rBAsu/sQFBCcTlHOuwWlIvBrtLUDSEI/FpCrub+WXXYRFke+7CMv M/rIZsBC9T+NVE10m4/XVzLQrjlqHzw7TxLOP9OQJyMSyg9l6EbTdmK9E8kQU91WHBCNL/ qkDNSMnx1kCdEn6Dikh73m67BDLo5B8=; Received: from [172.27.250.167] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 19 Jan 2021 17:46:09 +0000 From: Alexey Melnikov To: Daniel Migault , secdir@ietf.org Cc: draft-ietf-extra-imap4rev2.all@ietf.org, extra@ietf.org, last-call@ietf.org References: <161106792581.26552.4563982290675643872@ietfa.amsl.com> Message-ID: <99082ebc-318b-5c4d-a9e6-b3893ab99c0d@isode.com> Date: Tue, 19 Jan 2021 17:46:08 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 In-Reply-To: <161106792581.26552.4563982290675643872@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-extra-imap4rev2-24 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 Jan 2021 17:46:14 -0000 Hi Daniel, Thank you for your review. My replies below. I removed some of your=20 comments that I need to think a bit more and will reply to them separately. On 19/01/2021 14:52, Daniel Migault via Datatracker wrote: > Reviewer: Daniel Migault > Review result: Has Nits > > 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 summary of the review is: Ready though I found some nits in > the security consideration. > > Please find my comments/ questions below. > > Yours, > Daniel > > > =20 > > > Internet Message Access Protocol (IMAP) - Version 4rev2 > draft-ietf-extra-imap4rev2-24 > > > [ ... ] > > $Phishing The $Phishing keyword can be used by a delivery agent to > mark a message as highly likely to be a phishing email. An email > that's determined to be a phishing email by the delivery agent > should also be considered a junk email and have the appropriate > junk filtering applied, including setting the $Junk flag and > placing in the \Junk special-use mailbox (see Section 7.2.3) if > available. > If both the $Phishing flag and the $Junk flag are set, the user > agent should display an additional warning message to the user. > User agents should not use the term "phishing" in their warning > message as most users do not understand this term. Phrasing of > the form "this message may be trying to steal your personal > information" is recommended. Additionally the user agent may > display a warning when clicking on any hyperlinks within the > message. > > > I tend to believe that phishing is now > (unfortunately) known by most users. > I have the impression that UI is always a > difficult problem, and I am wondering if such > recommendations are still valid or if that is > a legacy statement. I do not have strong > feeling about what to do, so I leave it to > you, but is interested in your opinion. This text matches the original registration of the $Phishing keyword. I=20 have seen some modern email clients still following this advice, so I=20 think it is useful. Which part of it do you find outdated? > > > [ ... ] > > 6.2.3. LOGIN Command > > Arguments: user name > password > > Responses: no specific responses for this command > > Result: OK - login completed, now in authenticated state > NO - login failure: user name or password rejected > BAD - command unknown or arguments invalid > > The LOGIN command identifies the client to the server and carries the > plaintext password authenticating this user. > > A server MAY include a CAPABILITY response code in the tagged OK > response to a successful LOGIN command in order to send capabilities > automatically. It is unnecessary for a client to send a separate > CAPABILITY command if it recognizes these automatic capabilities. > > > > Melnikov & Leiba Expires July 9, 2021 [Page 32] > =0C > Internet-Draft IMAP4rev2 January 2021 > > > Example: C: a001 LOGIN SMITH SESAME > S: a001 OK LOGIN completed > > Note: Use of the LOGIN command over an insecure network (such as the > Internet) is a security risk, because anyone monitoring network > traffic can obtain plaintext passwords. The LOGIN command SHOULD NOT > be used except as a last resort, and it is recommended that client > implementations have a means to disable any automatic use of the > LOGIN command. > > > For my personal information. It is unclear > to me why the LOGIN command is SHOULD NOT and > not MUST NOT. I am mostly likely missing > something, but my impression was so far that > STARTTLS was mandatory. I suppose that "a > configuration" means that it is not always > the case, but then it becomes unclear to me > why we would have STARTTLS in one > configuration but not the other. This sounds > to me that we are sort of allowing a > vulnerable configuration as long the server > may be accessed with a secure configuration. > I think I am missing some dots. Thank you for drawing my attention to this. I agree that the text is=20 wrong. I think the intent was to allow LOGIN on "secure networks" and=20 disallow it otherwise. After rereading this the quoted paragraph is not=20 saying that. I will fix. > > > Unless either the client is accessing IMAP service on IMAPS port > [RFC8314], the STARTTLS command has been negotiated or some other > mechanism that protects the session from password snooping has been > provided, a server implementation MUST implement a configuration in > which it advertises the LOGINDISABLED capability and does NOT permit > the LOGIN command. Server sites SHOULD NOT use any configuration > which permits the LOGIN command without such a protection mechanism > against password snooping. A client implementation MUST NOT send a > LOGIN command if the LOGINDISABLED capability is advertised. > > [... ] > > 11. Security Considerations > > IMAP4rev2 protocol transactions, including electronic mail data, are > sent in the clear over the network unless protection from snooping is > negotiated. This can be accomplished either by the use of IMAPS > service, STARTTLS command, negotiated privacy protection in the > AUTHENTICATE command, or some other protection mechanism. > > 11.1. STARTTLS Security Considerations > > IMAP client and server implementations MUST comply with relevant TLS > recommendations from [RFC8314]. > > > > > > Melnikov & Leiba Expires July 9, 2021 [Page 143] > =0C > Internet-Draft IMAP4rev2 January 2021 > > > Clients and servers MUST implement TLS 1.2 [TLS-1.2] or newer. Use > of TLS 1.3 [TLS-1.3] is RECOMMENDED. TLS 1.2 may be used only in > cases where the other party has not yet implemented TLS 1.3. > Additionally, when using TLS 1.2, IMAP implementations MUST implement > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite, and SHOULD > implement the TLS_RSA_WITH_AES_128_CBC_SHA [TLS-1.2] cipher suite. > > > I suspect there is an issue and that > TLS_RSA_WITH_AES_128_CBC_SHA is instead > TLS_RSA_WITH_AES_128_CBC_SHA256. > > However, these suites are not set as > "recommended" on the IANA registry. Note > that the term recommended may be misleading > as it does not necessarily means the cipher > is weak. It means instead that the cipher > suite has not been through a standard > process. This could mean, for example, the > cipher suite may correspond to a specific use > case. If that is the case, I believe that > should be mentioned. However, I believe that > in this case, the motivation for the > community is that RSA authentication suffers > from a significant number of attacks - [1], > no forward secrecy - and I tend to believe > its support may not be recommended. RFC7525 > for example mentions it as SHOULD NOT. Good point. I will remove TLS_RSA_WITH_AES_128_CBC_SHA from the document. > [1]https://www.usenix.org/conference/usenixsecurity18/presentation/bock > > > > In order to defer the cryptographic > recommendations to RFC8447, and ensure these > recommendations to be update to date, I would > reference that the TLS client and server are > expected to follow RFC8447 for their > cryptographic recommendations. Currently > RFC8847 sets a cipher suite as recommended > when it has received a wide support from the > community and it intend is as far as I think > to remove ciphers that will become weak. > > RFC8447 works for TLS 1.2 and 1.3 keeps the > number of cipher suites relatively low, so if > the motivation to mandate > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and > LS_RSA_WITH_AES_128_CBC_SHA256 was to keep > the number of cipher suites low. If that is > the case, > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 may > be a better fit at least in my opinion. Ok. > > > This is important as it assures that any two compliant > implementations can be configured to interoperate. Other TLS cipher > suites recommended in RFC 7525 are RECOMMENDED: > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. All other cipher suites are > OPTIONAL. Note that this is a change from section 2.1 of [IMAP-TLS]. > > > I believe this is good to mention RFC7525 for > TLS 1.2. There might small overlap concerning > cipher recommendations with RFC8447, but > RFC7525 recommendations go beyond and is not > limited to cipher suites recommendations. > > Regarding the RSA versus ECDSA it seems to me > that RSA is a bit behind. [1] mentions ECDSA > and RSA in their intermediate profile with > ECDSA recommended. I would maybe avoid > explicitly recommend these cipher suites, and > if that is needed, I would explain why these > are recommended. > > [1]https://wiki.mozilla.org/Security/Server_Side_TLS Thank you for the link, I will review. > > > The list of mandatory-to-implement TLS 1.3 cipher suites is described > in Section 9.1 of [TLS-1.3]. > =C2=A0[snip] > Both the client and server MUST check the result of the STARTTLS > command and subsequent TLS ([TLS-1.3][TLS-1.2]) negotiation to see > whether acceptable authentication and/or privacy was achieved. > > > This is a bit unclear to me as I do not > expect to have a server / client accepting > cipher_suites, or being configured to > establish a TLS session that does not achieve > what we expect. In other word, I understand > the paragraph as saying after the > session establishment, we recheck that > parameters chosen are appropriated. I suppose > I am missing something, but if not I would > have expected it to be the other way around. I don't think all implementations control cipher suites to be used=20 before negotiation starts (this might be API and/or implementation=20 limitation), so this is encouraging to check whether negotiated=20 ciphersuite matches policy after negotiation completes. > > =C2=A0[snip] > 11.4. Other Security Considerations > > A server error message for an AUTHENTICATE command which fails due to > invalid credentials SHOULD NOT detail why the credentials are > invalid. > > Use of the LOGIN command sends passwords in the clear. This can be > avoided by using the AUTHENTICATE command with a [SASL] mechanism > that does not use plaintext passwords, by first negotiating > encryption via STARTTLS or some other protection mechanism. > > A server implementation MUST implement a configuration that, at the > time of authentication, requires: > (1) The STARTTLS command has been negotiated. > OR > (2) Some other mechanism that protects the session from password > snooping has been provided. > OR > (3) The following measures are in place: > (a) The LOGINDISABLED capability is advertised, and [SASL] mechanisms > (such as PLAIN) using plaintext passwords are NOT advertised in the > CAPABILITY list. > AND > (b) The LOGIN command returns an error even if the password is > correct. > AND > (c) The AUTHENTICATE command returns an error with all [SASL] > mechanisms that use plaintext passwords, even if the password is > correct. > > A server error message for a failing LOGIN command SHOULD NOT specify > that the user name, as opposed to the password, is invalid. > > A server SHOULD have mechanisms in place to limit or delay failed > AUTHENTICATE/LOGIN attempts. > > Additional security considerations are discussed in the section > discussing the AUTHENTICATE (see Section 6.2.2) and LOGIN (see > Section 6.2.3) commands. > > > Another concern regarding > authentication with IMAP is user have usually > one account and one login/password for a > cloud account as well as an IMAP account. In > many cases, the cloud account provides 2FA > which makes possession of the login password > not sufficient to gain access. However, IMAP > authentication hardly provide 2FA, and mail > may not benefit from the same protection and > could be used to escape 2FA. I believe this > could be mentioned as well as known > mechanisms to provide 2FA with IMAP - if > there are some. There are some drafts adding 2FA to SASL authentication that are likely=20 to be discussed in the KITTEN WG. But at this point there is nothing=20 that can be referenced normatively. I will think what can be said about=20 that. > Note that 2FA may not necessarily prevent to > guess the correspondence between login and > password. > > The section mentions that repeated attempts > for a password associated is detected, > somehow prevented. It may also worth > mentioning that with a large number of login > (known or guessed), > an attacker may try to guess a login > associated to a small number of commonly > known weak passwords ( password > spraying). I believe it might worth being > mentioned, that correlating failed attempts > worth also being mentioned. Fair enough. Can you suggest some text? > Maybe that goes a bit too far in the purpose > of recommendations, but it might may sense to > recommend strong random passwords used in > conjunction of passwords wallets or the use > of mutually authenticate TLS. > > > > > > One question I would have - and with very > little opinion on it - is how vulnerable IMAP > parsing is to injection. I usually see the > use of JSON as a big advantage toward > this, but I would be happy to known > your opinion on it. Can you give me an example, as I am not sure what do you mean by=20 injection in this case? > I also have the impression that injections > can be performed via the web interface, so a > web front end should be carefully considered > and IMAP server may not believe they are > always immune behind a web front end and > still require to follow the best practises. > > Best Regards, Alexey From nobody Tue Jan 19 12: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 2A4D73A0ABB; Tue, 19 Jan 2021 12:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, 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, 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=ericsson.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 EscpjHllVbhY; Tue, 19 Jan 2021 12:46:44 -0800 (PST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2085.outbound.protection.outlook.com [40.107.237.85]) (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 B040F3A0AA7; Tue, 19 Jan 2021 12:46:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qnk0ALELhnwEj0GiN/9+TWhY9A7vk5gybKd914XmONcyYVpdShcQjcZgFh2uXWF2tE2lttRtxYvv49CL+Vtu2YR6wMCx1ZEEUrpdinkPrk6kdBuIoIgMAzXdrP4ZwOeDk4xrGLg8H57tMlMjwp3knAPN95E9RS60uKvmoda91XXKfvXTBWF1VfhZsrq6kztlBKs6dtnu7MSMkIkQkJsPAU9Y9dwB9O4Mh1W+0hOApz8Ndnwz6u2ZJepXzDX3WmJ0IxAzpytlmfOPykzDXjtIVWO2Lw2gUkoN+I16SlwlguY4F/NUoHPNFVqxx3Mku6CbaZbOR9ME9Ms7eAXRh/l0mQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gMklTcF1itVMTUcmOv4t6Mv4hEffMxmVqdrxxcQAs/M=; b=e/qftYS1jGm9o+GpZ6/UDN+AaG0OzYRZx8HyPqKWHTerkwDx/E1/WlNBXMvPm1xJdtDd30yB7Ij62xk3V4D4AZmpL9Uz+wuZytZ2FJKhRun5wzPNz1mIfEUy+amfCCnc+7vsjdtqTsYiu5TxFQvwFNg3UFHqy8JBkvbLw+5qx4oEkUvApU6zZ71hJInWaHz1yKhnOQX3CL4UJyWFfcZwEbbzZCBlbtzmKGNA0B0bmieQ1eBuXH0UuOWmtDUIVkMXdUaIInbnAHRA3VRDayT29KckgIrFtvIFdQRNw41tQxeJ/WLQSP9k0fDOWHVjHBQlEA5oLBHMzDFwE/MrMVrFgA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gMklTcF1itVMTUcmOv4t6Mv4hEffMxmVqdrxxcQAs/M=; b=vMhBnWVDF6K+c0OuC4Oy1pxQjxHNDcqI9ccaBdikjvy3DBPWfzi9QmmftiwLAIPRY8edhQMvTl7M5mARudgQN9+Z2Lu7UwchY8DhHWTpB4tdQCvyT2cacyqdusK2Y6ubXwt5kA0ayInag/OzfEB5zamBZ1+tM6IIYO8HBbqmad0= Received: from DM6PR15MB2379.namprd15.prod.outlook.com (2603:10b6:5:8a::16) by DM6PR15MB2666.namprd15.prod.outlook.com (2603:10b6:5:1a8::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.10; Tue, 19 Jan 2021 20:46:37 +0000 Received: from DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::a9f9:326f:8cfb:157b]) by DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::a9f9:326f:8cfb:157b%7]) with mapi id 15.20.3763.014; Tue, 19 Jan 2021 20:46:37 +0000 From: Daniel Migault To: Alexey Melnikov , "secdir@ietf.org" CC: "draft-ietf-extra-imap4rev2.all@ietf.org" , "extra@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-extra-imap4rev2-24 Thread-Index: AQHW7osBCZRYcejh/kaFOg7r/oDlOqovTFtx Date: Tue, 19 Jan 2021 20:46:37 +0000 Message-ID: References: <161106792581.26552.4563982290675643872@ietfa.amsl.com>, <99082ebc-318b-5c4d-a9e6-b3893ab99c0d@isode.com> In-Reply-To: <99082ebc-318b-5c4d-a9e6-b3893ab99c0d@isode.com> 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=ericsson.com; x-originating-ip: [96.22.11.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3007eb55-b530-4a2e-8c23-08d8bcbb50fc x-ms-traffictypediagnostic: DM6PR15MB2666: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Rl0kw/RP7cly449tjtC8Lan+IIobuE73xAXU4gMhBikwQny+keD1EV1FYKwOEPtEztSy39CRFScxsXflAv34BoFLhmHRj/hsdBWEG73mln5MQlTl3QZeJSxTG5wnl6Nsnzfifz5MiH4kKXxAjHLCe2QreN8cT9YCCwUuNgyQ6hbbkNBzWXdt7jggkmYNh6lAYd+2qO60mIeE0wySV+l81uX4eYeJI3U7zVavS5vA//CZY0XUX8xSpLb3FPb4GlQl+LeHz1uD1ci+YKtei3+Lma0R+3NZguTQ+y8iesPFwpV9P7dsr/B9WbtcsLZA/nIN6jzUo8HUJAV4NjFjkumcaudRgmslTJvFGrlMqYt0MssW19xJUliKihgCgwQGrtIbmCCC+zBCJckh3WR4V0tvAUSsVL8ePy+7MO3djUliMxAS3zL2QUY4fM7AOrRghBDFuHY3bJ+MyUqCcDscfGcUxQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR15MB2379.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(366004)(396003)(39860400002)(136003)(33656002)(8676002)(44832011)(71200400001)(66446008)(4326008)(19627405001)(26005)(55016002)(86362001)(7696005)(9686003)(8936002)(54906003)(83380400001)(66946007)(66476007)(91956017)(186003)(478600001)(52536014)(30864003)(316002)(76116006)(5660300002)(64756008)(66574015)(53546011)(110136005)(2906002)(66556008)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?nsWV6bFMK+32yt1Qbzg/MpP9BRcmjWQ92QdjHWbGDr4tPrvJZIP2dL/Wan?= =?iso-8859-1?Q?Auhk+n59OGSMLkpTOTUEnFFVvY1y6iGjfji46wahNScr2iUaZXauXfCegG?= =?iso-8859-1?Q?P5d60j913BeyffVUmUbHx6ntbTNmczewZ3Jdw8Teu5EP670CqUJzUQvEwY?= =?iso-8859-1?Q?C2igx8EkbZzvaI5+3wtyTRcmyhlf5JmFFkFNeWY/Qh1M63bBiZ0FdzhamG?= =?iso-8859-1?Q?vbBbvhUJ9VtGZq+e2D7svrUf+Tt2+lxX/qvgBdYbY9leoob8qx5I8UsTLi?= =?iso-8859-1?Q?kM56oUi6T1A+88LNBvW2YQX0uSTXBiYJ1wg52yPO0InGYMU+el0e07pVC9?= =?iso-8859-1?Q?iO7pGqd5K3rTWmrBCLEWz/bNcohHZ1zgITC21GuLEI1/mS8y/kCZx0rPx6?= =?iso-8859-1?Q?UmZWcIjvw57nS6KIz6X8ggEqYozXAAh77RPgs9fliDKH1YG5Uqs4Ph3cOe?= =?iso-8859-1?Q?ZBgAEphP9Qs0Y/J08NDf5G6UM4iQZrvA9Z/KsS9WBB1FGtW15VBGj+ESC9?= =?iso-8859-1?Q?VY0a/hjbYDYFQXhHUIEEOM8wxaTNWMdd6GzlDY4eT7RBt5pvxlhdvRECVN?= =?iso-8859-1?Q?LHsBufXp+8/IEKCTun74rTcv1B49fJmlOy8BkZctmKkuhJkMGtUHVjnJFA?= =?iso-8859-1?Q?vhrblhIuvQMXwEe9wXyfBV3RdnFrES5BnbLn0N88zLifivy9QCdGBUg3Z7?= =?iso-8859-1?Q?p0X4Gl8aXu+CTuIHAKDnJaw9WFZmiR81yOdtOJmrAcY06azDnDFecCVhg2?= =?iso-8859-1?Q?nQ8gpHG9b6g5jHqzfIVLPCWrK5wNBaoWsDlRoWlhPeRPy+LrKfxqmyC68U?= =?iso-8859-1?Q?a7P7IfvqYClaATO6FvVKtsMyilpQV9YYLR5vAOCQ23peN1AeHvg8ptrBsY?= =?iso-8859-1?Q?myw/fP6mhl9gmpOf19+grGu9g0ZEsHzbM15CsDi4YmYpFNv5TQ+mh+z5Ih?= =?iso-8859-1?Q?ohkhtDwvpQsoAIE7gLJQSkLGhQ1mUy8ypgCyijNMc4mpbVR9bTg0zB/ngr?= =?iso-8859-1?Q?88PTEkNGz+EuhG2zo=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR15MB2379AD34B141FD5015D25E86E3A30DM6PR15MB2379namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR15MB2379.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3007eb55-b530-4a2e-8c23-08d8bcbb50fc X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2021 20:46:37.5930 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ceXGFQLZj3OsK/qvC/Oynse3BSplqVBGSSFwhOsAAfiqmCAxhxq5wX9rR7L4w3SpJq+F0b3ludSd7vJyaxhBDitOuaDM52Z1aTt6B5WLA2g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2666 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-extra-imap4rev2-24 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 Jan 2021 20:46:48 -0000 --_000_DM6PR15MB2379AD34B141FD5015D25E86E3A30DM6PR15MB2379namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alexey, Thanks for your response. Please find some clarifications/responses. Yours, Daniel ________________________________ From: Alexey Melnikov Sent: Tuesday, January 19, 2021 12:46 PM To: Daniel Migault ; secdir@ietf.org Cc: draft-ietf-extra-imap4rev2.all@ietf.org ; extra@ietf.org ; last-call@ietf.org Subject: Re: Secdir last call review of draft-ietf-extra-imap4rev2-24 Hi Daniel, Thank you for your review. My replies below. I removed some of your comments that I need to think a bit more and will reply to them separately. On 19/01/2021 14:52, Daniel Migault via Datatracker wrote: > Reviewer: Daniel Migault > Review result: Has Nits > > 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 summary of the review is: Ready though I found some nits in > the security consideration. > > Please find my comments/ questions below. > > Yours, > Daniel > > > > > > Internet Message Access Protocol (IMAP) - Version 4rev2 > draft-ietf-extra-imap4rev2-24 > > > [ ... ] > > $Phishing The $Phishing keyword can be used by a delivery agent to > mark a message as highly likely to be a phishing email. An email > that's determined to be a phishing email by the delivery agent > should also be considered a junk email and have the appropriate > junk filtering applied, including setting the $Junk flag and > placing in the \Junk special-use mailbox (see Section 7.2.3) if > available. > If both the $Phishing flag and the $Junk flag are set, the user > agent should display an additional warning message to the user. > User agents should not use the term "phishing" in their warning > message as most users do not understand this term. Phrasing of > the form "this message may be trying to steal your personal > information" is recommended. Additionally the user agent may > display a warning when clicking on any hyperlinks within the > message. > > > I tend to believe that phishing is now > (unfortunately) known by most users. > I have the impression that UI is always a > difficult problem, and I am wondering if such > recommendations are still valid or if that is > a legacy statement. I do not have strong > feeling about what to do, so I leave it to > you, but is interested in your opinion. This text matches the original registration of the $Phishing keyword. I have seen some modern email clients still following this advice, so I think it is useful. Which part of it do you find outdated? Just to be clear that was just a comment. In the following sentence, """ User agents should not use the term "phishing" in their warning message as most users do not understand this term. """ I was questioning "as most users do not understand this term" and tend to = believe that most users have heard what phishing means. So I am wondering i= f the user the message is being shown does not translate to itself: "Oh yea= h they mean phishing". Again just some random thoughts from my part. > > > [ ... ] > > 6.2.3. LOGIN Command > > Arguments: user name > password > > Responses: no specific responses for this command > > Result: OK - login completed, now in authenticated state > NO - login failure: user name or password rejected > BAD - command unknown or arguments invalid > > The LOGIN command identifies the client to the server and carries the > plaintext password authenticating this user. > > A server MAY include a CAPABILITY response code in the tagged OK > response to a successful LOGIN command in order to send capabilities > automatically. It is unnecessary for a client to send a separate > CAPABILITY command if it recognizes these automatic capabilities. > > > > Melnikov & Leiba Expires July 9, 2021 [Page 32] > > Internet-Draft IMAP4rev2 January 2021 > > > Example: C: a001 LOGIN SMITH SESAME > S: a001 OK LOGIN completed > > Note: Use of the LOGIN command over an insecure network (such as the > Internet) is a security risk, because anyone monitoring network > traffic can obtain plaintext passwords. The LOGIN command SHOULD NOT > be used except as a last resort, and it is recommended that client > implementations have a means to disable any automatic use of the > LOGIN command. > > > For my personal information. It is unclear > to me why the LOGIN command is SHOULD NOT and > not MUST NOT. I am mostly likely missing > something, but my impression was so far that > STARTTLS was mandatory. I suppose that "a > configuration" means that it is not always > the case, but then it becomes unclear to me > why we would have STARTTLS in one > configuration but not the other. This sounds > to me that we are sort of allowing a > vulnerable configuration as long the server > may be accessed with a secure configuration. > I think I am missing some dots. Thank you for drawing my attention to this. I agree that the text is wrong. I think the intent was to allow LOGIN on "secure networks" and disallow it otherwise. After rereading this the quoted paragraph is not saying that. I will fix. > > > Unless either the client is accessing IMAP service on IMAPS port > [RFC8314], the STARTTLS command has been negotiated or some other > mechanism that protects the session from password snooping has been > provided, a server implementation MUST implement a configuration in > which it advertises the LOGINDISABLED capability and does NOT permit > the LOGIN command. Server sites SHOULD NOT use any configuration > which permits the LOGIN command without such a protection mechanism > against password snooping. A client implementation MUST NOT send a > LOGIN command if the LOGINDISABLED capability is advertised. > > [... ] > > 11. Security Considerations > > IMAP4rev2 protocol transactions, including electronic mail data, are > sent in the clear over the network unless protection from snooping is > negotiated. This can be accomplished either by the use of IMAPS > service, STARTTLS command, negotiated privacy protection in the > AUTHENTICATE command, or some other protection mechanism. > > 11.1. STARTTLS Security Considerations > > IMAP client and server implementations MUST comply with relevant TLS > recommendations from [RFC8314]. > > > > > > Melnikov & Leiba Expires July 9, 2021 [Page 143] > > Internet-Draft IMAP4rev2 January 2021 > > > Clients and servers MUST implement TLS 1.2 [TLS-1.2] or newer. Use > of TLS 1.3 [TLS-1.3] is RECOMMENDED. TLS 1.2 may be used only in > cases where the other party has not yet implemented TLS 1.3. > Additionally, when using TLS 1.2, IMAP implementations MUST implement > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite, and SHOULD > implement the TLS_RSA_WITH_AES_128_CBC_SHA [TLS-1.2] cipher suite. > > > I suspect there is an issue and that > TLS_RSA_WITH_AES_128_CBC_SHA is instead > TLS_RSA_WITH_AES_128_CBC_SHA256. > > However, these suites are not set as > "recommended" on the IANA registry. Note > that the term recommended may be misleading > as it does not necessarily means the cipher > is weak. It means instead that the cipher > suite has not been through a standard > process. This could mean, for example, the > cipher suite may correspond to a specific use > case. If that is the case, I believe that > should be mentioned. However, I believe that > in this case, the motivation for the > community is that RSA authentication suffers > from a significant number of attacks - [1], > no forward secrecy - and I tend to believe > its support may not be recommended. RFC7525 > for example mentions it as SHOULD NOT. Good point. I will remove TLS_RSA_WITH_AES_128_CBC_SHA from the document. > [1]https://www.usenix.org/conference/usenixsecurity18/presentation/bock > > > > In order to defer the cryptographic > recommendations to RFC8447, and ensure these > recommendations to be update to date, I would > reference that the TLS client and server are > expected to follow RFC8447 for their > cryptographic recommendations. Currently > RFC8847 sets a cipher suite as recommended > when it has received a wide support from the > community and it intend is as far as I think > to remove ciphers that will become weak. > > RFC8447 works for TLS 1.2 and 1.3 keeps the > number of cipher suites relatively low, so if > the motivation to mandate > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and > LS_RSA_WITH_AES_128_CBC_SHA256 was to keep > the number of cipher suites low. If that is > the case, > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 may > be a better fit at least in my opinion. Ok. > > > This is important as it assures that any two compliant > implementations can be configured to interoperate. Other TLS cipher > suites recommended in RFC 7525 are RECOMMENDED: > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. All other cipher suites are > OPTIONAL. Note that this is a change from section 2.1 of [IMAP-TLS]. > > > I believe this is good to mention RFC7525 for > TLS 1.2. There might small overlap concerning > cipher recommendations with RFC8447, but > RFC7525 recommendations go beyond and is not > limited to cipher suites recommendations. > > Regarding the RSA versus ECDSA it seems to me > that RSA is a bit behind. [1] mentions ECDSA > and RSA in their intermediate profile with > ECDSA recommended. I would maybe avoid > explicitly recommend these cipher suites, and > if that is needed, I would explain why these > are recommended. > > [1]https://wiki.mozilla.org/Security/Server_Side_TLS Thank you for the link, I will review. > > > The list of mandatory-to-implement TLS 1.3 cipher suites is described > in Section 9.1 of [TLS-1.3]. > [snip] > Both the client and server MUST check the result of the STARTTLS > command and subsequent TLS ([TLS-1.3][TLS-1.2]) negotiation to see > whether acceptable authentication and/or privacy was achieved. > > > This is a bit unclear to me as I do not > expect to have a server / client accepting > cipher_suites, or being configured to > establish a TLS session that does not achieve > what we expect. In other word, I understand > the paragraph as saying after the > session establishment, we recheck that > parameters chosen are appropriated. I suppose > I am missing something, but if not I would > have expected it to be the other way around. I don't think all implementations control cipher suites to be used before negotiation starts (this might be API and/or implementation limitation), so this is encouraging to check whether negotiated ciphersuite matches policy after negotiation completes. ok, I agree this maybe the case for the client, but I expect the server to = have its library being "specifically" configured. > > [snip] > 11.4. Other Security Considerations > > A server error message for an AUTHENTICATE command which fails due to > invalid credentials SHOULD NOT detail why the credentials are > invalid. > > Use of the LOGIN command sends passwords in the clear. This can be > avoided by using the AUTHENTICATE command with a [SASL] mechanism > that does not use plaintext passwords, by first negotiating > encryption via STARTTLS or some other protection mechanism. > > A server implementation MUST implement a configuration that, at the > time of authentication, requires: > (1) The STARTTLS command has been negotiated. > OR > (2) Some other mechanism that protects the session from password > snooping has been provided. > OR > (3) The following measures are in place: > (a) The LOGINDISABLED capability is advertised, and [SASL] mechanisms > (such as PLAIN) using plaintext passwords are NOT advertised in the > CAPABILITY list. > AND > (b) The LOGIN command returns an error even if the password is > correct. > AND > (c) The AUTHENTICATE command returns an error with all [SASL] > mechanisms that use plaintext passwords, even if the password is > correct. > > A server error message for a failing LOGIN command SHOULD NOT specify > that the user name, as opposed to the password, is invalid. > > A server SHOULD have mechanisms in place to limit or delay failed > AUTHENTICATE/LOGIN attempts. > > Additional security considerations are discussed in the section > discussing the AUTHENTICATE (see Section 6.2.2) and LOGIN (see > Section 6.2.3) commands. > > > Another concern regarding > authentication with IMAP is user have usually > one account and one login/password for a > cloud account as well as an IMAP account. In > many cases, the cloud account provides 2FA > which makes possession of the login password > not sufficient to gain access. However, IMAP > authentication hardly provide 2FA, and mail > may not benefit from the same protection and > could be used to escape 2FA. I believe this > could be mentioned as well as known > mechanisms to provide 2FA with IMAP - if > there are some. There are some drafts adding 2FA to SASL authentication that are likely to be discussed in the KITTEN WG. But at this point there is nothing that can be referenced normatively. I will think what can be said about that. > Note that 2FA may not necessarily prevent to > guess the correspondence between login and > password. > > The section mentions that repeated attempts > for a password associated is detected, > somehow prevented. It may also worth > mentioning that with a large number of login > (known or guessed), > an attacker may try to guess a login > associated to a small number of commonly > known weak passwords ( password > spraying). I believe it might worth being > mentioned, that correlating failed attempts > worth also being mentioned. Fair enough. Can you suggest some text? Maybe something around these lines: An IMAP server SHOULD report any authentication failure and analyze the att= empt with regard to a password brute force attack as well as a password spr= aying attack. Accounts that matching password spraying attacks MUST be bloc= ked and request to change their passwords and only password with significan= t strength SHOULD be accepted. > Maybe that goes a bit too far in the purpose > of recommendations, but it might may sense to > recommend strong random passwords used in > conjunction of passwords wallets or the use > of mutually authenticate TLS. > > > > > > One question I would have - and with very > little opinion on it - is how vulnerable IMAP > parsing is to injection. I usually see the > use of JSON as a big advantage toward > this, but I would be happy to known > your opinion on it. Can you give me an example, as I am not sure what do you mean by injection in this case? I do not have specific example in mind. My question was if there are known = ways to inject some commands in a specific field or if some parsers checks = have been relaxed to enable interoperability. > I also have the impression that injections > can be performed via the web interface, so a > web front end should be carefully considered > and IMAP server may not believe they are > always immune behind a web front end and > still require to follow the best practises. > > Best Regards, Alexey --_000_DM6PR15MB2379AD34B141FD5015D25E86E3A30DM6PR15MB2379namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Alexey, 

Thanks for your response. Please find some clarifications/responses. <= /div>

Yours, 
Daniel

From: Alexey Melnikov <a= lexey.melnikov@isode.com>
Sent: Tuesday, January 19, 2021 12:46 PM
To: Daniel Migault <daniel.migault@ericsson.com>; secdir@ietf.= org <secdir@ietf.org>
Cc: draft-ietf-extra-imap4rev2.all@ietf.org <draft-ietf-extra-ima= p4rev2.all@ietf.org>; extra@ietf.org <extra@ietf.org>; last-call@i= etf.org <last-call@ietf.org>
Subject: Re: Secdir last call review of draft-ietf-extra-imap4rev2-2= 4
 
Hi Daniel,

Thank you for your review. My replies below. I removed some of your
comments that I need to think a bit more and will reply to them separately.=

On 19/01/2021 14:52, Daniel Migault via Datatracker wrote:
> Reviewer: Daniel Migault
> Review result: Has Nits
>
> 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 t= he
> security area directors.  Document editors and WG chairs should t= reat
> these comments just like any other last call comments.
>
> The summary of the review is: Ready though I found some nits in
> the security consideration.
>
> Please find my comments/ questions below.
>
> Yours,
> Daniel
>
>
>  
>
>
>         Internet Message Acces= s Protocol (IMAP) - Version 4rev2
>            = ;           draft-ietf-ex= tra-imap4rev2-24
>
>
> [ ... ]
>
>     $Phishing  The $Phishing keyword can be u= sed by a delivery agent to
>        mark a message as highly lik= ely to be a phishing email.  An email
>        that's determined to be a ph= ishing email by the delivery agent
>        should also be considered a = junk email and have the appropriate
>        junk filtering applied, incl= uding setting the $Junk flag and
>        placing in the \Junk special= -use mailbox (see Section 7.2.3) if
>        available.
>        If both the $Phishing flag a= nd the $Junk flag are set, the user
>        agent should display an addi= tional warning message to the user.
>        User agents should not use t= he term "phishing" in their warning
>        message as most users do not= understand this term.  Phrasing of
>        the form "this message = may be trying to steal your personal
>        information" is recomme= nded.  Additionally the user agent may
>        display a warning when click= ing on any hyperlinks within the
>        message.
>
> <mglt>
> I tend to believe that phishing is now
> (unfortunately) known by most users.
> I have the impression that UI is always a
> difficult problem, and I am wondering if such
> recommendations are still valid or if that is
> a legacy statement. I do not have strong
> feeling about what to do, so I leave it to
> you, but is interested in your opinion.
This text matches the original registration of the $Phishing keyword. I have seen some modern email clients still following this advice, so I
think it is useful. Which part of it do you find outdated?

<mglt>

Just to be cl= ear that was just a comment. In the following sentence,  <= br>
"""
User agents should not use t= he term "phishing" in their warning
message as most users do not understand this term.&nb= sp; 
"""
I was questioning = ; "as most users do not understand this term" and tend to believe that most users have heard what phishing me= ans. So I am wondering if the user the message is being shown does not tran= slate to itself: "Oh yeah they mean phishing".  Again just s= ome random thoughts from my part.

</mglt>
> </mglt>
>
> [ ... ]
>
> 6.2.3.  LOGIN Command
>
>     Arguments:  user name
>            = ;     password
>
>     Responses:  no specific responses for thi= s command
>
>     Result:     OK - login com= pleted, now in authenticated state
>            = ;     NO - login failure: user name or password rejecte= d
>            = ;     BAD - command unknown or arguments invalid
>
>     The LOGIN command identifies the client to the= server and carries the
>     plaintext password authenticating this user. >
>     A server MAY include a CAPABILITY response cod= e in the tagged OK
>     response to a successful LOGIN command in orde= r to send capabilities
>     automatically.  It is unnecessary for a c= lient to send a separate
>     CAPABILITY command if it recognizes these auto= matic capabilities.
>
>
>
> Melnikov & Leiba        &n= bsp; Expires July 9, 2021        &n= bsp;        [Page 32]
> 
> Internet-Draft         &n= bsp;        IMAP4rev2   &= nbsp;           &nbs= p;   January 2021
>
>
>        Example:    C= : a001 LOGIN SMITH SESAME
>            = ;        S: a001 OK LOGIN completed
>
>     Note: Use of the LOGIN command over an insecur= e network (such as the
>     Internet) is a security risk, because anyone m= onitoring network
>     traffic can obtain plaintext passwords.  = The LOGIN command SHOULD NOT
>     be used except as a last resort, and it is rec= ommended that client
>     implementations have a means to disable any au= tomatic use of the
>     LOGIN command.
>
> <mglt>
> For my personal information.  It is unclear
> to me why the LOGIN command is SHOULD NOT and
> not MUST NOT. I am mostly likely missing
> something, but my impression was so far that
> STARTTLS was mandatory. I suppose that "a
> configuration" means that it is not always
> the case, but then it becomes unclear to me
> why we would have STARTTLS in one
> configuration but not the other. This sounds
> to me that we are sort of allowing a
> vulnerable configuration as long the server
> may be accessed with a secure configuration.
> I think I am missing some dots.

Thank you for drawing my attention to this. I agree that the text is
wrong. I think the intent was to allow LOGIN on "secure networks"= and
disallow it otherwise. After rereading this the quoted paragraph is not saying that. I will fix.

> </mglt>
>
>     Unless either the client is accessing IMAP ser= vice on IMAPS port
>     [RFC8314], the STARTTLS command has been negot= iated or some other
>     mechanism that protects the session from passw= ord snooping has been
>     provided, a server implementation MUST impleme= nt a configuration in
>     which it advertises the LOGINDISABLED capabili= ty and does NOT permit
>     the LOGIN command.  Server sites SHOULD N= OT use any configuration
>     which permits the LOGIN command without such a= protection mechanism
>     against password snooping.  A client impl= ementation MUST NOT send a
>     LOGIN command if the LOGINDISABLED capability = is advertised.
>
> [... ]
>
> 11.  Security Considerations
>
>     IMAP4rev2 protocol transactions, including ele= ctronic mail data, are
>     sent in the clear over the network unless prot= ection from snooping is
>     negotiated.  This can be accomplished eit= her by the use of IMAPS
>     service, STARTTLS command, negotiated privacy = protection in the
>     AUTHENTICATE command, or some other protection= mechanism.
>
> 11.1.  STARTTLS Security Considerations
>
>     IMAP client and server implementations MUST co= mply with relevant TLS
>     recommendations from [RFC8314].
>
>
>
>
>
> Melnikov & Leiba        &n= bsp; Expires July 9, 2021        &n= bsp;       [Page 143]
> 
> Internet-Draft         &n= bsp;        IMAP4rev2   &= nbsp;           &nbs= p;   January 2021
>
>
>     Clients and servers MUST implement TLS 1.2 [TL= S-1.2] or newer.  Use
>     of TLS 1.3 [TLS-1.3] is RECOMMENDED.  TLS= 1.2 may be used only in
>     cases where the other party has not yet implem= ented TLS 1.3.
>     Additionally, when using TLS 1.2, IMAP impleme= ntations MUST implement
>     TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher s= uite, and SHOULD
>     implement the TLS_RSA_WITH_AES_128_CBC_SHA [TL= S-1.2] cipher suite.
>
> <mglt>
> I suspect there is an issue and that
> TLS_RSA_WITH_AES_128_CBC_SHA  is instead
> TLS_RSA_WITH_AES_128_CBC_SHA256.
>
> However, these suites are not set as
> "recommended" on the IANA registry.  Note
> that the term recommended may be misleading
> as it does not necessarily means the cipher
> is weak. It means instead that the cipher
> suite has not been through a standard
> process.  This could mean, for example, the
> cipher suite may correspond to a specific use
> case. If that is the case, I believe that
> should be mentioned.  However, I believe that
> in this case, the motivation for the
> community is that RSA authentication suffers
> from a significant number of attacks - [1],
> no forward secrecy - and I tend to believe
> its support may not be recommended. RFC7525
> for example mentions it as SHOULD NOT.
Good point. I will remove TLS_RSA_WITH_AES_128_CBC_SHA from the document. > [1]https://www.usenix.org/conference/usenixsecurity18/presentation/boc= k
>
>
>
> In order to defer the cryptographic
> recommendations to RFC8447, and ensure these
> recommendations to be update to date, I would
> reference that the TLS client and server are
> expected to follow RFC8447 for their
> cryptographic recommendations. Currently
> RFC8847 sets a cipher suite as recommended
> when it has received a wide support from the
> community and it intend is as far as I think
> to remove ciphers that will become weak.
>
> RFC8447 works for TLS 1.2 and 1.3  keeps the
> number of cipher suites relatively low, so if
> the motivation to mandate
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and
> LS_RSA_WITH_AES_128_CBC_SHA256 was to keep
> the number of cipher suites low. If that is
> the case,
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 may
> be a better fit at least in my opinion.
Ok.
> </mglt>
>
>     This is important as it assures that any two c= ompliant
>     implementations can be configured to interoper= ate.  Other TLS cipher
>     suites recommended in RFC 7525 are RECOMMENDED= :
>     TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
>     TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and
>     TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.  A= ll other cipher suites are
>     OPTIONAL.  Note that this is a change fro= m section 2.1 of [IMAP-TLS].
>
> <mglt>
> I believe this is good to mention RFC7525 for
> TLS 1.2. There might small overlap concerning
> cipher recommendations with RFC8447, but
> RFC7525 recommendations go beyond and is not
> limited to cipher suites recommendations.
>
> Regarding the RSA versus ECDSA it seems to me
> that RSA is a bit behind. [1] mentions ECDSA
> and RSA in their intermediate profile with
> ECDSA recommended. I would maybe avoid
> explicitly recommend these cipher suites, and
> if that is needed, I would explain why these
> are recommended.
>
> [1]https://wiki.mozilla.org/Security/Server_Side_TLS
Thank you for the link, I will review.
> </mglt>
>
>     The list of mandatory-to-implement TLS 1.3 cip= her suites is described
>     in Section 9.1 of [TLS-1.3].
>
  [snip]
>     Both the client and server MUST check the resu= lt of the STARTTLS
>     command and subsequent TLS ([TLS-1.3][TLS-1.2]= ) negotiation to see
>     whether acceptable authentication and/or priva= cy was achieved.
>
> <mglt>
> This is a bit unclear to me as I do not
> expect to have a server / client accepting
> cipher_suites, or being configured to
> establish a TLS session that does not achieve
> what we expect. In other word, I understand
> the paragraph as saying after the
> session establishment, we recheck that
> parameters chosen are appropriated. I suppose
> I am missing something, but if not I would
> have expected it to be the other way around.

I don't think all implementations control cipher suites to be used
before negotiation starts (this might be API and/or implementation
limitation), so this is encouraging to check whether negotiated
ciphersuite matches policy after negotiation completes.

<mglt>
ok, I agree this maybe the case for the client, bu= t I expect the server to have its library being "specifically" co= nfigured. 

</mglt>

> </mglt>
>
  [snip]
> 11.4.  Other Security Considerations
>
>     A server error message for an AUTHENTICATE com= mand which fails due to
>     invalid credentials SHOULD NOT detail why the = credentials are
>     invalid.
>
>     Use of the LOGIN command sends passwords in th= e clear.  This can be
>     avoided by using the AUTHENTICATE command with= a [SASL] mechanism
>     that does not use plaintext passwords, by firs= t negotiating
>     encryption via STARTTLS or some other protecti= on mechanism.
>
>     A server implementation MUST implement a confi= guration that, at the
>     time of authentication, requires:
>     (1) The STARTTLS command has been negotiated.<= br> >     OR
>     (2) Some other mechanism that protects the ses= sion from password
>     snooping has been provided.
>     OR
>     (3) The following measures are in place:
>     (a) The LOGINDISABLED capability is advertised= , and [SASL] mechanisms
>     (such as PLAIN) using plaintext passwords are = NOT advertised in the
>     CAPABILITY list.
>     AND
>     (b) The LOGIN command returns an error even if= the password is
>     correct.
>     AND
>     (c) The AUTHENTICATE command returns an error = with all [SASL]
>     mechanisms that use plaintext passwords, even = if the password is
>     correct.
>
>     A server error message for a failing LOGIN com= mand SHOULD NOT specify
>     that the user name, as opposed to the password= , is invalid.
>
>     A server SHOULD have mechanisms in place to li= mit or delay failed
>     AUTHENTICATE/LOGIN attempts.
>
>     Additional security considerations are discuss= ed in the section
>     discussing the AUTHENTICATE (see Section 6.2.2= ) and LOGIN (see
>     Section 6.2.3) commands.
>
> <mglt>
> Another concern regarding
> authentication with IMAP is user have usually
> one account and one login/password for a
> cloud account as well as an IMAP account. In
> many cases, the cloud account provides 2FA
> which makes possession of the login password
> not sufficient to gain access. However, IMAP
> authentication hardly provide 2FA, and mail
> may not benefit from the same protection and
> could be used to escape 2FA. I believe this
> could be mentioned as well as known
> mechanisms to provide 2FA with IMAP - if
> there are some.
There are some drafts adding 2FA to SASL authentication that are likely to be discussed in the KITTEN WG. But at this point there is nothing
that can be referenced normatively. I will think what can be said about that.
> Note that 2FA may not necessarily prevent to
> guess the correspondence between login and
> password.
>
> The section mentions that repeated attempts
> for a password associated is detected,
> somehow prevented. It may also worth
> mentioning that with a large number of login
> (known or guessed),
> an attacker may try to guess a login
> associated to a small number of commonly
> known weak passwords ( password
> spraying). I believe it might worth being
> mentioned, that correlating failed attempts
> worth also being mentioned.
Fair enough. Can you suggest some text?

<mglt>
Maybe something around these lines:

An IMAP server SHOULD report any authentication fa= ilure and analyze the attempt with regard to a password brute force attack = as well as a password spraying attack. Accounts that matching password spra= ying attacks MUST be blocked and request to change their passwords and only password with significant strength SHOU= LD be accepted. 
</mglt> 

> Maybe that goes a bit too far in the purpose<= br> > of recommendations, but it might may sense to
> recommend strong random passwords used in
> conjunction of passwords wallets or the use
> of mutually authenticate TLS.
>
> </mglt>
>
>
> <mglt>
> One question I would have - and with very
> little opinion on it - is how vulnerable IMAP
> parsing is to injection. I usually see the
> use of JSON as a big advantage toward
> this, but I would be happy to known
> your opinion on it.
Can you give me an example, as I am not sure what do you mean by
injection in this case?

<mglt>
I do not have specific example in mind. My questio= n was if there are known ways to inject some commands in a specific field o= r if some parsers checks have been relaxed to enable interoperability. = ;

</mglt>

> I also have the impression that injections
> can be performed via the web interface, so a
> web front end should be carefully considered
> and IMAP server may not believe they are
> always immune behind a web front end and
> still require to follow the best practises.
>
> </mglt>

Best Regards,

Alexey

--_000_DM6PR15MB2379AD34B141FD5015D25E86E3A30DM6PR15MB2379namp_-- From nobody Tue Jan 19 19:14: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 CCB573A0CB5; Tue, 19 Jan 2021 19:14:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Chris Lonvick via Datatracker To: Cc: draft-ietf-pce-association-bidir.all@ietf.org, last-call@ietf.org, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161111248778.9321.14389087731876214196@ietfa.amsl.com> Reply-To: Chris Lonvick Date: Tue, 19 Jan 2021 19:14:47 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-pce-association-bidir-10 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 Jan 2021 03:14:48 -0000 Reviewer: Chris Lonvick Review result: Ready 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. The Security Considerations section is a bit light, but addresses the matter. The only nit I found was that in the Security Considerations section, the use of TLS for securing the PCEP session is "recommended". I think that's a BCP 14 keyword so should be "RECOMMENDED". (I don't think that's significant enough to change the summary to Has Nits.) Best regards, Chris From nobody Tue Jan 19 20:49: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 D34DE3A0D03; Tue, 19 Jan 2021 20:49:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Watson Ladd via Datatracker To: Cc: draft-ietf-rift-applicability.all@ietf.org, last-call@ietf.org, rift@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161111819082.6760.13942493068778566822@ietfa.amsl.com> Reply-To: Watson Ladd Date: Tue, 19 Jan 2021 20:49:50 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-rift-applicability-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: Wed, 20 Jan 2021 04:49:51 -0000 Reviewer: Watson Ladd Review result: Has Nits I read this document. I found it had very helpful and informative examples. My one complaint is a nit. My first issue is that https://tools.ietf.org/html/rfc7322#section-4.8.5 says all RFCs must have security considerations. Yes, even ones like this one listing example networks and failures. In this case a short reference to the security section of RIFT is entirely appropriate. I do have questions about the empty Acknowledgements section and the Contributors section with one person and address: seems a bit odd to me. Sincerely, Watson Ladd From nobody Wed Jan 20 09:31:34 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 BFB313A1028; Wed, 20 Jan 2021 09:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 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, NICE_REPLY_A=-0.262, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=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=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 6HFP6p3DBRt1; Wed, 20 Jan 2021 09:31:19 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id AB0D73A0AE8; Wed, 20 Jan 2021 09:31:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1611163877; d=isode.com; s=june2016; i=@isode.com; bh=M8tMXbRgBudrl2UlcRB0PCcw71rntN+ExU926NUd1yw=; 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=KuVoDbuCQAC7t0YzRBnpv40snSqvoyKdEGgdGhBlmI4TaRveHE4VjsNRmbCJikhVL6nnDl F6CUoOEQQ8Shx0I9zLak+yfIJaW4bPpl4RX4tPXxQjnIX3s/obS9v4phjQXF/Ed6OWCZln dZ9u6heY+05x+XEGu3ZdFO6MkdlJMWw=; Received: from [172.27.250.196] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 20 Jan 2021 17:31:16 +0000 To: Daniel Migault , "secdir@ietf.org" Cc: "draft-ietf-extra-imap4rev2.all@ietf.org" , "extra@ietf.org" , "last-call@ietf.org" References: <161106792581.26552.4563982290675643872@ietfa.amsl.com> <99082ebc-318b-5c4d-a9e6-b3893ab99c0d@isode.com> From: Alexey Melnikov Message-ID: Date: Wed, 20 Jan 2021 17:31:07 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------13083B1379C3450CCE4C04B9" Content-Language: en-GB Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-extra-imap4rev2-24 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 Jan 2021 17:31:25 -0000 --------------13083B1379C3450CCE4C04B9 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable Hi Daniel, On 19/01/2021 20:46, Daniel Migault wrote: > Hi Alexey, > > Thanks for your response. Please find some clarifications/responses. Thank you for the followup. My responses below. > > Yours, > Daniel > > ------------------------------------------------------------------------ > *From:* Alexey Melnikov > *Sent:* Tuesday, January 19, 2021 12:46 PM > *To:* Daniel Migault ; secdir@ietf.org=20 > > *Cc:* draft-ietf-extra-imap4rev2.all@ietf.org=20 > ; extra@ietf.org=20 > ; last-call@ietf.org > *Subject:* Re: Secdir last call review of draft-ietf-extra-imap4rev2-24 > Hi Daniel, > > Thank you for your review. My replies below. I removed some of your > comments that I need to think a bit more and will reply to them=20 > separately. > > On 19/01/2021 14:52, Daniel Migault via Datatracker wrote: > > Reviewer: Daniel Migault > > Review result: Has Nits > > =A0[snip] > > > > [ ... ] > > > >=A0=A0=A0=A0 $Phishing=A0 The $Phishing keyword can be used by a delivery= agent to > >=A0=A0=A0=A0=A0=A0=A0 mark a message as highly likely to be a phishing em= ail.=A0 An email > >=A0=A0=A0=A0=A0=A0=A0 that's determined to be a phishing email by the del= ivery agent > >=A0=A0=A0=A0=A0=A0=A0 should also be considered a junk email and have the= appropriate > >=A0=A0=A0=A0=A0=A0=A0 junk filtering applied, including setting the $Junk= flag and > >=A0=A0=A0=A0=A0=A0=A0 placing in the \Junk special-use mailbox (see Secti= on 7.2.3) if > >=A0=A0=A0=A0=A0=A0=A0 available. > >=A0=A0=A0=A0=A0=A0=A0 If both the $Phishing flag and the $Junk flag are s= et, the user > >=A0=A0=A0=A0=A0=A0=A0 agent should display an additional warning message = to the user. > >=A0=A0=A0=A0=A0=A0=A0 User agents should not use the term "phishing" in t= heir warning > >=A0=A0=A0=A0=A0=A0=A0 message as most users do not understand this term.= =A0 Phrasing of > >=A0=A0=A0=A0=A0=A0=A0 the form "this message may be trying to steal your = personal > >=A0=A0=A0=A0=A0=A0=A0 information" is recommended.=A0 Additionally the us= er agent may > >=A0=A0=A0=A0=A0=A0=A0 display a warning when clicking on any hyperlinks w= ithin the > >=A0=A0=A0=A0=A0=A0=A0 message. > > > > > > I tend to believe that phishing is now > > (unfortunately) known by most users. > > I have the impression that UI is always a > > difficult problem, and I am wondering if such > > recommendations are still valid or if that is > > a legacy statement. I do not have strong > > feeling about what to do, so I leave it to > > you, but is interested in your opinion. > This text matches the original registration of the $Phishing keyword. I > have seen some modern email clients still following this advice, so I > think it is useful. Which part of it do you find outdated? > > > > Just to be clear that was just a comment. In the following sentence, > """ > User agents should not use the term "phishing" in their warning > message as most users do not understand this term. > """ > I was questioning=A0 "as most users do not understand this term" and=20 > tend to believe that most users have heard what phishing means. So I=20 > am wondering if the user the message is being shown does not translate=20 > to itself: "Oh yeah they mean phishing".=A0 Again just some random=20 > thoughts from my part. Sorry, I was staring at this text so much that I stopped noticing it.=20 Now that you pointed this out I think removing this sentence makes sense. > > =A0[snip] > > > > The section mentions that repeated attempts > > for a password associated is detected, > > somehow prevented. It may also worth > > mentioning that with a large number of login > > (known or guessed), > > an attacker may try to guess a login > > associated to a small number of commonly > > known weak passwords ( password > > spraying). I believe it might worth being > > mentioned, that correlating failed attempts > > worth also being mentioned. > Fair enough. Can you suggest some text? > > > Maybe something around these lines: > > An IMAP server SHOULD report any authentication failure and analyze=20 > the attempt with regard to a password brute force attack as well as a=20 > password spraying attack. Accounts that matching password spraying=20 > attacks MUST be blocked and request to change their passwords and only=20 > password with significant strength SHOULD be accepted. I edited this slightly. Thank you for the suggestion. > /**/ > > > > Maybe that goes a bit too far in the purpose > > of recommendations, but it might may sense to > > recommend strong random passwords used in > > conjunction of passwords wallets or the use > > of mutually authenticate TLS. > > > > > > > > > > > > One question I would have - and with very > > little opinion on it - is how vulnerable IMAP > > parsing is to injection. I usually see the > > use of JSON as a big advantage toward > > this, but I would be happy to known > > your opinion on it. > Can you give me an example, as I am not sure what do you mean by > injection in this case? > > > I do not have specific example in mind. My question was if there are=20 > known ways to inject some commands in a specific field or if some=20 > parsers checks have been relaxed to enable interoperability. I can't think of any. IMAP is either using octet-counted literals or=20 strict syntax (LIST-like). Syntax is quite regular and easier than XML=20 (IMHO). > > > > > I also have the impression that injections > > can be performed via the web interface, so a > > web front end should be carefully considered > > and IMAP server may not believe they are > > always immune behind a web front end and > > still require to follow the best practises. > > > > > > Best Regards, > > Alexey > --------------13083B1379C3450CCE4C04B9 Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable

Hi Daniel,


On 19/01/2021 20:46, Daniel Migault wrote:
Hi Alexey,=A0

Thanks for your response. Please find some clarifications/responses.
Thank you for the followup. My responses below.

Yours,=A0
Daniel

From: Alexey Melnikov <alexey.melnikov@isode.com>
Sent: Tuesday, January 19, 2021 12:46 PM
To: Daniel Migault <daniel.migault@ericsson.com><= /a>; secdir@ietf.org <secdir@ietf.org>
Cc: draft-ietf-extra-imap4rev2.all@ietf.o= rg <draft-ietf-extra-imap4rev2.all@ietf.org>= ; extra@ietf.org <extra@ietf.org>; last-call@ietf.org <last-call@ietf.org>
Subject: Re: Secdir last call review of draft-ietf-extra-imap4rev2-24
=A0
Hi Daniel,

Thank you for your review. My replies below. I removed some of your
comments that I need to think a bit more and will reply to them separately.

On 19/01/2021 14:52, Daniel Migault via Datatracker wrote:
> Reviewer: Daniel Migault
> Review result: Has Nits
>
=A0[snip]
>
> [ ... ]
>
>=A0=A0=A0=A0 $Phishing=A0 The $Phishing keyword can be use= d by a delivery agent to
>=A0=A0=A0=A0=A0=A0=A0 mark a message as highly likely to b= e a phishing email.=A0 An email
>=A0=A0=A0=A0=A0=A0=A0 that's determined to be a phishing e= mail by the delivery agent
>=A0=A0=A0=A0=A0=A0=A0 should also be considered a junk ema= il and have the appropriate
>=A0=A0=A0=A0=A0=A0=A0 junk filtering applied, including se= tting the $Junk flag and
>=A0=A0=A0=A0=A0=A0=A0 placing in the \Junk special-use mai= lbox (see Section 7.2.3) if
>=A0=A0=A0=A0=A0=A0=A0 available.
>=A0=A0=A0=A0=A0=A0=A0 If both the $Phishing flag and the $= Junk flag are set, the user
>=A0=A0=A0=A0=A0=A0=A0 agent should display an additional w= arning message to the user.
>=A0=A0=A0=A0=A0=A0=A0 User agents should not use the term = "phishing" in their warning
>=A0=A0=A0=A0=A0=A0=A0 message as most users do not underst= and this term.=A0 Phrasing of
>=A0=A0=A0=A0=A0=A0=A0 the form "this message may be trying= to steal your personal
>=A0=A0=A0=A0=A0=A0=A0 information" is recommended.=A0 Addi= tionally the user agent may
>=A0=A0=A0=A0=A0=A0=A0 display a warning when clicking on a= ny hyperlinks within the
>=A0=A0=A0=A0=A0=A0=A0 message.
>
> <mglt>
> I tend to believe that phishing is now
> (unfortunately) known by most users.
> I have the impression that UI is always a
> difficult problem, and I am wondering if such
> recommendations are still valid or if that is
> a legacy statement. I do not have strong
> feeling about what to do, so I leave it to
> you, but is interested in your opinion.
This text matches the original registration of the $Phishing keyword. I
have seen some modern email clients still following this advice, so I
think it is useful. Which part of it do you find outdated?

<mglt>

Ju= st to be clear that was just a comment. In the following sentence,=A0=A0
"""
User agents should not use the term "phishing" in their warning
message as most users do not understand this term.=A0=A0=
"""
I was questioning=A0 "as most users do not understand this term" and tend to believe that most users have heard what phishing means. So I am wondering if the user the message is being shown does not translate to itself: "Oh yeah they mean phishing".=A0 Again just some random thoughts from my part.
Sorry, I was staring at this text so much that I stopped noticing it. Now that you pointed this out I think removing this sentence makes sense.

</mglt>
=A0[snip]
>
> The section mentions that repeated attempts
> for a password associated is detected,
> somehow prevented. It may also worth
> mentioning that with a large number of login
> (known or guessed),
> an attacker may try to guess a login
> associated to a small number of commonly
> known weak passwords ( password
> spraying). I believe it might worth being
> mentioned, that correlating failed attempts
> worth also being mentioned.
Fair enough. Can you suggest some text?

<mglt>
Maybe something around these lines:

An IMAP server SHOULD report any authentication failure and analyze the attempt with regard to a password brute force attack as well as a password spraying attack. Accounts that matching password spraying attacks MUST be blocked and request to change their passwords and only password with significant strength SHOULD be accepted.
I edited this slightly. Thank you for the suggestion.
</mglt>=A0

> Maybe that goes a bit too far in the purpose
> of recommendations, but it might may sense to
> recommend strong random passwords used in
> conjunction of passwords wallets or the use
> of mutually authenticate TLS.
>
> </mglt>
>
>
> <mglt>
> One question I would have - and with very
> little opinion on it - is how vulnerable IMAP
> parsing is to injection. I usually see the
> use of JSON as a big advantage toward
> this, but I would be happy to known
> your opinion on it.
Can you give me an example, as I am not sure what do you mean by
injection in this case?

<mglt>
I do not have specific example in mind. My question was if there are known ways to inject some commands in a specific field or if some parsers checks have been relaxed to enable interoperability.
I can't think of any. IMAP is either using octet-counted literals or strict syntax (LIST-like). Syntax is quite regular and easier than XML (IMHO).

</mglt>

> I also have the impression that injections
> can be performed via the web interface, so a
> web front end should be carefully considered
> and IMAP server may not believe they are
> always immune behind a web front end and
> still require to follow the best practises.
>
> </mglt>

Best Regards,

Alexey

--------------13083B1379C3450CCE4C04B9-- From nobody Wed Jan 20 10:22: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 8B0613A11B5; Wed, 20 Jan 2021 10:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, 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, 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=ericsson.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 WPrcfCDz8Vlh; Wed, 20 Jan 2021 10:22:18 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2049.outbound.protection.outlook.com [40.107.220.49]) (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 9B8893A11B6; Wed, 20 Jan 2021 10:22:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S0+igAr8foh6zqlVJV0oaLufXVBGCg4+Ud1Qc7umCL1644wyvWKyxBQwb38paQDbFBMqYVBNKapOAEmm0Ak17P6lFS72cXfAXM8iOK4+T7XFp0D2rjWNCO8OOSISKEeroKoGKtRUAqV2ahNj4BletJLLm7vI55uiKVHEnomWgb5a7FKNTo8O08Rl1LDuWxLC2FNHhKR9vu1iA8GDtpFQ79JiQu17KhFl7J7d0I/DvOoqGwUJiGYTuLqq9y0SNrk5tGtVEoN+qjCTHNbAIvJ67RV5u4kJz3qoMHV14i6IqcO6S+srmVIgSqPcewxUpt9ofvZQ+eNKMKLn7YaHLZePRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MEO3CUHPFCpmt0LfX2T5d+4QiR0GEqXudOrTiEzGMD8=; b=eNqiI+TUjhE4kubK0UaYiD3BmR9I53oRZ7AndMNVzDhTaI98FvY/s/jC5W9Uf8Klk3SKh8rkrTrfTf/UPB6HLMG0AmHO07/qOnH5OaWtgouE7+sjEnIPnDyaZDS5NMvdNXrOs8TlP5PR+rrV3UYhclCtz3peGKQDnduYehPCT05fOtY9sBezOPpWmoI9CBx1Mys1VGO5Vk1pc6Eb0VpT4sVgc/E0AowfAmBstNL6c3QoJIJCpMyKCwSQw/5b3rplNmz2TWL7YcX3ON2H2YVMRnPARrEyg2FW/bZX5UJvudJH6o5QV7mG/2J1rsJ5oFBe7YwU/990LjV51tYYIxK+HA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MEO3CUHPFCpmt0LfX2T5d+4QiR0GEqXudOrTiEzGMD8=; b=X0OphG7tLHyTeor0x7WG/8OYN2cVKcnTz9Cy5YU0dItaV79OcwyFk3G8qVK1DR5CmRtlsYfQao62WvoWhWaEmGfyAhtMlZan9UyjYIJDSaR+cu0yOmjxhmqlv4kheTDRqnINeV2qMQRfMpFUUwpE25ZcVoX8mioNEnLgtRxeUQQ= Received: from DM6PR15MB2379.namprd15.prod.outlook.com (2603:10b6:5:8a::16) by DM6PR15MB4005.namprd15.prod.outlook.com (2603:10b6:5:294::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.11; Wed, 20 Jan 2021 18:22:16 +0000 Received: from DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::a9f9:326f:8cfb:157b]) by DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::a9f9:326f:8cfb:157b%7]) with mapi id 15.20.3763.014; Wed, 20 Jan 2021 18:22:16 +0000 From: Daniel Migault To: Alexey Melnikov , "secdir@ietf.org" CC: "draft-ietf-extra-imap4rev2.all@ietf.org" , "extra@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-extra-imap4rev2-24 Thread-Index: AQHW7osBCZRYcejh/kaFOg7r/oDlOqovTFtxgAF6oICAAA4TNQ== Date: Wed, 20 Jan 2021 18:22:16 +0000 Message-ID: References: <161106792581.26552.4563982290675643872@ietfa.amsl.com> <99082ebc-318b-5c4d-a9e6-b3893ab99c0d@isode.com> , 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=ericsson.com; x-originating-ip: [96.22.11.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fe2391ab-e7bb-4b04-7630-08d8bd7050cb x-ms-traffictypediagnostic: DM6PR15MB4005: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PFKxMv8WyveqjET9E0t0xwIqV287zDkocc/gX6CI9C/LBIz9JMlmRFy+PWGZR+nhamBqIo1Tos0flXFlA8qHJB6BRv9R78vERbwZERQmzuGMmdDQGAfvSXONXcN7Xg1AcwAEdRs0BKvmESgdH0ht/OzdJY6rrBmddwVC7SOVVjgkFxOVS5Z7CGbZ0cvVLeg7ul+L3PvV6cPFo+ql8iTKNLlspkvzeVSlHzt6qDRx9gwCKbf64G6E9Yibn+NgbgZtsLlj4IBKTz18nuVRoeEftqrICxIkcFSvK4aIdgyBR+QB7FtDIjXbmAe0G/b8TlLnr7yKD8oSpesLgQXEnry2bMrIpxTdrmEJ7HG+OqPvZnlxVB1p6RHQuSfErEdGFjG/vG3jnz02KpaPkLg/6qKUHA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR15MB2379.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(346002)(366004)(396003)(39860400002)(54906003)(64756008)(19627405001)(52536014)(66476007)(66446008)(5660300002)(2906002)(7696005)(316002)(91956017)(26005)(33656002)(76116006)(44832011)(186003)(66946007)(8936002)(71200400001)(66556008)(83380400001)(9686003)(86362001)(55016002)(110136005)(8676002)(478600001)(53546011)(6506007)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?Y3ndetPOyLqhXL0b+dGtwiXWJXyEVs52cJ1YLf5JedOBiXwluDcSCUpz/GUP?= =?us-ascii?Q?sIXuUlJiTl1N2RJN46G0uwJ7ZigT7MkHvuYDMjbfBLbFrda6sa0LEm1Ct4K2?= =?us-ascii?Q?Dg7seXFjMwnxW19+GRoamQTH0j0gDx/x95ZbZ6cQkyohFqaixT2NRZLUxHra?= =?us-ascii?Q?0HtfgxbDLnfURIt2tV0gpXPSez6TIuVM9c+PpFSvoDqvZRfqS8tv0TNaZt/0?= =?us-ascii?Q?qFlJFF34AJ24doTnegQhgZEewfkPSs491v4WpVaFMvUzQ5fhKZj9vR+Qn9OF?= =?us-ascii?Q?P5E+la12tv9oOszEJiRca35Qw634L15iQFtA0k0p3lqWYFl2morEWUy74ehr?= =?us-ascii?Q?wfnqHXRUudne8wsdhA1Duf0m79JXZ07JSJWGhERYvA54u9Qfwg+Px3MpemC/?= =?us-ascii?Q?OIcnpUAQI7/bH/dATFrLEoeixBrrKfKyTIp8kD1AnXQ6X4NWO+Q6oGnq5ztG?= =?us-ascii?Q?7+aopdhSvGAkJxvjI38NbzYm1NASbtKjpVUOkTkpdv6Bf45uMECrgOruclcg?= =?us-ascii?Q?D/Itjz1LaDeXUqAaMR7MqLbCYkAtbHxPyiiGhEkOvy3n/moD7Q0KHtEW1RAu?= =?us-ascii?Q?4XhnHRFHZaTJr/4aKrJ4Oe0lUrEy3OqWhfxK5I5uxY/iWNtyexnXvVlg2klE?= =?us-ascii?Q?5PZhpSpZFnM3fNZhMAuuSPcQwFHVvM07vDkI+E2WfQdUoT0FpaYmN8kQxkCr?= =?us-ascii?Q?LeRLBld2enDGZ2DCI1++gL9LTDnVpUlTWSjAVQ/0+kEzNrm0BwTzqD2tmdDn?= =?us-ascii?Q?LPHfiLYbelVKZ5Js8GW21jIPO+/N8RDqu4ZCRLKwVSTR79A7Sm2Ja43NuY1z?= =?us-ascii?Q?Nl0RA+W50JVN8X57MTQRb5hkOO37Bqp6Skgkj0WcdfizNxQ9RWNP9vnNpVVm?= =?us-ascii?Q?Pw3G7mnheITt6mvG+hQlRFtOpk6GtIY+eG0+1LCiw3mJgZ/8upPMg05CLMYa?= =?us-ascii?Q?H9JjUO6C0PX7nVNenJfby6QuOcxCHiygeKOa5tlJJBk=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR15MB2379B58281E066E4523B1404E3A20DM6PR15MB2379namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR15MB2379.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fe2391ab-e7bb-4b04-7630-08d8bd7050cb X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2021 18:22:16.1913 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qvc0XjKhL4fPpueZwekY7JnI1x+8qc8Bo0Dz9kCudO2nCRIsTuLDTo9j+moHaPNOWhy/BxJU3h60QOaxn6oOpEvU1+phxnV561eKBJ6ZAac= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB4005 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-extra-imap4rev2-24 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 Jan 2021 18:22:21 -0000 --_000_DM6PR15MB2379B58281E066E4523B1404E3A20DM6PR15MB2379namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the response! Yours, Daniel ________________________________ From: Alexey Melnikov Sent: Wednesday, January 20, 2021 12:31 PM To: Daniel Migault ; secdir@ietf.org Cc: draft-ietf-extra-imap4rev2.all@ietf.org ; extra@ietf.org ; last-call@ietf.org Subject: Re: Secdir last call review of draft-ietf-extra-imap4rev2-24 Hi Daniel, On 19/01/2021 20:46, Daniel Migault wrote: Hi Alexey, Thanks for your response. Please find some clarifications/responses. Thank you for the followup. My responses below. Yours, Daniel ________________________________ From: Alexey Melnikov Sent: Tuesday, January 19, 2021 12:46 PM To: Daniel Migault ; secdir@ietf.org Cc: draft-ietf-extra-imap4rev2.all@ietf.org ; extra@ietf.org ; last-call@ietf.org Subject: Re: Secdir last call review of draft-ietf-extra-imap4rev2-24 Hi Daniel, Thank you for your review. My replies below. I removed some of your comments that I need to think a bit more and will reply to them separately. On 19/01/2021 14:52, Daniel Migault via Datatracker wrote: > Reviewer: Daniel Migault > Review result: Has Nits > [snip] > > [ ... ] > > $Phishing The $Phishing keyword can be used by a delivery agent to > mark a message as highly likely to be a phishing email. An email > that's determined to be a phishing email by the delivery agent > should also be considered a junk email and have the appropriate > junk filtering applied, including setting the $Junk flag and > placing in the \Junk special-use mailbox (see Section 7.2.3) if > available. > If both the $Phishing flag and the $Junk flag are set, the user > agent should display an additional warning message to the user. > User agents should not use the term "phishing" in their warning > message as most users do not understand this term. Phrasing of > the form "this message may be trying to steal your personal > information" is recommended. Additionally the user agent may > display a warning when clicking on any hyperlinks within the > message. > > > I tend to believe that phishing is now > (unfortunately) known by most users. > I have the impression that UI is always a > difficult problem, and I am wondering if such > recommendations are still valid or if that is > a legacy statement. I do not have strong > feeling about what to do, so I leave it to > you, but is interested in your opinion. This text matches the original registration of the $Phishing keyword. I have seen some modern email clients still following this advice, so I think it is useful. Which part of it do you find outdated? Just to be clear that was just a comment. In the following sentence, """ User agents should not use the term "phishing" in their warning message as most users do not understand this term. """ I was questioning "as most users do not understand this term" and tend to = believe that most users have heard what phishing means. So I am wondering i= f the user the message is being shown does not translate to itself: "Oh yea= h they mean phishing". Again just some random thoughts from my part. Sorry, I was staring at this text so much that I stopped noticing it. Now t= hat you pointed this out I think removing this sentence makes sense. [snip] > > The section mentions that repeated attempts > for a password associated is detected, > somehow prevented. It may also worth > mentioning that with a large number of login > (known or guessed), > an attacker may try to guess a login > associated to a small number of commonly > known weak passwords ( password > spraying). I believe it might worth being > mentioned, that correlating failed attempts > worth also being mentioned. Fair enough. Can you suggest some text? Maybe something around these lines: An IMAP server SHOULD report any authentication failure and analyze the att= empt with regard to a password brute force attack as well as a password spr= aying attack. Accounts that matching password spraying attacks MUST be bloc= ked and request to change their passwords and only password with significan= t strength SHOULD be accepted. I edited this slightly. Thank you for the suggestion. > Maybe that goes a bit too far in the purpose > of recommendations, but it might may sense to > recommend strong random passwords used in > conjunction of passwords wallets or the use > of mutually authenticate TLS. > > > > > > One question I would have - and with very > little opinion on it - is how vulnerable IMAP > parsing is to injection. I usually see the > use of JSON as a big advantage toward > this, but I would be happy to known > your opinion on it. Can you give me an example, as I am not sure what do you mean by injection in this case? I do not have specific example in mind. My question was if there are known = ways to inject some commands in a specific field or if some parsers checks = have been relaxed to enable interoperability. I can't think of any. IMAP is either using octet-counted literals or strict= syntax (LIST-like). Syntax is quite regular and easier than XML (IMHO). > I also have the impression that injections > can be performed via the web interface, so a > web front end should be carefully considered > and IMAP server may not believe they are > always immune behind a web front end and > still require to follow the best practises. > > Best Regards, Alexey --_000_DM6PR15MB2379B58281E066E4523B1404E3A20DM6PR15MB2379namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks for the response!
Yours, 
Daniel
From: Alexey Melnikov <a= lexey.melnikov@isode.com>
Sent: Wednesday, January 20, 2021 12:31 PM
To: Daniel Migault <daniel.migault@ericsson.com>; secdir@ietf.= org <secdir@ietf.org>
Cc: draft-ietf-extra-imap4rev2.all@ietf.org <draft-ietf-extra-ima= p4rev2.all@ietf.org>; extra@ietf.org <extra@ietf.org>; last-call@i= etf.org <last-call@ietf.org>
Subject: Re: Secdir last call review of draft-ietf-extra-imap4rev2-2= 4
 

Hi Daniel,


On 19/01/2021 20:46, Daniel Migault wrote:=
Hi Alexey, 

Thanks for your response. Please find some clarifications/responses.
Thank you for the followup. My responses below.

Yours, 
Daniel

From: Alexey Melnikov <alexey.melnikov@isode.com>
Sent: Tuesday, January 19, 2021 12:46 PM
To: Daniel Migault <daniel.migault@ericsson.com>; secdir@ietf.org <secdir@ietf.org>
Cc: draft-ietf-extra-imap4rev2.all@ietf.org <draft-ietf-extra-imap4rev2.all@ietf.org>; extra@ietf.org <extra@ietf.org>; last-call@ietf.org <last-call@ietf.org>
Subject: Re: Secdir last call review of draft-ietf-extra-imap4rev2-2= 4
 
Hi Daniel,

Thank you for your review. My replies below. I removed some of your
comments that I need to think a bit more and will reply to them separately.=

On 19/01/2021 14:52, Daniel Migault via Datatracker wrote:
> Reviewer: Daniel Migault
> Review result: Has Nits
>
 [snip]
>
> [ ... ]
>
>     $Phishing  The $Phishing keyword can be u= sed by a delivery agent to
>        mark a message as highly lik= ely to be a phishing email.  An email
>        that's determined to be a ph= ishing email by the delivery agent
>        should also be considered a = junk email and have the appropriate
>        junk filtering applied, incl= uding setting the $Junk flag and
>        placing in the \Junk special= -use mailbox (see Section 7.2.3) if
>        available.
>        If both the $Phishing flag a= nd the $Junk flag are set, the user
>        agent should display an addi= tional warning message to the user.
>        User agents should not use t= he term "phishing" in their warning
>        message as most users do not= understand this term.  Phrasing of
>        the form "this message = may be trying to steal your personal
>        information" is recomme= nded.  Additionally the user agent may
>        display a warning when click= ing on any hyperlinks within the
>        message.
>
> <mglt>
> I tend to believe that phishing is now
> (unfortunately) known by most users.
> I have the impression that UI is always a
> difficult problem, and I am wondering if such
> recommendations are still valid or if that is
> a legacy statement. I do not have strong
> feeling about what to do, so I leave it to
> you, but is interested in your opinion.
This text matches the original registration of the $Phishing keyword. I have seen some modern email clients still following this advice, so I
think it is useful. Which part of it do you find outdated?

<mglt>

Just to be clea= r that was just a comment. In the following sentence,  
"""
User agents should not use th= e term "phishing" in their warning
message as most users do not understand this term. =  
"""
I was questioning = "as most users do not understand this term" and tend to believe that most users have heard what phishing means. So I a= m wondering if the user the message is being shown does not translate to it= self: "Oh yeah they mean phishing".  Again just some random = thoughts from my part.
Sorry, I was staring at this text so much that I stopped n= oticing it. Now that you pointed this out I think removing this sentence ma= kes sense.

</mglt>
 [snip]
>
> The section mentions that repeated attempts
> for a password associated is detected,
> somehow prevented. It may also worth
> mentioning that with a large number of login
> (known or guessed),
> an attacker may try to guess a login
> associated to a small number of commonly
> known weak passwords ( password
> spraying). I believe it might worth being
> mentioned, that correlating failed attempts
> worth also being mentioned.
Fair enough. Can you suggest some text?

<mglt>
Maybe something around these lines:
An IMAP server SHOULD report any authentication = failure and analyze the attempt with regard to a password brute force attac= k as well as a password spraying attack. Accounts that matching password sp= raying attacks MUST be blocked and request to change their passwords and only password with significant stren= gth SHOULD be accepted.
I edited this slightly. Thank you for the suggestion.
</mglt> 

> Maybe that goes a bit too far in the purpos= e
> of recommendations, but it might may sense to
> recommend strong random passwords used in
> conjunction of passwords wallets or the use
> of mutually authenticate TLS.
>
> </mglt>
>
>
> <mglt>
> One question I would have - and with very
> little opinion on it - is how vulnerable IMAP
> parsing is to injection. I usually see the
> use of JSON as a big advantage toward
> this, but I would be happy to known
> your opinion on it.
Can you give me an example, as I am not sure what do you mean by
injection in this case?

<mglt>
I do not have specific example in mind. My quest= ion was if there are known ways to inject some commands in a specific field= or if some parsers checks have been relaxed to enable interoperability.
I can't think of any. IMAP is either using octet-counted l= iterals or strict syntax (LIST-like). Syntax is quite regular and easier th= an XML (IMHO).

</mglt>

> I also have the impression that injections
> can be performed via the web interface, so a
> web front end should be carefully considered
> and IMAP server may not believe they are
> always immune behind a web front end and
> still require to follow the best practises.
>
> </mglt>

Best Regards,

Alexey

--_000_DM6PR15MB2379B58281E066E4523B1404E3A20DM6PR15MB2379namp_-- From nobody Thu Jan 21 09:48: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 2FC493A1371 for ; Thu, 21 Jan 2021 09:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 dtnvY6Hds7zZ for ; Thu, 21 Jan 2021 09:48:42 -0800 (PST) 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 48E733A137A for ; Thu, 21 Jan 2021 09:48:41 -0800 (PST) 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 10LHmZgq019677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Jan 2021 12:48:39 -0500 Date: Thu, 21 Jan 2021 09:48:35 -0800 From: Benjamin Kaduk To: "Rabadan, Jorge (Nokia - US/Mountain View)" Cc: Russ Housley , "secdir@ietf.org" Message-ID: <20210121174835.GC21@kduck.mit.edu> References: <160744443645.5849.4437345323739394566@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-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: Thu, 21 Jan 2021 17:48:44 -0000 Russ, thanks for the review -- well spotted! Jorge, thanks for the updates. I entered a No Objection ballot. -Ben On Mon, Jan 04, 2021 at 03:52:31PM +0000, Rabadan, Jorge (Nokia - US/Mountain View) wrote: > Hi Russ, > > The references to SEND are not needed. It was just an example. > Since it is not appropriate, I removed the references to RFC 3971. > > I also addressed your other editorial comments in the other email. > Thank you very much! > Jorge > > > From: Russ Housley via Datatracker > Date: Tuesday, December 8, 2020 at 11:20 AM > To: secdir@ietf.org > Cc: bess@ietf.org , draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org , last-call@ietf.org > Subject: Secdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-09 > Reviewer: Russ Housley > Review result: Has Issues > > I 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 authors, document editors, and WG chairs should > treat these comments just like any other IETF Last Call comments. > > Document: draft-ietf-bess-evpn-proxy-arp-nd-09 > Reviewer: Russ Housley > Review Date: 2020-12-08 > IETF LC End Date: 2020-12-15 > IESG Telechat date: unknown > > Summary: Has Issues > > > Major Concerns: I worry about the reference to SEND (RFC 3971). The > SEND protocol only supports digital signatures using RSA with SHA-1. > While this still might be adequate for the time scales associated > with ND, the 80-bit security offered by SHA-1 is not considered > adequate for digital signatures in general. Is the reference to > SEND really needed in this document? > > > Minor Concerns: None > > > Nits: The Gen-ART review by me includes some editorial suggestions. > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Fri Jan 22 11:27:11 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 0CE1A3A1421; Fri, 22 Jan 2021 10:34:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1611340462; bh=Ujx1eIDFYKU2yl5rYdxeo+LkvZ9UGUmt7rlyp/Oyg0U=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=qwfvOliLSbfOzh9u5g/Ft8w4fnw6NwW2kcKBeYzdNpGgKd1SrLvX/WQBbJPoKR2j4 yG0MwUyp+2ITjYFrOBhJeVbD+loDaylrXPLhXXqYTyXugKscFxLK198sadAJmA3vwh hYd4YCySCiLRB770VvsmuMurfLbCXcw9ZzE5f7rg= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Jan 22 10:34:16 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 676183A13FE; Fri, 22 Jan 2021 10:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1611340454; bh=Ujx1eIDFYKU2yl5rYdxeo+LkvZ9UGUmt7rlyp/Oyg0U=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=WQi+c1HshCrhbl4iafj46iLFvusjyltHN+GbFdBRxmGwEwY0wMuqu/mh6XYOFiTdB UbR+HvTA2zAI99XwTc4BLh/xN11YOD840o6YF7tgTiM+xgwiqZuU9akDM66OcbK3kp i26Skvq2A6idSr35aZsmTZXeJbU+8fu+wqZn4DpM= 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 1C1633A13E6 for ; Fri, 22 Jan 2021 10:34:07 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <161134044709.32352.4950018425192632154@ietfa.amsl.com> Date: Fri, 22 Jan 2021 10:34:07 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 22 Jan 2021 11:27:10 -0800 Subject: [secdir] [new-work] WG Review: WebRTC Ingest Signaling over HTTPS (wish) 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, 22 Jan 2021 18:34:29 -0000 A new IETF WG has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2021-02-01. WebRTC Ingest Signaling over HTTPS (wish) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Alex Gouaillard Sean Turner Assigned Area Director: Murray Kucherawy Applications and Real-Time Area Directors: Barry Leiba Murray Kucherawy Mailing list: Address: wish@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/wish Archive: https://mailarchive.ietf.org/arch/browse/wish/ Group page: https://datatracker.ietf.org/group/wish/ Charter: https://datatracker.ietf.org/doc/charter-ietf-wish/ The WISH working group is chartered to specify a simple, extensible, HTTPS-based signaling protocol to establish one-way WebRTC-based audiovisual sessions between broadcasting tools and real-time media broadcast networks. Background: WebRTC defines a set of wire protocols for real-time media transmission, as well as a profile of the Signaling Description Protocol (SDP) for setting up and controlling the associated media streams. Because of its typical use cases, and to increase overall flexibility, WebRTC did not specify a wire protocol for exchanging SDP messages, leaving the creation of such protocols up to the applications that use WebRTC. This works well when WebRTC clients are vertically integrated with the servers they communicate with, as it allows for rapid iteration of new features. At the same time, the use of WebRTC as a mechanism for large-scale media broadcast is gaining popularity, with companies such as Millicast, Caffeine, Janus/Meetecho, Evercast, Wowza, Liveswitch, Antmedia, and Strivecast deploying WebRTC-based media distribution networks. Unlike more vertically integrated uses of WebRTC, these networks would benefit immensely from being able to re-use the several broadcasting tools that have been developed over time (such as Wirecast, OBS, Stretchcast, NewBlue Stream, XSplit, FFSplit, Lightstream, vMix, and a host of other applications). To date, these media distribution networks have employed their own proprietary signaling protocols to establish the connection between broadcasting tools and the network, generally requiring either bespoke software or customized modifications to existing broadcasting tools. With the large number of available tools and the growing number of real-time media distribution networks, this ad-hoc approach to creating custom protocols for establishing sessions clearly does not scale. The real-time broadcasting ecosystem would benefit immensely from a single, shared protocol to meet this goal. Deliverables: The product of this working group will be a specification for a simple, extensible, HTTPS-based signaling protocol to establish one-way WebRTC-based audiovisual sessions between broadcasting tools and real-time media broadcast networks. This working group will use existing HTTPS, WebRTC, and SDP mechanisms to the extent possible. While no extensions to those core protocols is expected, the working group may consider such extensions if they are necessary to meet the requirements of broadcasting tools and networks. Any such work will be coordinated with the HTTPBIS and/or MMUSIC working groups, as appropriate. Additionally, this working group will coordinate with HTTPBIS and HTTPAPI to assure that the HTTP protocol is being used according to current best practice. While there may be other problems that the proposed mechanism may solve or nearly solve, such as video display clients connecting to the egress of a media delivery network, adding explicit protocol support for those use cases is not in scope for the WISH working group. Milestones: Dec 2021 - Submit web ingest signaling protocol to IESG for publication _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Jan 22 11:27:15 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 8DF063A149E; Fri, 22 Jan 2021 11:19:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1611343173; bh=01inHMVvT/FKnHMuxLbadig55E1oapr4RSeyn+DJ7Lc=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=l6H/S5+RhyZObpPs5qwMw7Sc3VoEYW5kydmtbr5n3NlFxAAjpex9Px5BOXrwIWmAR CFkXARnVlLunJYFcVBO1A90h0i+vrZHhZ1Bc5IZce9RwTreYPUS03O5tN2chS/wlwM v2X+uHPsMKW20baIP4kx2OeHCo/K1a+h9dlD1nBM= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Jan 22 11:19:27 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E741D3A14AF; Fri, 22 Jan 2021 11:19:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1611343161; bh=01inHMVvT/FKnHMuxLbadig55E1oapr4RSeyn+DJ7Lc=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=sw7OnK12lVQdHconyxxTUgfmsojgyy47lmr5AzPtzme9/oOuMK5hqlXRzt/65OWc8 MdHog8NPtc05fR6xjmVI2dVgbUaNWmvTlJ4rDaRlE8s6pj9w0mTNZTRKQ13OAEABCJ qR9/vOZ0uNleoK38ydb5TVeNRkPAzMXU1TKrb5hw= 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 6273A3A1464 for ; Fri, 22 Jan 2021 11:19:14 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <161134315438.13237.16167447594241364067@ietfa.amsl.com> Date: Fri, 22 Jan 2021 11:19:14 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 22 Jan 2021 11:27:10 -0800 Subject: [secdir] [new-work] WG Review: IOT Operations (iotops) 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, 22 Jan 2021 19:19:39 -0000 A new IETF WG has been proposed in the Operations and Management Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2021-02-01. IOT Operations (iotops) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Henk Birkholz Alexey Melnikov Assigned Area Director: Warren Kumari Operations and Management Area Directors: Warren Kumari Robert Wilton Mailing list: Address: iotops@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/iotops Archive: https://mailarchive.ietf.org/arch/browse/iotops/ Group page: https://datatracker.ietf.org/group/iotops/ Charter: https://datatracker.ietf.org/doc/charter-ietf-iotops/ The IOTOPS Working Group is chartered for the discussion of operational issues related to Internet of Things (IoT) devices, in particular related to device onboarding and lifecycle management. IoT has a rather nebulous definition with different meanings for different people. For the purposes of this WG, its focus is on devices that - are networked, either to the Internet or within limited administrative domains - have a very limited end user interface or no end-user interface at all - are deployed in sufficiently large numbers that they cannot easily be managed or maintained manually The IETF works on a number of technologies related to IoT. This includes, but is not limited to work done in ACE, ANIMA, CBOR, CORE, DRIP, LAKE, LPWAN, LWIG, ROLL, SUIT, TEEP, 6LO, 6TISCH, and other working groups. IOTOPS is intended to be a discussion venue where people can discuss how various IoT-related technologies fit together. IOTOPS provides a venue for IoT experts and other interested parties to engage in discussions of operational IoT requirements, as well as proposals for new uses of IP technology related to IoT device and network operations. Revision, updates, and extensions to work from existing WGs will be done in those WGs. Where new protocols may be needed, IOTOPS will help identify candidate venues within IETF for their development. IOTOPS WG charter is restricted to: 1) Taking input and discussing issues related to the operational management of IoT devices. This includes (but is not limited to): - factory provisioning of devices - onboarding of devices - access control of devices to network resources - administrative control of devices - software/firmware upgrades - isolation/quarantine of devices - remediation of broken devices - end of life management of devices 2) Discussing issues related to IoT operational security. 3) Publishing operational practice. 4) Documenting requirements. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Sun Jan 24 04:51: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 492AD3A089C; Sun, 24 Jan 2021 04:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 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.262, 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 YfPsowWVfAMZ; Sun, 24 Jan 2021 04:50:57 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id D60403A0888; Sun, 24 Jan 2021 04:50:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1611492655; d=isode.com; s=june2016; i=@isode.com; bh=ienI35VtEv8fFBs7TNGn3YZFAHRFCz3wcCRGaGJMmHY=; 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=fKy1vyUNOFSE9ZliMps4hkpaf4BdaU0Et90l2WXhRsvi5cd3bf2Bm7UAwwI813K7TmMru8 Qp1/Tfvo7JBd7sxPCmdnQjD9jXbLvplwUFenTbX6Co396ws8y04Y73vlEQKfHZsSeWXHTW LW0EhLMsvZjg4wZRTBFmXIeElaM9N+Y=; Received: from [192.168.0.5] (4e697ac1.skybroadband.com [78.105.122.193]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 24 Jan 2021 12:50:55 +0000 From: Alexey Melnikov To: Daniel Migault , secdir@ietf.org Cc: draft-ietf-extra-imap4rev2.all@ietf.org, extra@ietf.org, last-call@ietf.org References: <161106792581.26552.4563982290675643872@ietfa.amsl.com> Message-ID: <180cc9c6-f438-f05d-741c-f250024738db@isode.com> Date: Sun, 24 Jan 2021 12:50:56 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 In-Reply-To: <161106792581.26552.4563982290675643872@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-extra-imap4rev2-24 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 Jan 2021 12:50:58 -0000 Hi Daniel, On 19/01/2021 14:52, Daniel Migault via Datatracker wrote: =C2=A0[snip] > During the TLS negotiation [TLS-1.3][TLS-1.2], the client MUST check > its understanding of the server hostname against the server's > identity as presented in the server Certificate message, in order to > prevent man-in-the-middle attacks. This procedure is described in > [RFC7817]. > > > I think it would be good to mention DANE as > well as certificate checks. This came up before, but at this point there is no document describing=20 how to use DANE with email clients (an alternative/update to RFC 7817)=20 and I am not aware of any client implementations that use DANE=20 experimentally for this. Best Regards, Alexey From nobody Sun Jan 24 11:32:32 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 CE4E23A03F1 for ; Sun, 24 Jan 2021 11:32:30 -0800 (PST) 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.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <161151675082.11679.9179661570849946671@ietfa.amsl.com> Date: Sun, 24 Jan 2021 11:32:30 -0800 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: Sun, 24 Jan 2021 19:32:31 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2021-02-04 Reviewer LC end Draft Daniel Migault R2021-01-20 draft-ietf-extra-imap4rev2 Last calls: Reviewer LC end Draft Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping Daniel Gillmor 2020-09-30 draft-ietf-ccamp-layer0-types Phillip Hallam-Baker 2020-12-03 draft-ietf-tls-ticketrequests Phillip Hallam-Baker 2020-09-30 draft-ietf-lwig-tcp-constrained-node-networks Steve Hanna 2020-09-30 draft-ietf-ccamp-wson-yang Dan Harkins None draft-ietf-rtgwg-policy-model Leif Johansson None draft-ietf-netconf-crypto-types Leif Johansson 2020-10-02 draft-ietf-lpwan-schc-over-lorawan Aanchal Malhotra 2021-01-26 draft-ietf-mpls-lsp-ping-registries-update Catherine Meadows 2021-01-25 draft-ietf-dime-group-signaling Daniel Migault R2021-01-20 draft-ietf-extra-imap4rev2 Adam Montville 2021-02-12 draft-crocker-inreply-react Kathleen Moriarty 2021-02-05 draft-ietf-detnet-ip-over-tsn Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Yoav Nir 2021-02-05 draft-ietf-detnet-mpls-over-tsn Magnus Nystrom 2021-02-05 draft-ietf-detnet-tsn-vpn-over-mpls Francesca Palombini None draft-ietf-opsawg-finding-geofeeds Tirumaleswar Reddy.K 2020-11-16 draft-ietf-quic-transport Rich Salz R2020-08-14 draft-ietf-suit-architecture Brian Weis R2020-12-02 draft-ietf-core-dev-urn Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Christopher Wood R2021-01-18 draft-ietf-dtn-tcpclv4 Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model Liang Xia 2020-11-30 draft-ietf-spring-sr-yang Early review requests: Reviewer Due Draft Alexey Melnikov 2021-02-01 draft-ietf-idr-bgp-open-policy Dacheng Zhang 2020-12-07 draft-ietf-idr-eag-distribution Next in the reviewer rotation: Tim Polk Tirumaleswar Reddy.K Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore From nobody Tue Jan 26 08:56:27 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 BEE753A0ADA; Tue, 26 Jan 2021 08:56:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Catherine Meadows via Datatracker To: Cc: dime@ietf.org, draft-ietf-dime-group-signaling.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161168017872.21141.3982625411769831365@ietfa.amsl.com> Reply-To: Catherine Meadows Date: Tue, 26 Jan 2021 08:56:18 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dime-group-signaling-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: Tue, 26 Jan 2021 16:56:19 -0000 Reviewer: Catherine Meadows Review result: Ready 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 draft presents the commands a Diameter node could use to communicate with multiple sessions of the Diameter simultaneously. The Security Considerations section mentions two issues. One is that the use of bulk commands introduces increases the ease of implementing certain types of DoS attacks because a single command, e.g. to terminate a session, could affect multiple sessions instead of just one. The other is that current security mechanisms employed by Diameter do not enforce end-to-end security, and so make it difficult to trust information received from non-adjacent nodes. Work is ongoing on end-to-end security for Diameter, so it is premature to address end-to-end security in this document, which instead relies on available security mechanisms. I think this is a reasonable summary of the security considerations. Since end-to-end security for Diameter is a work in progress, it would be premature to attempt to address it in this document. I consider this document Ready. From nobody Wed Jan 27 15:33:06 2021 Return-Path: <01000177463160fb-8dd3e153-dd68-4eba-b370-49aed4d02a87-000000@amazonses.watsen.net> 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 945863A0D60; Wed, 27 Jan 2021 15:33:00 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 rUzV39IHvAwi; Wed, 27 Jan 2021 15:32:59 -0800 (PST) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832B23A0D64; Wed, 27 Jan 2021 15:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1611790377; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=40yNJK1r5WqPRwwAwXrbbDBJ0hRRjym+UlJzylnCe3w=; b=cGTHHuq5tiaj7NxqtHwBAWzEJOX+yroHhTpOE4160TcvnGXyCRr/iDFlV9l1dwZp EfP19lo6weVZWLehNrIFlsTc2BOLLHjclVqZRcThl1pHFQLZyO1bKAqOTwfgpXsG4fl E3CH5SJbnjxybGyD2cRLARa+NSq1hKoGKoZrtg28= From: Kent Watsen Message-ID: <01000177463160fb-8dd3e153-dd68-4eba-b370-49aed4d02a87-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9B6F05B5-F72C-414B-8564-8C142E4E68B1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 27 Jan 2021 23:32:57 +0000 In-Reply-To: <01000176b576c690-7bb22a7a-1fb1-485f-bb06-51f3c08d0fdc-000000@email.amazonses.com> Cc: draft-ietf-netconf-trust-anchors.all@ietf.org, "netconf@ietf.org" , Yoav Nir , secdir@ietf.org To: Benjamin Kaduk References: <160107496501.14047.597283542214697710@ietfa.amsl.com> <01000174e90a9186-0a4edb66-4120-44b7-a79f-7b9935f6d48f-000000@email.amazonses.com> <010001768d05bf5b-eb6d3807-2d23-45c8-a905-dfdaf9fe5bb3-000000@email.amazonses.com> <20201230011701.GO89068@kduck.mit.edu> <01000176b576c690-7bb22a7a-1fb1-485f-bb06-51f3c08d0fdc-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.01.27-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [secdir] [netconf] [Last-Call] Secdir last call review of draft-ietf-netconf-trust-anchors-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: Wed, 27 Jan 2021 23:33:01 -0000 --Apple-Mail=_9B6F05B5-F72C-414B-8564-8C142E4E68B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ben/Yoav, I forgot to mention before that the draft supports two ways to store = symmetric keys and two ways to store private keys. In general, the two = ways are =E2=80=9Craw=E2=80=9D and =E2=80=9CCMS=E2=80=9D. The good = news, when using CMS, the structure internally includes a field for the = key's usage. So, perhaps the resolution is for the Security = Considerations section to say =E2=80=9CCMS keys are RECOMMENDED=E2=80=A6=E2= =80=9D? Details: 1) for asymmetric keys - the =E2=80=9Craw=E2=80=9D value is an RSAPrivateKey, = ECPrivateKey, etc. - the =E2=80=9Ccms=E2=80=9D value is an OneAsymmetricKey (from RFC = 5958) - the OneAsymmetricKey structure includes a field called = =E2=80=9Cattributes=E2=80=9D - the =E2=80=9Cattributes=E2=80=9D field is of type = OneAsymmetricKeyAttributes - attribute values van come from, e.g., RFC 7906 2) for symmetric keys - the =E2=80=9Craw=E2=80=9D value is an octet string - the =E2=80=9Ccms=E2=80=9D value is an OneSymmetricKey (from RFC = 6031) - the OneSymmetricKey structure includes a field called = =E2=80=9CsKeyAttrs=E2=80=9D - the sKeyAttrs field is of type Attributes - SKeyAttributes include "at-pskc-keyUsage" Kent > On Dec 30, 2020, at 4:03 PM, Kent Watsen wrote: >=20 > Hi Ben, >=20 >> This doesn't really fill me with joy. In short, constraints are = going to >> have to be applied at *some* level, even if it's not this one, or the >> system as a whole is likely to have some very surprising security >> properties. I recognize that coming up with a new language to = describe >> this sort of constraints is neither fun nor easy (and trying to = repurpose >> an existing language, such as that used by X.509, is not without = issues >> either), but I'd hope we could come up with something to say about = how to >> effectively use constraints on raw public keys. >=20 > You say constraints have to be applied at some level, but is this true = when TLS uses a raw key? Likewise for SSH keys (e.g., ~/.ssh/id_rsa)? >=20 > I=E2=80=99m extremely hesitant to make this change. Already this work = (9 drafts in total) has been in progress for more than 5 years. Will = you object during the IETF Last Call if it=E2=80=99s not added? >=20 > One thing not mentioned before, is that, while the keys are = unconstrained in the three base drafts (crypto-types, keystore, and = truststore), the =E2=80=9Ctis-client-server=E2=80=9D and = =E2=80=9Cssh-client-server=E2=80=9D drafts refine the base YANG models = to assert that the raw public key must be a SubjectPublicInfo structure = or an SSH public key, respectively. In fairness, this only constrains = the format of the data, not how the keys are used. That said, this = approach works with OpenSSH and OpenSSL keys, apparently indicating that = specifying the raw key=E2=80=99s use isn=E2=80=99t always necessary... >=20 >=20 >>=20 >> Thanks, >>=20 >> Ben >=20 >=20 > Kent >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_9B6F05B5-F72C-414B-8564-8C142E4E68B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ben/Yoav,

I forgot = to mention before that the draft supports two ways to store symmetric = keys and two ways to store private keys.  In general, the two ways = are =E2=80=9Craw=E2=80=9D and =E2=80=9CCMS=E2=80=9D.  The good = news, when using CMS, the structure internally includes a field for the = key's usage.  So, perhaps the resolution is for the Security = Considerations section to say =E2=80=9CCMS keys are = RECOMMENDED=E2=80=A6=E2=80=9D?

Details:

1) = for asymmetric keys
      - the =E2=80=9Craw= =E2=80=9D value is an RSAPrivateKey, ECPrivateKey, etc.
  =     - the =E2=80=9Ccms=E2=80=9D value is an OneAsymmetricKey = (from RFC 5958)
      - the OneAsymmetricKey structure includes a field = called =E2=80=9Cattributes=E2=80=9D
      - = the =E2=80=9Cattributes=E2=80=9D field is of = type OneAsymmetricKeyAttributes
    =   - attribute values van come from, e.g., RFC 7906

2) for symmetric keys
  =     - the =E2=80=9Craw=E2=80=9D value is an octet = string
      - the =E2=80=9Ccms=E2=80=9D value = is an OneSymmetricKey (from RFC 6031)
      - = the OneSymmetricKey structure includes a field = called =E2=80=9CsKeyAttrs=E2=80=9D
      - the sKeyAttrs field is of = type Attributes
      - SKeyAttributes include = "at-pskc-keyUsage"

Kent



On Dec 30, 2020, at 4:03 PM, Kent Watsen = <kent+ietf@watsen.net> wrote:

Hi Ben,

This doesn't = really fill me with joy.  In short, constraints are going to
have to be applied at *some* level, even if it's not this = one, or the
system as a whole is likely to have some very = surprising security
properties.  I recognize that = coming up with a new language to describe
this sort of = constraints is neither fun nor easy (and trying to repurpose
an existing language, such as that used by X.509, is not = without issues
either), but I'd hope we could come up with = something to say about how to
effectively use constraints = on raw public keys.

You say constraints have = to be applied at some level, but is this true when TLS uses a raw key? =  Likewise for SSH keys (e.g., ~/.ssh/id_rsa)?

I=E2=80=99m extremely = hesitant to make this change.  Already this work (9 drafts in = total) has been in progress for more than 5 years.  Will you object = during the IETF Last Call if it=E2=80=99s not added?

One thing not = mentioned before, is that, while the keys are unconstrained in the three = base drafts (crypto-types, keystore, and truststore), the = =E2=80=9Ctis-client-server=E2=80=9D and =E2=80=9Cssh-client-server=E2=80=9D= drafts refine the base YANG models to assert that the raw public key = must be a SubjectPublicInfo structure or an SSH public key, = respectively.  In fairness, this only constrains the format of the = data, not how the keys are used.   That said, this approach works = with OpenSSH and OpenSSL keys, apparently indicating that specifying the = raw key=E2=80=99s use isn=E2=80=99t always necessary...



Thanks,

Ben


Kent


_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

= --Apple-Mail=_9B6F05B5-F72C-414B-8564-8C142E4E68B1-- From nobody Thu Jan 28 06:04:53 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 E8C1E3A1514; Thu, 28 Jan 2021 06:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 ZXgVL48SiLws; Thu, 28 Jan 2021 06:04:44 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E08D3A1516; Thu, 28 Jan 2021 06:04:39 -0800 (PST) Received: from [IPv6:2800:810:464:2b9:18e2:60b8:efab:c3f2] (unknown [IPv6:2800:810:464:2b9:18e2:60b8:efab:c3f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 0730D283A13; Thu, 28 Jan 2021 14:04:35 +0000 (UTC) To: Christopher Wood , secdir@ietf.org Cc: draft-ietf-6man-rfc4941bis.all@ietf.org, Benjamin Kaduk References: <160998197921.18103.15481726186693031049@ietfa.amsl.com> From: Fernando Gont Message-ID: <532736e2-f235-2bb1-9e31-7f707b153b15@si6networks.com> Date: Thu, 28 Jan 2021 11:03:37 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <160998197921.18103.15481726186693031049@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-6man-rfc4941bis-12 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, 28 Jan 2021 14:04:52 -0000 Hi, Chris, I had responded to this one, but will respond again about the main points you raise. PLease find my comments in-line.... On 6/1/21 22:12, Christopher Wood via Datatracker wrote: [....] > > Section 2.1. > > One of the requirements for correlating seemingly unrelated > activities is the use (and reuse) of an identifier that is > recognizable over time within different contexts. IP addresses > provide one obvious example, but there are more. For example, > > What about MAC addresses? As I understand it, most systems are moving towards > MAC address randomization, though it's still probably worth mentioning. > Likewise, similar to cookies, one could also mention TLS (or transport) layer > identifiers, such as TLS session tickets. This is touched on somewhat in the > Security Considerations. This document notes that it tries to tackle only address-based correlation. As you correctly note, there are potentially multiple IDs, at lower and upper layers, that could be leveraged for activity correlation. But this documents tries to tackle only IPv6 address-based correlation. > Section 2.2. > > To make it difficult to make educated guesses as to whether two > different interface identifiers belong to the same host, the > algorithm for generating alternate identifiers must include input > that has an unpredictable component from the perspective of the > outside entities that are collecting information. > > It seems like this "must" be normative, and should probably reference the > RFC4086 [https://tools.ietf.org/html/rfc4086]. This section, as well as the design goals in Section 3.1, are not normative but informative. -- that's why they don't delve into much detail or have RFC2119 language. > > Section 3.1. > > 3. New temporary addresses are generated over time to replace > temporary addresses that expire. > > I assume expiration here means that the address is deprecated, right? If so, > that might be worth clarifying. > > 4. > > The lifetime of temporary addresses must be statistically different > for different addresses, such that it is hard to predict or infer > when a new temporary address is generated, or correlate a newly- > generated address with an existing one. > > This "must" is not normative, right? I assume not, since the previous guideline > in this item ("the lifetime of an address should be further reduced when > privacy-meaningful events ... takes place") does not require all temporary > addresses to cease working. It might be better to drop the "or correlate a > newly-generated address with an existing one" bit. How about rephrase as: "hard to predict or infer when a temporary address are regenerated"? > Moreover, what does "statistically different" mean, precisely? A and B having a high probability of being different when both of them are selected from a PRNG > It might be more > accurate to talk about this property from the perspective of the adversary. For > example, I think this is trying to say that given two different temporary > addresses, an adversary must have negligible probability in determining whether > or not they correspond to the same or different sources. (That would match > better with the Randomized Interface Identifier algorithms given in Section > 3.3.) The property that you describe depends on the specific deployment. e.g., If I0m an attacker, and you are the only host on a /64 there's "nothing" you can do for me not to be able to tell that it's just you changing the address of your own box. > Section 3.3. > > The algorithm specified in > Section 3.3.1 benefits from a Pseudo-Random Number Generator (PRNG) > available on the system. > > What does "benefits" mean here? If we're specifying an algorithm to generate > random values, shouldn't a PRNG be *required*? Implementation-wise, when you work on the code, must likely you have some form of random() available (I personally don't know of a system that doesn't). Whereas for the other algorithm, it will probably require more work on your side. (e.g., consider if you want to use siphash for the PRF). > Section 3.3.2. > > This section assumes a "hash-based" algorithm, but is specified using a PRF. Actually, the title is misleading. The algorithm requires a PRF, but notes that one possible implementation is with a hash function. We could provide an actual PRF as an example (e.g. BLAKE3) if you think that's important. This wouldn't/shouldn't be a big deal to do, since specific PRFs are not required by the algorithm (i.e., there are no normative references or specification of any specific PRF). > Later, in the text, it reads: > > F() could be the > result of applying a cryptographic hash over an encoded > version of the function parameters. > > But a cryptographic hash is not a PRF. If the hash function is meant to be > keyed, even that probably isn't sufficient. (Some constructions, like H(k || m) > for secret k and input m, are vulnerable to length extensions.) > > I think it's probably safest to recommend a particular construction, such as > HKDF with secret_key and output length equal to the number bytes needed for the > interface identifier. As noted in the document, we do talk about a "cryptographically robust construction". However, since the use of a keyed-hash function is mostly informational, I think that we could easily reference an HMAC instead. So far, in the context of numeric-ids, we were employing HMAC-SHA-256 ... which also happen to be the HMAC flavor of the hash function that we currently suggest in this document. Would HMAC-SHA-256 address this comment? > Moreover, requirements for secret_key are not really strict enough. There's > text about F(), e.g.,: > > F() MUST > also be difficult to reverse, such that it resists attempts to > obtain the secret_key > > And it is said that secret_key "SHOULD be of at least 128 bits," but what if > it's less? What if it only has a single byte of entropy? The rationale here essentially was that in such case, you're supposed to know what you're doing if you're going against the "SHOULD". Besides, in that cause you'd be able to compute the output of F(), and hence would not be complying with this earlier requirement: A pseudorandom function (PRF) that MUST NOT be computable from the outside (without knowledge of the secret key) > Section 3.4. > > Constants here are used before defined. Moving Section 3.8 to somewhere before > Section 3.4 might help. The oredering is borrowed from RFC4941. THe only way that I envision that the order could be altered (without the parameters section interrupting the natural read of the document) would be for Section 4 and section 3.8 to be subsections of the same parent Section. Not sure I'd do it at this stage, though. Thoughts? > What happens if the constants are chosen such that the rule (5) is not possible > to achieve? The math in Section 3.8 should prevent you from setting such values. > Section 3.6. > > The frequency at which temporary addresses change depends on how a > device is being used (e.g., how frequently it initiates new > communication) and the concerns of the end user. The most egregious > privacy concerns appear to involve addresses used for long periods of > time (weeks to months to years). The more frequently an address > changes, the less feasible collecting or coordinating information > keyed on interface identifiers becomes. Moreover, the cost of > collecting information and attempting to correlate it based on > interface identifiers will only be justified if enough addresses > contain non-changing identifiers to make it worthwhile. Thus, having > large numbers of clients change their address on a daily or weekly > basis is likely to be sufficient to alleviate most privacy concerns. > > I don't disagree with the text, but is there anything we can cite here? Why do > we think it's "sufficient," for example? I don't have a reference for this -- at the end of the day, this is quite subjective. The bottom-line here is that you don't want to expose your stable address (which has a potential lifetime of O(forever) ). O(day) seems to be more than a fair compromise. > Finally, when an interface connects to a new (different) link, > existing temporary addresses for the corresponding interface MUST be > eliminated, and new temporary addresses MUST be generated immediately > for use on the new link. > > If the addresses are eliminated, how does one run DAD and ensure that the same > (or similar) addresses are not used on the new link? If you move to a different link, you don't need your old addresses (even the prefix should have changed). So why would you mind? > > Section 3.7. > > Devices implementing this specification MUST provide a way for the > end user to explicitly enable or disable the use of temporary > addresses. > > Why is this a MUST, rather than a SHOULD? Since this is effectively describing > an API, I think this ought to be relaxed. This was borrowed from RFC4941. Now, there could be valid reasons for a user that wants to disable it: e.g., let's say I use ssh a lot, like long-lived sessions, and use an ssh client that doesn't know how to tell the OS to use stable addresses for the ssh sessions. In such case, my options are: * disable v6 on my host * disable use of temporary addresses (*this knob*) > Section 6. > > An implementation might want to keep track of which addresses are > being used by upper layers so as to be able to remove a deprecated > temporary address from internal data structures once no upper layer > protocols are using it (but not before). > > It seems an application might also want to consider other information linkable > to select addresses in the future. For example, TLS resumption may link clients > across two different temporary addresses. (This goes back to my comment on > Section 2.1 above.) Indeed. But this is out of the scope of RFC4941bis. rfc4941 simply provides temporary addresses. It doesn't have features like "create a new address on request" or the like -- that would be valuable, but subject for a different document. Thoughts? Thanks again for your comments! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 28 14:29:08 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 57A623A17AB for ; Thu, 28 Jan 2021 14:29:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <161187294578.10272.9079642323447205288@ietfa.amsl.com> Date: Thu, 28 Jan 2021 14:29:06 -0800 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: Thu, 28 Jan 2021 22:29:06 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2021-02-04 Reviewer LC end Draft Daniel Migault R2021-01-20 draft-ietf-extra-imap4rev2 Last calls: Reviewer LC end Draft Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping Daniel Gillmor 2020-09-30 draft-ietf-ccamp-layer0-types Phillip Hallam-Baker 2020-12-03 draft-ietf-tls-ticketrequests Phillip Hallam-Baker 2020-09-30 draft-ietf-lwig-tcp-constrained-node-networks Steve Hanna 2020-09-30 draft-ietf-ccamp-wson-yang Dan Harkins None draft-ietf-rtgwg-policy-model Leif Johansson None draft-ietf-netconf-crypto-types Leif Johansson 2020-10-02 draft-ietf-lpwan-schc-over-lorawan Aanchal Malhotra 2021-01-26 draft-ietf-mpls-lsp-ping-registries-update Daniel Migault R2021-01-20 draft-ietf-extra-imap4rev2 Adam Montville 2021-02-12 draft-crocker-inreply-react Kathleen Moriarty 2021-02-05 draft-ietf-detnet-ip-over-tsn Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Yoav Nir 2021-02-05 draft-ietf-detnet-mpls-over-tsn Magnus Nystrom 2021-02-05 draft-ietf-detnet-tsn-vpn-over-mpls Tim Polk None draft-ietf-opsawg-finding-geofeeds Tirumaleswar Reddy.K 2021-02-09 draft-ietf-regext-unhandled-namespaces Tirumaleswar Reddy.K 2020-11-16 draft-ietf-quic-transport Kyle Rose 2021-02-09 draft-ietf-stir-rph-emergency-services Joseph Salowey 2021-02-09 draft-ietf-oauth-access-token-jwt Rich Salz 2021-02-08 draft-ietf-regext-rfc7483bis Rich Salz R2020-08-14 draft-ietf-suit-architecture Stefan Santesson 2021-02-08 draft-ietf-regext-rfc7482bis Yaron Sheffer 2021-02-08 draft-ietf-pce-pcep-extension-for-pce-controller Brian Weis R2020-12-02 draft-ietf-core-dev-urn Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Christopher Wood R2021-01-18 draft-ietf-dtn-tcpclv4 Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model Liang Xia 2020-11-30 draft-ietf-spring-sr-yang Early review requests: Reviewer Due Draft Alexey Melnikov 2021-02-01 draft-ietf-idr-bgp-open-policy Dacheng Zhang 2020-12-07 draft-ietf-idr-eag-distribution Next in the reviewer rotation: Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks Takeshi Takahashi Tina Tsou Sean Turner Mališa Vučinić Carl Wallace Samuel Weiler From nobody Thu Jan 28 16:31:59 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 80B593A0B9F; Thu, 28 Jan 2021 16:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1611880062; bh=MqeAvk8v+rt0OTwnJXfinOTv8XK8kT9q/gg2BL0YfIw=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=qbYkVcXVHIFNtK2RYDvsoLaVM3y+dVuvUGO/N1ylQo2r5hVhj35MSR+VQnzw07hlR aoMmvVcqktIOUSvL4v+1/kTR7DlaW0PQfIaBGY/3c4tz2oO0Vedc5yAY2KzAx4nqUS 6hWxQuERs2+oJ2nhwwQpy+5OUqoS0fg8OjFlLzFA= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Jan 28 16:27:36 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFE93A0AD1; Thu, 28 Jan 2021 16:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1611880055; bh=MqeAvk8v+rt0OTwnJXfinOTv8XK8kT9q/gg2BL0YfIw=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=u+up/XyVQ14Or6YF7vtCeHl4m7nLBffllogC98XvZUhqkkXF2lSqoOJY3weL1HIWN +1gqh5nEHyWhThltzK3Gspav4O6Mk/k/W+hzA3HFujB/l24/UvZJmgq2FtQCOeG8vr No7nTuxitcyPzqLTRUY244KuOJYQxpQ1+yVkQAw0= 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 C32EE3A0839 for ; Thu, 28 Jan 2021 16:27:27 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <161188004778.19279.15281065918384392698@ietfa.amsl.com> Date: Thu, 28 Jan 2021 16:27:27 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 28 Jan 2021 16:31:57 -0800 Subject: [secdir] [new-work] WG Review: Authentication and Authorization for Constrained Environments (ace) 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, 29 Jan 2021 00:27:49 -0000 The Authentication and Authorization for Constrained Environments (ace) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2021-02-07. Authentication and Authorization for Constrained Environments (ace) ----------------------------------------------------------------------- Current status: Active WG Chairs: Daniel Migault Assigned Area Director: Benjamin Kaduk Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: ace@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ace Archive: https://mailarchive.ietf.org/arch/browse/ace/ Group page: https://datatracker.ietf.org/group/ace/ Charter: https://datatracker.ietf.org/doc/charter-ietf-ace/ The Authentication and Authorization for Constrained Environments (ace) WG has defined a standardized solution framework for authentication and authorization to enable authorized access to resources identified by a URI and hosted on a resource server in constrained environments. The access to the resource is mediated by an authorization server, which is not considered to be constrained. Profiles of this framework for application to security protocols commonly used in constrained environments, including CoAP+DTLS and CoAP+OSCORE, have also been standardized. The Working Group is charged with maintenance of the framework and existing profiles thereof, and may undertake work to specify profiles of the framework for additional secure communications protocols and for additional support services providing authorized access to crypto keys (that are not necessarily limited to constrained endpoints, though the focus remains on deployment in ecosystems with a substantial portion of constrained devices). In addition to the ongoing maintenance work, the Working Group will extend the framework (originally designed to protect the exchange between single client and single RS) as needed for applicability to group communications. The initial focus will be on using (D)TLS and (Group) OSCORE as the underlying communication security protocols. The Working Group will standardize procedures for requesting and distributing group keying material using the ACE framework as well as appropriated management interfaces. The Working Group will standardize a format for expressing authorization information for a given authenticated principal as received from an authorization manager. The Working Group will examine how to use Constrained Application Protocol (CoAP) as a transport medium for certificate enrollment protocols, such as EST and CMPv2, as well as a transport for authentication protocols such as EAP (in coordination with the EMU WG), and standardize as needed. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Jan 29 06:51: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 C9BB53A0EF3; Fri, 29 Jan 2021 06:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=heapingbits.net header.b=AbgbNTLp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hFT4XQs+ 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 Yebb7DthFBl4; Fri, 29 Jan 2021 06:51:21 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBADF3A0DE0; Fri, 29 Jan 2021 06:51:21 -0800 (PST) Received: from compute4.internal (unknown [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A1D365C1225; Fri, 29 Jan 2021 09:39:30 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute4.internal (MEProxy); Fri, 29 Jan 2021 09:39:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=bjpWwFXqc2OjHCTXJ4nqK4/9W2FQ kRtf3REcoIQTSFw=; b=AbgbNTLpg1zeV7XAS9NuBsqoC0HurxviY5hSgjm1/Vos OXWpaYA/YiAed4YPm5mv4Dp95A2ixo9pWZJf+npV0bkYyFx9x5jum6Jgmz5VdWjf jzPZZjRoluOhAufrgVG+lhYkW2E+RGDC82tLwaCWUvCdhnLJVa7luIP58jj6cWYM m4RC7qkSeCSPm1KTljipUG1QTFaNGn3B+6YazujAOHimnxzduHnFApv5pdBco8v6 kng7WAIarecWk94tcY2BZgxD8hQnf4vswwv2XmamrvFIyq0BxngzpPxFxVQ7GmiB YonvUbagIc8HAx66F0PHyrBhfAW1IDvAPMpkvoqCYA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=bjpWwF Xqc2OjHCTXJ4nqK4/9W2FQkRtf3REcoIQTSFw=; b=hFT4XQs+YKNCcsQxHd7/m/ R90ajBtIaTVqo1iB96qHF2RXxd0dR0PxVwemBvkXqcBgM9qyYhtWCkm0XFITpOyc gO8fAzzAYRuYaVTWL7MVtotTv55hdu3twAkZ4nQB2uhP6g0o8mGBBEXMWlUbbBry t32eTwhTkbZ35gZrkZdU83MHnVDB82ofhu3rZxoFWF8H0toyD0RuY5ohjqmkBQe5 uB9njqJmTkuckynp5wmXmzqxEXsh5vVNGIIJ2y87BWPXoMSBhR7rQv9aZEmMCSTC PPMkO3TmW5X2UyKdSwN31RgJOES1zA1A/KK+tJdp2xJVlmIr12qtUKgfwGAkS/5A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedvgdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfvehhrhhi shhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvghtqe enucggtffrrghtthgvrhhnpeduffeitddutdetgfegfeekgedvkeelvdeiiedtjeetteeu vdejveelleeltedtheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8993B1600B2; Fri, 29 Jan 2021 09:39:27 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-84-gfc141fe8b8-fm-20210125.001-gfc141fe8 Mime-Version: 1.0 Message-Id: <4005a168-d4b7-4324-bcd1-a721fe0d743f@www.fastmail.com> In-Reply-To: <532736e2-f235-2bb1-9e31-7f707b153b15@si6networks.com> References: <160998197921.18103.15481726186693031049@ietfa.amsl.com> <532736e2-f235-2bb1-9e31-7f707b153b15@si6networks.com> Date: Fri, 29 Jan 2021 06:39:07 -0800 From: "Christopher Wood" To: "Fernando Gont" , "secdir@ietf.org" Cc: draft-ietf-6man-rfc4941bis.all@ietf.org, "Benjamin Kaduk" Content-Type: text/plain Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-6man-rfc4941bis-12 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 Jan 2021 14:51:24 -0000 Hi Fernando, Apologies for the delay. Please see inline below. On Thu, Jan 28, 2021, at 6:03 AM, Fernando Gont wrote: > Hi, Chris, > > I had responded to this one, but will respond again about the main > points you raise. PLease find my comments in-line.... > > > On 6/1/21 22:12, Christopher Wood via Datatracker wrote: > [....] > > > > Section 2.1. > > > > One of the requirements for correlating seemingly unrelated > > activities is the use (and reuse) of an identifier that is > > recognizable over time within different contexts. IP addresses > > provide one obvious example, but there are more. For example, > > > > What about MAC addresses? As I understand it, most systems are moving towards > > MAC address randomization, though it's still probably worth mentioning. > > Likewise, similar to cookies, one could also mention TLS (or transport) layer > > identifiers, such as TLS session tickets. This is touched on somewhat in the > > Security Considerations. > > This document notes that it tries to tackle only address-based > correlation. As you correctly note, there are potentially multiple IDs, > at lower and upper layers, that could be leveraged for activity > correlation. But this documents tries to tackle only IPv6 address-based > correlation. Sure, sure, I was only suggesting that these other correlation vectors be noted somewhere. :-) > > > > Section 3.1. > > > > 3. New temporary addresses are generated over time to replace > > temporary addresses that expire. > > > > I assume expiration here means that the address is deprecated, right? If so, > > that might be worth clarifying. > > > > 4. > > > > The lifetime of temporary addresses must be statistically different > > for different addresses, such that it is hard to predict or infer > > when a new temporary address is generated, or correlate a newly- > > generated address with an existing one. > > > > This "must" is not normative, right? I assume not, since the previous guideline > > in this item ("the lifetime of an address should be further reduced when > > privacy-meaningful events ... takes place") does not require all temporary > > addresses to cease working. It might be better to drop the "or correlate a > > newly-generated address with an existing one" bit. > > How about rephrase as: "hard to predict or infer when a temporary > address are regenerated"? That's good! (Small nit: s/address are regenerated/address is regenerated) > > Moreover, what does "statistically different" mean, precisely? > > A and B having a high probability of being different when both of them > are selected from a PRNG Would it make sense to include that definition? > > It might be more > > accurate to talk about this property from the perspective of the adversary. For > > example, I think this is trying to say that given two different temporary > > addresses, an adversary must have negligible probability in determining whether > > or not they correspond to the same or different sources. (That would match > > better with the Randomized Interface Identifier algorithms given in Section > > 3.3.) > > The property that you describe depends on the specific deployment. e.g., > If I0m an attacker, and you are the only host on a /64 there's "nothing" > you can do for me not to be able to tell that it's just you changing the > address of your own box. Yep, I agree, and I think that's important. In such deployments, changing addresses offers no privacy, right? > > Section 3.3. > > > > The algorithm specified in > > Section 3.3.1 benefits from a Pseudo-Random Number Generator (PRNG) > > available on the system. > > > > What does "benefits" mean here? If we're specifying an algorithm to generate > > random values, shouldn't a PRNG be *required*? > > Implementation-wise, when you work on the code, must likely you have > some form of random() available (I personally don't know of a system > that doesn't). Whereas for the other algorithm, it will probably require > more work on your side. (e.g., consider if you want to use siphash for > the PRF). Yep, I follow. My point was rather that the text might be better if it said: "The algorithm specified in Section 3.3.1 requires a PRNG." Whether it comes from the system (random()) or not is irrelevant, I think. > > Section 3.3.2. > > > > This section assumes a "hash-based" algorithm, but is specified using a PRF. > > Actually, the title is misleading. The algorithm requires a PRF, but > notes that one possible implementation is with a hash function. > > We could provide an actual PRF as an example (e.g. BLAKE3) if you think > that's important. This wouldn't/shouldn't be a big deal to do, since > specific PRFs are not required by the algorithm (i.e., there are no > normative references or specification of any specific PRF). It might be useful to note possible PRFs. Your call. :-) > > Later, in the text, it reads: > > > > F() could be the > > result of applying a cryptographic hash over an encoded > > version of the function parameters. > > > > But a cryptographic hash is not a PRF. If the hash function is meant to be > > keyed, even that probably isn't sufficient. (Some constructions, like H(k || m) > > for secret k and input m, are vulnerable to length extensions.) > > > > I think it's probably safest to recommend a particular construction, such as > > HKDF with secret_key and output length equal to the number bytes needed for the > > interface identifier. > > As noted in the document, we do talk about a "cryptographically robust > construction". However, since the use of a keyed-hash function is mostly > informational, I think that we could easily reference an HMAC instead. Indeed! That would be better. > So far, in the context of numeric-ids, we were employing HMAC-SHA-256 > ... which also happen to be the HMAC flavor of the hash function that we > currently suggest in this document. Would HMAC-SHA-256 address this comment? Yep, it would, provided the secret key was not known to the attacker. > > Moreover, requirements for secret_key are not really strict enough. There's > > text about F(), e.g.,: > > > > F() MUST > > also be difficult to reverse, such that it resists attempts to > > obtain the secret_key > > > > And it is said that secret_key "SHOULD be of at least 128 bits," but what if > > it's less? What if it only has a single byte of entropy? > > The rationale here essentially was that in such case, you're supposed to > know what you're doing if you're going against the "SHOULD". Besides, in > that cause you'd be able to compute the output of F(), and hence would > not be complying with this earlier requirement: > > A pseudorandom function (PRF) that MUST NOT be computable from > the outside (without knowledge of the secret key) True, true. Thanks for clarifying. > > Section 3.4. > > > > Constants here are used before defined. Moving Section 3.8 to somewhere before > > Section 3.4 might help. > > The oredering is borrowed from RFC4941. THe only way that I envision > that the order could be altered (without the parameters section > interrupting the natural read of the document) would be for Section 4 > and section 3.8 to be subsections of the same parent Section. Not sure > I'd do it at this stage, though. > > Thoughts? Given how far along this document is, what you think is probably best! > > What happens if the constants are chosen such that the rule (5) is not possible > > to achieve? > > The math in Section 3.8 should prevent you from setting such values. I didn't check, so if that's the case, please disregard this comment. > > Section 3.6. > > > > The frequency at which temporary addresses change depends on how a > > device is being used (e.g., how frequently it initiates new > > communication) and the concerns of the end user. The most egregious > > privacy concerns appear to involve addresses used for long periods of > > time (weeks to months to years). The more frequently an address > > changes, the less feasible collecting or coordinating information > > keyed on interface identifiers becomes. Moreover, the cost of > > collecting information and attempting to correlate it based on > > interface identifiers will only be justified if enough addresses > > contain non-changing identifiers to make it worthwhile. Thus, having > > large numbers of clients change their address on a daily or weekly > > basis is likely to be sufficient to alleviate most privacy concerns. > > > > I don't disagree with the text, but is there anything we can cite here? Why do > > we think it's "sufficient," for example? > > I don't have a reference for this -- at the end of the day, this is > quite subjective. > > The bottom-line here is that you don't want to expose your stable > address (which has a potential lifetime of O(forever) ). O(day) seems to > be more than a fair compromise. Indeed. I don't have a citation either. I was just noting in case others did. > > Finally, when an interface connects to a new (different) link, > > existing temporary addresses for the corresponding interface MUST be > > eliminated, and new temporary addresses MUST be generated immediately > > for use on the new link. > > > > If the addresses are eliminated, how does one run DAD and ensure that the same > > (or similar) addresses are not used on the new link? > > If you move to a different link, you don't need your old addresses (even > the prefix should have changed). So why would you mind? Oh, hah, good point. Disregard. :-) > > > > Section 3.7. > > > > Devices implementing this specification MUST provide a way for the > > end user to explicitly enable or disable the use of temporary > > addresses. > > > > Why is this a MUST, rather than a SHOULD? Since this is effectively describing > > an API, I think this ought to be relaxed. > > This was borrowed from RFC4941. Now, there could be valid reasons for a > user that wants to disable it: > e.g., let's say I use ssh a lot, like long-lived sessions, and use an > ssh client that doesn't know how to tell the OS to use stable > addresses for the ssh sessions. > > In such case, my options are: > * disable v6 on my host > * disable use of temporary addresses (*this knob*) If there's precedent, I suppose it's fine to keep. It just read odd to me. > > Section 6. > > > > An implementation might want to keep track of which addresses are > > being used by upper layers so as to be able to remove a deprecated > > temporary address from internal data structures once no upper layer > > protocols are using it (but not before). > > > > It seems an application might also want to consider other information linkable > > to select addresses in the future. For example, TLS resumption may link clients > > across two different temporary addresses. (This goes back to my comment on > > Section 2.1 above.) > > Indeed. But this is out of the scope of RFC4941bis. rfc4941 simply > provides temporary addresses. It doesn't have features like "create a > new address on request" or the like -- that would be valuable, but > subject for a different document. > > Thoughts? Yep, that seems reasonable. Thanks for your thoughtful response, and work on this document! Best, Chris From nobody Fri Jan 29 14:06:25 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 0869C3A130E; Fri, 29 Jan 2021 14:06:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir via Datatracker To: Cc: detnet@ietf.org, draft-ietf-detnet-mpls-over-tsn.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161195798389.15160.12141368782949515798@ietfa.amsl.com> Reply-To: Yoav Nir Date: Fri, 29 Jan 2021 14:06:23 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-detnet-mpls-over-tsn-05 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 Jan 2021 22:06:24 -0000 Reviewer: Yoav Nir Review result: Ready 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 links to two external documents, one dedicated to security considerations for DetNet, the other for DetNet over MPLS, both documents are works in progress. This is a good use of security considerations by reference. For the specific issues regarding MPLS over TSN, the short section provides adequate details. From nobody Sun Jan 31 10:22:58 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 CD5C23A118F; Sun, 31 Jan 2021 10:22:56 -0800 (PST) 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 7_sSxjicPuqS; Sun, 31 Jan 2021 10:22:55 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 66E2E3A118E; Sun, 31 Jan 2021 10:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1612117371; d=isode.com; s=june2016; i=@isode.com; bh=hqbX3DiYhcTxMBXk2SaKMDwXULtCLaWkeAE7c3XTgsU=; 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=CzLNOjKCTON+MjFPEOXjbFCBXUVfk+U+Yoh6M/B0yGktyVTEae0zFsfwlUS+drjefJ9SqR jmTHjJZlgts3ieGbbrscQuWRv6N7IGQPOFIdjzPuDaxDBfQSxv6th1K9UPuP/mNpV7xXoz rEh4DNxc3beCi45ZxavE2rFL1LrL8To=; Received: from [192.168.0.5] (4e697ac1.skybroadband.com [78.105.122.193]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 31 Jan 2021 18:22:51 +0000 From: Alexey Melnikov To: secdir@ietf.org Cc: draft-ietf-idr-bgp-open-policy.all@ietf.org Message-ID: <26d2a9b5-09dc-0929-c393-f7f0e1be0a9b@isode.com> Date: Sun, 31 Jan 2021 18:22:55 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 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 early review of draft-ietf-idr-bgp-open-policy-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 Jan 2021 18:22:57 -0000 Reviewer: Alexey Melnikov Review result: Ready 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 proposes a way to both prevent and detect BGP route leaks, using a new BGP role capability and a new "Only to Customer" (OTC) BGP Path attribute. I found the document to be well written and easily understood by a reader like me who is not expert in BGP. The Security Considerations talks about OTC misconfiguration affecting prefix propagation, but that the new BGP role capability counteracts this. I tend to agree and I can't think of other security issues raised by this document. Best Regards, Alexey