From nobody Tue Feb 1 01:30:21 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D353A1EB4 for ; Tue, 1 Feb 2022 01:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.675 X-Spam-Level: X-Spam-Status: No, score=-7.675 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, 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_HI=-5, 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 sC8fxyqazaBP for ; Tue, 1 Feb 2022 01:30:14 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0603.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::603]) (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 CC3A33A1EB5 for ; Tue, 1 Feb 2022 01:30:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oKr4R/WzMP+G73dFi6J69aGMgpB5I5B8BDWnzJv9fF3ODscWp5Gd+pZat6k3wJ3sdqi1qEr6Z6G0Gta5ihMiJr3arxvKS26bPPXf9ajh4F4qXaISVk7Ka1nvU1XdqvdWy8Eo8mX9Bi2lvOsYUIkR+UEdoQFro62BMnJKhnAmlsI/vVmXwW//rogGPQRZYdxYu+O51OHlJ88LzqtiaxDBNpHrU9HJ/3wTr+/DpLyKBNJkblrQEkTJGmm0KSkcqzGCEMI6ZvcW7mSf7knLoBbMrTWmha1fWcXhDqhZuFAKOHgohFBnK8ZlBscwpevU1y0UelX9g3mrOg/CVUQP92sHYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XLcSRq+8vgREw5s4uOL7uRQoFhxsKL2E33gK0fhFANE=; b=Enx5DJ1SKQ1VP4wUvryMN8nGOiUf8i2GbaQhLBSUdfRzG/A2ByM8COX7fFr7DsiOQCencBdz2MKzhh6ZwFVnIuGVMOmM5yvFY8hAp4PlFU5tNKgWZyI2PAQAjeP6LafHeeDuHoto/cpwAIEpwPlXgKSIW/dLnXWiE84bcXlOWcLSFH1pLXmrVGaebCiFGGXAMqwvN/GcWSY+uk0uwllLfEGxwJQj0RYudnVfpEU7pbBk7jeKLk/xmI0Fq0hSH4L9yBYHRoybdxIdz3bi8PjDIUXxbOruTtLPsoQymnJrlxnKXMK7JnLZTzBm8XgBw6e2LESiIkqcJMrrJCQ4kjKpyQ== 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=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XLcSRq+8vgREw5s4uOL7uRQoFhxsKL2E33gK0fhFANE=; b=IO1yRowB62XG0rVSN0bXHJqa78g8uldA0dlSBu3b0wdoxxCWSzo+bKKHsAeVFOLCvvgndWSeoI4q3/vu2jI1dDRdC3s5gWKcWaFXkb8/3vwp1piY19YOfwzE/MkC8s7T8MZ3NT3I65SzJti6Q1nuplWfyB6cibJV56GFUkSt1Uc= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by DU0PR07MB8420.eurprd07.prod.outlook.com (2603:10a6:10:354::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.7; Tue, 1 Feb 2022 09:30:06 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b462:480e:b937:c62c]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b462:480e:b937:c62c%7]) with mapi id 15.20.4951.011; Tue, 1 Feb 2022 09:30:06 +0000 From: John Mattsson To: "core@ietf.org" Thread-Topic: New Version Notification for draft-mattsson-core-coap-attacks-02.txt Thread-Index: AQHYF0n1JcPl+afQf0+0QyaIhsj8LKx+azIS Date: Tue, 1 Feb 2022 09:30:06 +0000 Message-ID: References: <164370592991.14136.4943780498822971831@ietfa.amsl.com> In-Reply-To: <164370592991.14136.4943780498822971831@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 30b94900-2bc4-47ee-e50a-08d9e5656f17 x-ms-traffictypediagnostic: DU0PR07MB8420:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zdRC5n5wXOTA7MRx3gWXzOvdNQpeqTmJM7T3YZbm0t8TUijzIjGfOJPFvZqIP4g04CRtGTi5574wcXrJYOX+GxfO/dQPpaseLBr3IBDoHttLuO8opxZjQXaYyOcBMl/ax6WrWJfNJbimIjAD48I4FrvlKPwtfrEQ4SdEShOFNXtbePwl1W1Rof4/Lnoe8f47UVFt/IZS4TP21KDj+4TaC4XVkGYeDZ5rbrp9EbVoujSD0pOE53GFdidwdhbX2ZX9vAj+q4Y4UbLKdEByO8Es940KUkGUvrEMWQ7Flbt4tTMw9/Gyv+TabXIxoNAY3Trb9ea+UpnZ9tIE6X4t2DlPtuU4QkPXNM8CuLNrwenjJTLU3xfKTvj4m7+mmQY5FOClTMQsMWeqyLGKTuxWkgXkJ4CNdby8rISRCV/zl/VlnK5KJngsFaXqkOhRLCkQbd/UAq5QFuk35LdsN/9PdiyDKgD8mV/CwsLjN81x3xrCfeM2oAMSy58yMgCzT5tEZxkc4R/JY0uOBrvoxUjkI1DdPdlU8TkIJFK8F7FueoRAG2iVd8RdGKIGDzO7+Whjc+zS2OL+Ck0/qsYAghmVMX8p9Zs/+Vqkr/QArDOdheP9Hd8KcTV6hz0l8C9kWi8NfOXeEJAMVolTJ5ejYJAMylaBdGxA6wiWppB6kj4pc4eLAex7o/hCacgfAMJJSpjyvlNjfxaPOWi5Ya9ES9m/UfMY5cetdM3eVCQRoeLqqaS4w6o8eNTOtQkHtJMy7Yi6uKFo0PiNYL2xKz0/+iUIN5HSGqYfXhRqNdBNwaE7a7s5ru/KZDHEEmM5bz6RtyiXg7pOidXNrZ/ZFi5pm1bjXuMXtv8FoeL+VM7bh+wk62LjdOhe4+wu0vrvW8FSOcaRLzh0 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(66446008)(76116006)(6916009)(66946007)(91956017)(66556008)(33656002)(8936002)(316002)(55016003)(26005)(186003)(8676002)(83380400001)(66476007)(166002)(66574015)(508600001)(38070700005)(53546011)(6506007)(966005)(15650500001)(82960400001)(71200400001)(52536014)(86362001)(9686003)(38100700002)(44832011)(21615005)(2906002)(122000001)(64756008)(5660300002)(7696005)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?YhlJk+NvN4yU9bAz+rGfhit+RZa/qg0RRMdWzhrLPy9QJP5a8NWp6Wx0?= =?Windows-1252?Q?oOuPC1qFdoq31XK/Fp1+R7LBGVmgjmCpZIlFH0umOAUdt12rz6REd6ZM?= =?Windows-1252?Q?LIfjk3TLKNYxCi9lmuvPUzKa/CJ14MHbheFthFtPcfzC6KWM4Bu97v7b?= =?Windows-1252?Q?GMj7Bk6e0UWFLbs4+bIa+Sh3GlLkD4jaUYAO3ujfWXhAZkE5zzFqnl59?= =?Windows-1252?Q?Py1khnuOHnpB2VEeUFrlRtUC6qQB0gy46yu14ABwJxxoUS/+huIV7NT+?= =?Windows-1252?Q?RF8gJ/Qt6IGrDaEVLEuC/3i1Q4xkB77SsPt3xArCxlsUufF8WP/q3C7d?= =?Windows-1252?Q?03YKm60vISITZRDB9gpLxR6I/6AyU62Ho3akdw9gklKwqE+zUmvW3hh/?= =?Windows-1252?Q?06h35mFsatJB7834NNcA0mwWCQsRhJfFjeE2AwoZb17UY9wjnzNjiJMo?= =?Windows-1252?Q?XIVD9AL012GH4RMLUgpJq/OKe8QoPZtxvoNNmaZPm/QD7Y/REvJC+Llf?= =?Windows-1252?Q?fkrk5/ZY2TPqVB5x1C72ltbBG3ejW+xLyiuOSPTU+aYNeyzGFe/IL4bc?= =?Windows-1252?Q?Ibos2aEuw+wHKem2R+yGTGWGIWILorl9X08LzC5v8b7+tgT62F6IzIxL?= =?Windows-1252?Q?WN8dqO7Nicm6RbCBWtDCD3DSE66yO8AbdQ3kQP/ghyXhNQvru3oIU7/C?= =?Windows-1252?Q?eL0TA0eDNpKEwyEcboqEfY4lBXMdkhD+5Guu84FTVOFn4lh+ECA58igF?= =?Windows-1252?Q?8S8iIJqOuSt0ZgKiLPZF7RaTEDTVHY8aBLABPYwbvzMMXPQ2guizMOVW?= =?Windows-1252?Q?vV457g6DaMFAWwRJ1jv37iHT6kaiHCDs0Tu/+vY+hSt6k5WzXsc8pWAV?= =?Windows-1252?Q?F9si4+mIwgAtLhmzk3sK0SKQBXMD2wxvzIK/1GHiR9EGoBtwG/JS3FMD?= =?Windows-1252?Q?F3EzuhCTY699rNwSZfHE7hDBQ53MbuO8mTIqihvh4PHa7ZCYNShJYaV3?= =?Windows-1252?Q?JwwklIxFu02S3MlX4oeiUzyNY5sMqeOYGvaPa241X1reTvS3JsImRfWr?= =?Windows-1252?Q?uvEMkY1xBGMDXfSz3Uxx481PAmk/AtNc6WzbrKdGb7dF48RA8dXHLIvp?= =?Windows-1252?Q?6H4iYpSuZKVZBTMOc9M8lgRdHAFqBf1YZXoW0uQ5XRtYfqMDuJi6I7aw?= =?Windows-1252?Q?cBqMluIuToYG9Rs+LjzBLS2LWBfsVnmCqEWueq+4h8fBTOWzlBFQDPK4?= =?Windows-1252?Q?ohoRD5pTmb1L45bkeemBvlfR4ZbyJIxhJ1iaoFpeYQxKgBLAia83NNlL?= =?Windows-1252?Q?7MGaQX1Lj7p1+gTl+vOt3wyQ9L2+OPSvG2JapBaPAb5jKuprp0sn/WHM?= =?Windows-1252?Q?ulucNCJiPJJ/TR6AzoifQ1uHWGYL9z/dLALknJY6UKcCt3Brf2fdBdov?= =?Windows-1252?Q?IktR3fPt3/1017yt4JP2zzXHsKZz2M35/eqe6mi/HUjShdyoIt+WnWQu?= =?Windows-1252?Q?CoFPZUZI0dusSdqX56+nP9+YyMybJX5WXPHK7ELROMel1b2kGtW0KPZn?= =?Windows-1252?Q?lqdpen0zqodEiBzHJLr1EUuaDcI/FJRDKvPrEJ6T0S8x3K4+hkBg3F0l?= =?Windows-1252?Q?e52xQwrb/UBpoOOHmJnO7FTLDYB7A0dKxnf67Vw+CNCN9L33lUnvd0PA?= =?Windows-1252?Q?0iOhHwMtGk9FG3gGbWrPz39Yte8ZOHfj8YPiZjw8ZAO5KW6JcngAE2DJ?= =?Windows-1252?Q?VmWSi7MCJARV3aZIjWAnszWziB9z2cvqX232qUNJqJLETgLpteKuNI3h?= =?Windows-1252?Q?D9WoaiLuovNoKLAkG1fabYnSCxU=3D?= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB30500AA57A7DD6F3170BB60F89269HE1PR0701MB3050_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 30b94900-2bc4-47ee-e50a-08d9e5656f17 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2022 09:30:06.6680 (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: 5CydejLHlB6XjbH+nNI4HxX/eotiV64xoZl0TZCUaG5QtJh02OjI9zBeHAfbmklFBt/L8sRlN/MlgQzywdM1AM5tFpD8N4zQsuXbkTu2Awk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR07MB8420 Archived-At: Subject: [core] FW: New Version Notification for draft-mattsson-core-coap-attacks-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2022 09:30:20 -0000 --_000_HE1PR0701MB30500AA57A7DD6F3170BB60F89269HE1PR0701MB3050_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, -02 tries to address almost all received comments on -00 and -01. - A paragraph explaining freshness, replay protection, and sequence numbers= has been added. - More references to the soon to be published RFC 9175 (Echo, Request-Tag, = and Token Processing) - While RFC2119 terminology is perfectly fine in an informational draft/RFC= it is not needed in this document. All RFC2119 terminology has been removed based on a comme= nt from Carsten. - Added more details on which protocols are affected by the attacks and som= e practical difficulties based on comments from Achim. - Corrected text on OSCORE over TCP. It is TLS-like replay protection that = mitigates the attack, not TCP. - Added a sentence on why misbinding attacks do not work on HTTPS. - Changed homeless/hitman/killed to something nicer based on Carsten=92 com= ment. - Smaller editorial changes (several based on comments from Carsten) I think this would be a good time to have an adoption call for the document= . Echo, Request-Tag, and Token Processing will soon be published as RFC 917= 5. It would be good to publish the informational =93CoAP Attacks=94 as a co= mpanion document in the not-too-distant future as suggested by the security= AD. https://mailarchive.ietf.org/arch/msg/core/i6bf9C0ObT5FIplkHPms9gaC47U/ Cheers, John From: internet-drafts@ietf.org Date: Tuesday, 1 February 2022 at 09:59 To: Christian Ams=FCss , G=F6ran Selander , John Mattsson , Ch= ristian Amsuess , Francesca Palombini , G=F6ran Selander , John Fornehed , John Mattsson Subject: New Version Notification for draft-mattsson-core-coap-attacks-02.t= xt A new version of I-D, draft-mattsson-core-coap-attacks-02.txt has been successfully submitted by John Preu=DF Mattsson and posted to the IETF repository. Name: draft-mattsson-core-coap-attacks Revision: 02 Title: CoAP Attacks Document date: 2022-02-01 Group: Individual Submission Pages: 25 URL: https://www.ietf.org/archive/id/draft-mattsson-core-coap-at= tacks-02.txt Status: https://datatracker.ietf.org/doc/draft-mattsson-core-coap-a= ttacks/ Html: https://www.ietf.org/archive/id/draft-mattsson-core-coap-at= tacks-02.html Htmlized: https://datatracker.ietf.org/doc/html/draft-mattsson-core-c= oap-attacks Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mattsson-core-coa= p-attacks-02 Abstract: Being able to securely read information from sensors, to securely control actuators, and to not enable distributed denial-of-service attacks are essential in a world of connected and networking things interacting with the physical world. This document summarizes a number of known attacks on CoAP and show that just using CoAP with a security protocol like DTLS, TLS, or OSCORE is not enough for secure operation. The document also summarizes different denial-of-service attacks using CoAP. The goal with this document is motivating generic and protocol-specific recommendations on the usage of CoAP. Several of the discussed attacks can be mitigated with the solutions in draft-ietf-core-echo-request-tag. The IETF Secretariat --_000_HE1PR0701MB30500AA57A7DD6F3170BB60F89269HE1PR0701MB3050_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi,

 

-02 tries to address almost all received comments on= -00 and -01.

 

- A paragraph explaining freshness, replay protectio= n, and sequence numbers has been added.

- More references to the soon to be published RFC 91= 75 (Echo, Request-Tag, and Token Processing)

- While RFC2119 terminology is perfectly fine in an = informational draft/RFC it is not needed

in this document. All RFC2119 terminology has been r= emoved based on a comment from Carsten.

- Added more details on which protocols are affected= by the attacks and some practical difficulties based on comments from Achi= m.

- Corrected text on OSCORE over TCP. It is TLS-like = replay protection that mitigates the attack, not TCP.

- Added a sentence on why misbinding attacks do not = work on HTTPS.

- Changed homeless/hitman/killed to something nicer = based on Carsten=92 comment.

- Smaller editorial changes (several based on commen= ts from Carsten)

 

I think this would be a good time to have an adoptio= n call for the document. Echo, Request-Tag, and Token Processing will soon = be published as RFC 9175. It would be good to publish the informational =93CoAP Attacks=94 as a companion docume= nt in the not-too-distant future as suggested by the security AD.

 

https://mailarchive.ietf.org/arch/msg/core/i6bf9C0Ob= T5FIplkHPms9gaC47U/

 

Cheers,

John

 

From: internet-drafts@ietf.org <internet-dr= afts@ietf.org>
Date: Tuesday, 1 February 2022 at 09:59
To: Christian Ams=FCss <c.amsuess@energyharvesting.at>, G=F6ra= n Selander <goran.selander@ericsson.com>, John Mattsson <john.matt= sson@ericsson.com>, Christian Amsuess <c.amsuess@energyharvesting.at&= gt;, Francesca Palombini <francesca.palombini@ericsson.com>, G=F6ran Selander <goran.selander@ericsson.com>, John Fornehed <jo= hn.fornehed@ericsson.com>, John Mattsson <john.mattsson@ericsson.com&= gt;
Subject: New Version Notification for draft-mattsson-core-coap-attac= ks-02.txt


A new version of I-D, draft-mattsson-core-coap-attacks-02.txt
has been successfully submitted by John Preu=DF Mattsson and posted to the<= br> IETF repository.

Name:           draft-mat= tsson-core-coap-attacks
Revision:       02
Title:          CoAP Attacks Document date:  2022-02-01
Group:          Individual Sub= mission
Pages:          25
URL:            https://www.ietf.org/archive/id/draft-mattsson-core-coap-attacks-02.txt=
Status:         https://datatracker.ietf.org/doc/draft-mattsson-core-coap-attacks/
Html:           https://www.ietf.org/archive/id/draft-mattsson-core-coap-attacks-02.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mattsson-core-coap-attacks<= br> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-mattsson-core-coap-attacks-02=

Abstract:
   Being able to securely read information from sensors, to secur= ely
   control actuators, and to not enable distributed denial-of-ser= vice
   attacks are essential in a world of connected and networking t= hings
   interacting with the physical world.  This document summa= rizes a
   number of known attacks on CoAP and show that just using CoAP = with a
   security protocol like DTLS, TLS, or OSCORE is not enough for = secure
   operation.  The document also summarizes different denial= -of-service
   attacks using CoAP.  The goal with this document is motiv= ating
   generic and protocol-specific recommendations on the usage of = CoAP.
   Several of the discussed attacks can be mitigated with the sol= utions
   in draft-ietf-core-echo-request-tag.

            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


The IETF Secretariat

--_000_HE1PR0701MB30500AA57A7DD6F3170BB60F89269HE1PR0701MB3050_-- From nobody Tue Feb 1 08:03:27 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F3B3A1439 for ; Tue, 1 Feb 2022 08:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 bLrUGX-SuYpP for ; Tue, 1 Feb 2022 08:03:15 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620523A14D6 for ; Tue, 1 Feb 2022 08:02:40 -0800 (PST) Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Jp8pM5xPkzDCfK; Tue, 1 Feb 2022 17:02:35 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Tue, 1 Feb 2022 17:02:35 +0100 X-Mao-Original-Outgoing-Id: 665424154.852084-4a0d090414fd0a769ec9e0b728bded04 Content-Transfer-Encoding: quoted-printable Message-Id: References: <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> <8CDC234A-7F52-4571-8CCA-0D5F59A84DB6@tzi.org> <5B94533C-55C8-4DD8-BB57-29E96880A951@tzi.org> To: "t2trg@irtf.org" , "core@ietf.org" X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Quick Doodle T2TRG security topics (Re: [T2TRG] New topic for T2TRG?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2022 16:03:20 -0000 A Webex for the followup meeting now: https://ietf.webex.com/ietf/j.php?MTID=3Dm211a9425e38df42c96efa9e375a5801e= Gr=C3=BC=C3=9Fe, Carsten > On 2022-01-11, at 15:26, Carsten Bormann wrote: >=20 > On 2021-12-21, at 18:17, Carsten Bormann wrote: >>=20 >> So we=E2=80=99ll try to have a few short emails (=E2=80=9Cdocuments=E2=80= =9D) out with this by Monday, 2022-01-10, and meet again 2022-01-11 at = 1600Z again to merge and make this more concrete. >=20 > For those who want to join this chat, the Webex information: >=20 > T2TRG security topics >=20 > 16:00 - 17:00 Tuesday, 11 Jan 2022 (UTC+00:00) Reykjavik >=20 > Meeting link: > = https://ietf.webex.com/ietf/j.php?MTID=3Dm1fe31895b69dbf3669b4976b6b61d723= > Meeting number: > 2437 371 0612 > Password: > constrained >=20 > We=E2=80=99ll take notes at: >=20 > https://notes.ietf.org/notes-t2trg-chat-2022-01-11 >=20 > You can edit the proposed agenda there. >=20 > Let=E2=80=99s talk in ~ 90 minutes... >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Wed Feb 2 05:02:42 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457843A012C for ; Wed, 2 Feb 2022 05:02:35 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 w7pkCm_DyH3j for ; Wed, 2 Feb 2022 05:02:33 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F393A0991 for ; Wed, 2 Feb 2022 05:02:32 -0800 (PST) Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Jphm361lyzDCfx; Wed, 2 Feb 2022 14:02:27 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Wed, 2 Feb 2022 14:02:27 +0100 Cc: "core@ietf.org" , t2trg@irtf.org X-Mao-Original-Outgoing-Id: 665499747.3266751-977cae689772ebb06c314485bec66db8 Content-Transfer-Encoding: quoted-printable Message-Id: <5AFB6C76-9C15-4050-B478-711832318342@tzi.org> References: <164370592991.14136.4943780498822971831@ietfa.amsl.com> To: John Mattsson X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] New Version Notification for draft-mattsson-core-coap-attacks-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 13:02:35 -0000 Hi John, > On 2022-02-01, at 10:30, John Mattsson = wrote: >=20 > I think this would be a good time to have an adoption call for the = document. Echo, Request-Tag, and Token Processing will soon be published = as RFC 9175. It would be good to publish the informational =E2=80=9CCoAP = Attacks=E2=80=9D as a companion document in the not-too-distant future = as suggested by the security AD. I think we need to open up this discussion a little bit before we = converge on a good way forward. We already have elements of solutions standardized, e.g., = echo-request-tag (RFC 9175-to-be). This is a standards-track document, = done in the CoRE WG. This document provides the implementer with a set of tools, but = doesn=E2=80=99t provide actionable guidelines as to when these tools = should be used. We obviously need more documentation. We could go ahead and do a BCP now, but somehow that might work = approximately as well as the hand-washing mandates that are trying to = prevent the spread of COVID-19 =E2=80=94 we don=E2=80=99t actually know = very well what works and what doesn=E2=80=99t (*). To really do a BCP that works in a sustainable way, we need to do a bit = more research: =E2=80=94 what attacks do occur in practice =E2=80=94 what solutions [mitigations] (RFC 7252, RFC 9175-to-be, = others) actually do work against these attacks =E2=80=94 are there workarounds against those solutions that an attacker = could use =E2=80=94 would certain solutions just shift around the attacks to a = different vulnerability =E2=80=94 what is the design space for potential additional solutions = that have fewer work-arounds =E2=80=94 if there are several solutions that one could choose from, how = do they compare in =E2=80=94 effectiveness =E2=80=94 onus on the communication partners and the network in = between =E2=80=94 can we come up metrics that actually allow an implementer to = make decisions in this complex space That information should not all go into the BCP, as this should focus on = the actionable advice. Instead, there should be a document that can be = referenced from the BCP to provide more detailed explanation and = rationale. That other document (=E2=80=9Cresearch document=E2=80=9D) would be a = natural thing to work on in T2TRG. We already have had some off-list = discussions that indicate that we might have critical mass for that. Gr=C3=BC=C3=9Fe, Carsten (*) Spoiler: Hand-washing does little against the spread of COVID-19. = But a general increase of handwashing is not bad at all, and it may be = hard to retract mandates until it is proven that handwashing never helps = (which you essentially can=E2=80=99t prove), so handwashing will stay on = as a ritual that started with COVID-19. One of my objectives is to minimize the number of rituals that we infect = our ecosystem with=E2=80=A6 From nobody Wed Feb 2 06:43:51 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB683A1012 for ; Wed, 2 Feb 2022 06:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, 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 M1xrufuCZIWw for ; Wed, 2 Feb 2022 06:43:45 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2048.outbound.protection.outlook.com [40.107.22.48]) (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 E3FFE3A100B for ; Wed, 2 Feb 2022 06:43:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JsV44ER8ddSLeGCYgnc53uThMT8G5HI6fbsxuD/op3NsqkDseyPXoKSsZnm6JZbD+6i/1bUzimgLFCXw94/njBT8Uni2yj4/8FbJoHE8nAhHJEY0ngutBeVLpNhnXIcrQfQfKT1AuPXBW41fM1pk7XeSNGxnBsWlwg2p/QiLZgKzin9XE8sUXv1lnnf2wVxnI9hwJiSgreQIk7iO6Ut0yj27ir7FgZjqeixrFoDrQjEf+IK/q1rMUJfBbLp/3esX9QBCsYEf8K7d5HP54ecqsbzNTHZChLaToEEYQeQVPB9LQ90HvB1kyB9ZNzvlQ4D72f+fooKFmDIrCGhpU1pr7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zlWc85C3PYFAXhKkWyzDeU7wyFoiKG7JIpy28Wokzhk=; b=LLltunwcJyanYVdppjJx1omY88HldkWXqYrtpHhGnLkSICgcATGcgzNGUxJfi0wn+cTjU3qVnW2Hbsdsu/Y1Z1eosjje9bDMN3yMdc1Ch8Rf3Zvv3PHJ2y1bUkBYQSO3NB/ZZ/8LzwPC1XR2a0fPxfimNRVyds7v101L+taV5ACUVP11sI12O5UqnFrbuJQpkAs0bXRkJnkQf+7akqXzM8ToGLnzR6cu9W4rrwexXlP7X6VDHfz7HJFv9NaSgrz8OCgx0hO8nl+056ldBKopuPB02H887/RuFEGjKW7AfM8+stHPoLVWGSG+bvsU13zZl9H5lJ+4HG3rwBXzEbR6Mg== 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=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zlWc85C3PYFAXhKkWyzDeU7wyFoiKG7JIpy28Wokzhk=; b=AJRgAxzpRJmpXRUFhTTmWnXr6O1Mf+vBCm4H0HbcAu0Uij/9gth7BA3i8XMVRnRU+e51j3+EERXLktmCGBjK2Wn7v7KWtIp5OKhwU4zFFFNv93EI50mDhYglTX23jShm2RmVsAtsd40TPPfCcEAUE+0IAJh0tGpjkItq3bmDDXE= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by DB7PR07MB4988.eurprd07.prod.outlook.com (2603:10a6:10:6b::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12; Wed, 2 Feb 2022 14:43:41 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b462:480e:b937:c62c]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b462:480e:b937:c62c%7]) with mapi id 15.20.4951.012; Wed, 2 Feb 2022 14:43:41 +0000 From: John Mattsson To: Carsten Bormann CC: "core@ietf.org" , "t2trg@irtf.org" Thread-Topic: [core] New Version Notification for draft-mattsson-core-coap-attacks-02.txt Thread-Index: AQHYF0n1JcPl+afQf0+0QyaIhsj8LKx+azISgAHQe4CAABjvRA== Date: Wed, 2 Feb 2022 14:43:41 +0000 Message-ID: References: <164370592991.14136.4943780498822971831@ietfa.amsl.com> <5AFB6C76-9C15-4050-B478-711832318342@tzi.org> In-Reply-To: <5AFB6C76-9C15-4050-B478-711832318342@tzi.org> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a73f147c-75fc-488d-63f6-08d9e65a6816 x-ms-traffictypediagnostic: DB7PR07MB4988:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: w455x6hmDdWCuq9WSktB/I3SOgS7s0Qqm7HAXLb9GLR6Z4RkOLCk0GkQBdX9VuYcfPX9oHDtwNln28i3WaoyJDxq7FPtGqI53BXVPaXZhD9t0CdvkzdWxxP2cVb9rnMXN1RSbbVm6CeLs6IJf3UVk9mqeSGhDvzCLjIdwbuGfrBV7IVSFTnW+D3fKIh274q/K2N5LwMUnYaL3nN2/RXrt8fcnXuxBKGTKBev2eaeU/Etd9xbexcbhcwnHS7Vah8Ybya6hpFI5inz5jUr7yEGThmYtefXP7jmOPjUYQKJrGbodQl5nIZql1tRIMmacvFQEyzvf1sd1CQDqfkL1LMyYTwNP4qR9VHZMKE2+bCqOZ5NHM/zD00EOEGHwRPX7hLZW1sKayUTM4vlslFN8qQnmegLfCv4Ep4X7eZN0FIHkxApW84boFQpl27DA9whynRbeNejp+oDqwVFr/LOyzcx2cdsFWioQWctqI0auhS1DoMYfMIRfNbGr/D3Tp/EtxrQVOISEAY580Z0K6dX/oA5Fe6+RO0eV8bpRUMogMWeueIlBaA7kMcqYZCHGzYrFxLrf8RFps1UdWvTIsJDqtt2NNay5OYfEa1hRUceBMSdxK6vx2mXo7cqpmfkyqAeFlz/ZcFdzf9L9UU9dMQZZaTvLVLuRFj5R+69/8CXllNJhYRoHqwjUl5S9wrkPoLMg6uyNaBPrKepChtjEo8joLAws5RT8kN5PzdRrgbbzTc6U1kzWFXOAxU0pPpnXxWu+9m+Q67JVPshPxmeDE7qfl62cGuwAp88bB/MYgaBRJpoHvDc2rNsZ9AfWdZa0CV10cEL57cMuro+DIdmbVmfEho/otDPmz6577hpobfpfrOSFdfEXWQWgV9UzdHytGH7HK15 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(966005)(86362001)(26005)(33656002)(508600001)(66556008)(66946007)(52536014)(186003)(9686003)(53546011)(6506007)(7696005)(8936002)(8676002)(64756008)(66476007)(66446008)(38070700005)(4326008)(91956017)(54906003)(6916009)(71200400001)(316002)(76116006)(5660300002)(38100700002)(15650500001)(44832011)(83380400001)(55016003)(82960400001)(2906002)(122000001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?RWQZUqhKOWj+4nXVOxEEahVbwWOJuS079Pm6UA5RKHDAZ40T5rtLpoov?= =?Windows-1252?Q?zOlbWgj9c+kSnfnJz5UgcnAEk61RnXJNbjcj6f9GkaSMBfC68EMb1RqX?= =?Windows-1252?Q?yjAYBqZ6D/Yy0Lm5xLcdfRkswGGrPaew6qwTzYz2uapX1nPC3TolcV9v?= =?Windows-1252?Q?9geRmQ1yrqm7orS8Yb5Iq4rhTQOfgp7fxOU3W8BWKh40u8DaLd918e32?= =?Windows-1252?Q?zYQqknW3F6BEOc8HJFozrzJYbOPoV+pbJQTvhTVhihLNTrWtabOlV+gL?= =?Windows-1252?Q?iCrwL+gTnNLgIMGNFVpNY886Z+64ZAxXPykyDBEiUjjrDgSdzfyrjwTA?= =?Windows-1252?Q?jX9NAAd0+7t8TCIYG8wMvH/7WaelK8XertETumJWM51VYh4wmoX4eX7P?= =?Windows-1252?Q?ZSZK+MiMzgZw68ZAXPVGfDXcQYWQXm09Dd1cfR68GzXTcAYTb7abaF7M?= =?Windows-1252?Q?S/KPUrcAFxF0SMq4Qvb9Q4pkbHRB/CG00vWwuOnLQtdbTOw40NULhM1e?= =?Windows-1252?Q?snEIcUXaMUSrSt8HzsiwdRu9x0nT/FTtld+c8CQqdO7M/QpSgjnlCllV?= =?Windows-1252?Q?RtCtoLp4Dk6jJDYOBmByVLF476JA6sMDHCLxZBzj86NuI/lnyCsYwlAs?= =?Windows-1252?Q?h/GtzwjTBhhLi+ieN5PHNx/nvLbnKzmlYlOvNnCLi2JPhxxj5HC1tlHO?= =?Windows-1252?Q?G5xyGE9nQEnvBcTnpevVuRWyFug5C/sKSIa4NZPwhfS7d2zZFGFcfQjL?= =?Windows-1252?Q?OXF0n4KauR2gNpuhuwpw11eUKF3QQPD70Pjc8SZGJSkV+R7Qw4ccGmDQ?= =?Windows-1252?Q?mpdR5jMeWS7ZkM6vJ+l1z+Y0kL2v8NOJyCykRfH/kldTWwLW95GbUgRa?= =?Windows-1252?Q?Z2F/Bu+99J6PHZ4JjNIqIeM0Vv9HxBDKBSDSG+Bx7eDy4vCVFatalC9N?= =?Windows-1252?Q?klgMG3zCBRpas/U2BavRUiKB3bsd3Vjwgzn9Eu+z4VmDpY72wLpvM0G5?= =?Windows-1252?Q?5iqUlqUfXt34jOkj95DfaGeeTvmpqBpsqtp5IqrruNESL/xyni21eiaJ?= =?Windows-1252?Q?0ajW5ufbyTc3LdYUaZB8zpMpGtVJGIrlJlMT8+L7q5ObfCvaDtVgYtQu?= =?Windows-1252?Q?HXTmsc6CxbzEE7jywiKhiiHkR0NKY6scVbGrBIg8hsKJYb/z0mIPHu2p?= =?Windows-1252?Q?hOuXPs7dAegIWP/5Qp27JuWlbuyYil4PgsCfqzBhJZY1zkI/DniQSMJk?= =?Windows-1252?Q?EEC/ek6aZ93/rCIsiQRCtsLgFfSd9B+O1uJptyAShfKAEJ2/pp+jAh8P?= =?Windows-1252?Q?CoBwMwSRQGXwA1mtMJ2qCGJGvmmPIfsxv2T2Q6qGvn5meX+S6CKJm1va?= =?Windows-1252?Q?paGX/1LUXInv+pV4Wd4MMpAf8QNGOaaw0ZkhDYS8tC9jUGKK6smN2ccZ?= =?Windows-1252?Q?x/0qS4hENqw5y9j6muL//S5T7p9Otm47dARKGKnpMinESaaJRloFysFu?= =?Windows-1252?Q?A2S8avRoXo7iiUGshFYHTnEW+rxnQEVoM2G5cuTbao07jmBkQMx6GufX?= =?Windows-1252?Q?JkCgACpBpnD+/5QkhzzXRQemhV5TAFF5JeuMsofg4lGKnI311dEnUtvr?= =?Windows-1252?Q?1mWNl8OpXfZ96qDrPFbypoa+WjlK5t+Rch2qNEBJpSuS65cmeQRNn34A?= =?Windows-1252?Q?5LBKHTeQAmLLXFZus1NvKIvR4YkUa9e2O5MincKGKzGal/UyMFAu7Cy4?= =?Windows-1252?Q?ZBn8GXoqG9zxbTEZfs8w54TsQuc3/3gI0OoUGu27dganC9EyGyf9hj6d?= =?Windows-1252?Q?fTQmNp7MdlWtAnxB5532sKohBiY=3D?= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB3050F758474CC029B932112F89279HE1PR0701MB3050_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a73f147c-75fc-488d-63f6-08d9e65a6816 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2022 14:43:41.6285 (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: AGd5BatlF3uscjyRz+hX+xkp9SdA7ZT8gNQGlZBU+UpxKySbjZsehug1TPOGdhLdUy0Dlbe8zZ2deU8ppwgKfLeocFo7nAhc95puuFKH0+o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4988 Archived-At: Subject: Re: [core] New Version Notification for draft-mattsson-core-coap-attacks-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 14:43:50 -0000 --_000_HE1PR0701MB3050F758474CC029B932112F89279HE1PR0701MB3050_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > We obviously need more documentation. I agree that we obviously need more research and documentation regarding am= plification attacks. I also agree that we need more discussion. I think it = would be very good if T2TRG do research on the topic. echo-request-tag (RFC 9175-to-be) will soon be published which provides mec= hanisms and guidance to mitigate some of the attacks described in draft-mat= tsson-core-coap-attacks. Regarding BCP, I agree with you that we don't have all the knowledge. On th= e other hand we need to make sure that amplification attacks using IoT devi= ces do net get worse. They cause significant and costly damage. Right now C= oAP is used in DDoS attacks, and it is not even clear that the devices used= are violating IETF requirements. I think a minumum right now is to publish descriptions on how CoAP can be u= sed in amplification attacks (draft-mattsson-core-coap-attacks) and to make= the amplification mitigation requirements in new RFCs (group communicaiton= , conditional attributes) stricter then CORE has done in the past. I agree that an BCP would likely be much better if written later. But one c= ould also arguee that if we know so little on how to mitigate IoT amplifica= tion attacks, publishing more IoT RFCs is unethical. I think a reasonable way forward would be - Soon: Publish descriptions on how CoAP can be used in ampli= fication attacks. - Soon: Discuss how to make the amplification mitigation requ= irements in new RFCs stricter between now and when the BCP is published. - Later: Publish T2TRG research document on denial-of-service= and amplification attacks. - Later: Publish BCP referencing the research document. For T2TRG, here are links to the last two presentation on the topic. https://datatracker.ietf.org/meeting/111/materials/slides-111-core-coap-att= acks-00 https://datatracker.ietf.org/meeting/interim-2022-core-02/materials/slides-= interim-2022-core-02-sessa-coap-attacks-draft-mattsson-core-coap-attacks-02= -00 Cheers, John From: Carsten Bormann Date: Wednesday, 2 February 2022 at 14:03 To: John Mattsson Cc: core@ietf.org , t2trg@irtf.org Subject: Re: [core] New Version Notification for draft-mattsson-core-coap-a= ttacks-02.txt Hi John, > On 2022-02-01, at 10:30, John Mattsson wrote: > > I think this would be a good time to have an adoption call for the docume= nt. Echo, Request-Tag, and Token Processing will soon be published as RFC 9= 175. It would be good to publish the informational =93CoAP Attacks=94 as a = companion document in the not-too-distant future as suggested by the securi= ty AD. I think we need to open up this discussion a little bit before we converge = on a good way forward. We already have elements of solutions standardized, e.g., echo-request-tag = (RFC 9175-to-be). This is a standards-track document, done in the CoRE WG. This document provides the implementer with a set of tools, but doesn=92t p= rovide actionable guidelines as to when these tools should be used. We obviously need more documentation. We could go ahead and do a BCP now, but somehow that might work approximate= ly as well as the hand-washing mandates that are trying to prevent the spre= ad of COVID-19 =97 we don=92t actually know very well what works and what d= oesn=92t (*). To really do a BCP that works in a sustainable way, we need to do a bit mor= e research: =97 what attacks do occur in practice =97 what solutions [mitigations] (RFC 7252, RFC 9175-to-be, others) actuall= y do work against these attacks =97 are there workarounds against those solutions that an attacker could us= e =97 would certain solutions just shift around the attacks to a different vu= lnerability =97 what is the design space for potential additional solutions that have f= ewer work-arounds =97 if there are several solutions that one could choose from, how do they = compare in =97 effectiveness =97 onus on the communication partners and the network in between =97 can we come up metrics that actually allow an implementer to make decis= ions in this complex space That information should not all go into the BCP, as this should focus on th= e actionable advice. Instead, there should be a document that can be refer= enced from the BCP to provide more detailed explanation and rationale. That other document (=93research document=94) would be a natural thing to w= ork on in T2TRG. We already have had some off-list discussions that indica= te that we might have critical mass for that. Gr=FC=DFe, Carsten (*) Spoiler: Hand-washing does little against the spread of COVID-19. But = a general increase of handwashing is not bad at all, and it may be hard to = retract mandates until it is proven that handwashing never helps (which you= essentially can=92t prove), so handwashing will stay on as a ritual that s= tarted with COVID-19. One of my objectives is to minimize the number of rituals that we infect ou= r ecosystem with=85 --_000_HE1PR0701MB3050F758474CC029B932112F89279HE1PR0701MB3050_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

> We obviously need more documentation.

 

I agree that we obviously need more research and documentation rega= rding amplification attacks. I al= so agree that we need more discussion. I think it would be very good if T2T= RG do research on the topic.

 

echo-request-tag (RFC 9175-to-be) will soon be published which prov= ides mechanisms and guidance to mitigate some of the attacks described in d= raft-mattsson-core-coap-attacks.

 

Regarding BCP, I agree with you that we don't have all the knowledg= e. On the other hand we need to make sure that amplification attacks using = IoT devices do net get worse. They cause significant and costly damage. Right now CoAP is used in DDoS attacks, and = it is not even clear that the devices used are violating IETF requirements.

 

I think a minumum right now is to publish descriptions on how CoAP = can be used in amplification attacks (draft-mattsson-core-coap-attacks) and= to make the amplification mitigation requirements in new RFCs (group communicaiton, conditional attributes) str= icter then CORE has done in the past.

 

I agree that an BCP would likely be much better if written later. B= ut one could also arguee that if we know so little on how to mitigate IoT amplific= ation attacks, publishing more IoT RFCs is unethical.

 

I think a reasonable way forward would be

-           =     Soon: Publish descriptions on how CoAP can be used in am= plification attacks.

-           =     Soon: Discuss how to make the amplification mitigation r= equirements in new RFCs stricter between now and when the BCP is published.=

-           =     Later: Publish T2TRG research document on denial-of-serv= ice and amplification attacks.

-           =     Later: Publish BCP referencing the research document.

 

For T2TRG, here are links to the last two presentation on the topic= .

 

https://datatracker.ietf.org/meeting/111/materials/slides-111-core-= coap-attacks-00

 

https://datatracker.ietf.org/meeting/interim-2022-core-02/materials= /slides-interim-2022-core-02-sessa-coap-attacks-draft-mattsson-core-coap-at= tacks-02-00

 

Cheers,

John

 

From: Carsten Bormann <cabo@tzi.org>
Date: Wednesday, 2 February 2022 at 14:03
To: John Mattsson <john.mattsson@ericsson.com>
Cc: core@ietf.org <core@ietf.org>, t2trg@irtf.org <t2trg@ir= tf.org>
Subject: Re: [core] New Version Notification for draft-mattsson-core= -coap-attacks-02.txt

Hi John,

> On 2022-02-01, at 10:30, John Mattsson <john.mattsson=3D40ericsson.= com@dmarc.ietf.org> wrote:
>
> I think this would be a good time to have an adoption call for the doc= ument. Echo, Request-Tag, and Token Processing will soon be published as RF= C 9175. It would be good to publish the informational =93CoAP Attacks=94 as= a companion document in the not-too-distant future as suggested by the security AD.

I think we need to open up this discussion a little bit before we converge = on a good way forward.

We already have elements of solutions standardized, e.g., echo-request-tag = (RFC 9175-to-be).  This is a standards-track document, done in the CoR= E WG.
This document provides the implementer with a set of tools, but doesn=92t p= rovide actionable guidelines as to when these tools should be used.

We obviously need more documentation.

We could go ahead and do a BCP now, but somehow that might work approximate= ly as well as the hand-washing mandates that are trying to prevent the spre= ad of COVID-19 =97 we don=92t actually know very well what works and what d= oesn=92t (*).

To really do a BCP that works in a sustainable way, we need to do a bit mor= e research:

=97 what attacks do occur in practice
=97 what solutions [mitigations] (RFC 7252, RFC 9175-to-be, others) actuall= y do work against these attacks
=97 are there workarounds against those solutions that an attacker could us= e
=97 would certain solutions just shift around the attacks to a different vu= lnerability
=97 what is the design space for potential additional solutions that have f= ewer work-arounds
=97 if there are several solutions that one could choose from, how do they = compare in
  =97 effectiveness
  =97 onus on the communication partners and the network in between =97 can we come up metrics that actually allow an implementer to make decis= ions in this complex space

That information should not all go into the BCP, as this should focus on th= e actionable advice.  Instead, there should be a document that can be = referenced from the BCP to provide more detailed explanation and rationale.=

That other document (=93research document=94) would be a natural thing to w= ork on in T2TRG.  We already have had some off-list discussions that i= ndicate that we might have critical mass for that.

Gr=FC=DFe, Carsten

(*) Spoiler: Hand-washing does little against the spread of COVID-19. = But a general increase of handwashing is not bad at all, and it may be har= d to retract mandates until it is proven that handwashing never helps (whic= h you essentially can=92t prove), so handwashing will stay on as a ritual that started with COVID-19.
One of my objectives is to minimize the number of rituals that we infect ou= r ecosystem with=85

--_000_HE1PR0701MB3050F758474CC029B932112F89279HE1PR0701MB3050_-- From nobody Wed Feb 2 06:49:56 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3AD3A107B for ; Wed, 2 Feb 2022 06:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 z_oRrSZuHZgv for ; Wed, 2 Feb 2022 06:49:51 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89973A1079 for ; Wed, 2 Feb 2022 06:49:50 -0800 (PST) Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Jpl7w2swDzDCnV; Wed, 2 Feb 2022 15:49:48 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Wed, 2 Feb 2022 15:49:47 +0100 Cc: "core@ietf.org" , "t2trg@irtf.org" X-Mao-Original-Outgoing-Id: 665506187.814895-a62db6e08abfceac226c6463638acaec Content-Transfer-Encoding: quoted-printable Message-Id: <9F1343E2-B330-4ED8-8ECB-591A013A51EF@tzi.org> References: <164370592991.14136.4943780498822971831@ietfa.amsl.com> <5AFB6C76-9C15-4050-B478-711832318342@tzi.org> To: John Mattsson X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] New Version Notification for draft-mattsson-core-coap-attacks-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 14:49:56 -0000 On 2022-02-02, at 15:43, John Mattsson = wrote: >=20 > Publish I think we need to discuss what this means. In order of effort/time needed: 1 Publishing as a BCP >=20 2 Publishing as a (WG consensus) informational RFC >=20 3 Publishing as an (RG consensus) informational RFC >=20 4 Publishing as an (RG-sponsored) informational RFC > 5 Publishing as an Internet-Draft We already have (5); this could be improved by separating the DoS part = (attacking using CoAP) from the attacking CoAP part. Further improved by adopting (in RG or WG, depending on next step). Obviously, we also want to move forward on the attacking CoAP part. Similar considerations apply, but I think these should be run = separately. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Feb 2 08:41:46 2022 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C985B3A15A3; Wed, 2 Feb 2022 08:41:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: core-chairs@ietf.org, core@ietf.org, francesca.palombini@ericsson.com, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164382010474.18312.17930462030489873185@ietfa.amsl.com> Date: Wed, 02 Feb 2022 08:41:44 -0800 Archived-At: Subject: [core] core - New Meeting Session Request for IETF 113 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 16:41:45 -0000 A new meeting session request has just been submitted by Marco Tiloca, a Chair of the core working group. --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Marco Tiloca Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: Chair conflict: ace cbor t2trg cose lake artarea asdf Technology overlap: teep saag secdispatch sacm lwig 6tisch 6lo roll httpbis lpwan raw iotops Key participant conflict: irtfopen rats suit dnssd netconf netmod emu dots anima jsonpath sedate opsawg coinrg People who must be present: Jaime Jimenez Francesca Palombini Marco Tiloca Resources Requested: Special Requests: Please keep the 2 hours on a single session. Please also avoid any potentially IoT related BOFs and PRGs that might come up. --------------------------------------------------------- From nobody Wed Feb 2 09:00:42 2022 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA0B3A1605; Wed, 2 Feb 2022 09:00:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164382122026.21407.10738083735631049546@ietfa.amsl.com> Date: Wed, 02 Feb 2022 09:00:20 -0800 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2022-02-24 CHANGED X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 17:00:32 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Constrained RESTful Environments (core) WG will hold a virtual interim meeting on 2022-02-24 from 16:00 to 17:30 Europe/Stockholm (15:00 to 16:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=dca7677a-a7e4-4f63-812a-19b9a041c958 From nobody Wed Feb 2 09:03:50 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4429E3A1605 for ; Wed, 2 Feb 2022 09:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, 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 yBLvXe_RcXq6 for ; Wed, 2 Feb 2022 09:03:44 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50047.outbound.protection.outlook.com [40.107.5.47]) (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 018193A1720 for ; Wed, 2 Feb 2022 09:03:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RcRTiP71+d1sP1k7HE4HRdtbhOah+aJ5s7bZNblhklBU960CJy1rRYW+n9ZHMek/0SP9aP2UFLUUrcc019ALkXndVPRF/qN022CCnqfOFOA8Kg1uKaBHXDZDRnJz0YHljVTeyLmRiUDdY1XCTDrPBVvN1O8a4y6Jf/9D51hWFXaGqnMfJHFth/tqYS3snG2xu12EahlNWMmB2BchYSrf8cWDJ0M1Rw8juqnSMqidf6GeBPPehXTv3h5kamAhE19PUiqLhatJIk5Von2Qe5oHXQlCLTvBFFIGAcEoqB8R20OFSPLsZXUqdiMkyrBAsAY+pND3u9fBR1KLHEjnink+9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=e8orrbM9+i++fpf63pirtIUjX5V4plXFJ5UwIu4Q8SU=; b=kSTq+0/79CYCdM3V6uF/Zd0kH/SBuR0BcMqjQ+7CS5UI/EwA4444FhDclkuH0wG5aEfhrCwe4SqXWrbnTn20Vhm2lBm8fPdKFzwcqiqRycwsx2T3w1GHEgiE5wpdxZQorujnCbhGOlK25FoBu5/pVtiwQQaY67v7Fcu4fcVQAaf4eRjlIc9C4mqHynKuzsUuJYLvzeOEwnXZaFVJNp+cvEnznjvoGGYkO+ZYhGzd2ZzSNQu34RtMMaOaR1L/zn9RbI4mi+VEuaYragDJKum8VcvRnuI77O24dqB7nJMYW7G5lTiupMrOj7acq9HZRS48jBjef2B9rHRz4CdaxKbW5A== 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=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e8orrbM9+i++fpf63pirtIUjX5V4plXFJ5UwIu4Q8SU=; b=nhLkfwbSRJy32TJnV+6+bkF2xK2WWHVEoPj0c2ri8kxOxFOIv5sTCsPkxRP9tZVrlVf7Oe7UdPHndTed66WQj4QUkfq50C3kv8i+o7fh8lBa/OYqjsGyYg+jdBM4mxeGj0yLEtb7JBB79BifUY6lYKw3FhuJ3/ZbHyV74KM7Lyg= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by VI1PR07MB4525.eurprd07.prod.outlook.com (2603:10a6:803:76::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.10; Wed, 2 Feb 2022 17:03:07 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b462:480e:b937:c62c]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b462:480e:b937:c62c%7]) with mapi id 15.20.4951.012; Wed, 2 Feb 2022 17:03:06 +0000 From: John Mattsson To: Carsten Bormann CC: "core@ietf.org" , "t2trg@irtf.org" Thread-Topic: [core] New Version Notification for draft-mattsson-core-coap-attacks-02.txt Thread-Index: AQHYF0n1JcPl+afQf0+0QyaIhsj8LKx+azISgAHQe4CAABjvRIAABQ6AgAAkrDM= Date: Wed, 2 Feb 2022 17:03:06 +0000 Message-ID: References: <164370592991.14136.4943780498822971831@ietfa.amsl.com> <5AFB6C76-9C15-4050-B478-711832318342@tzi.org> <9F1343E2-B330-4ED8-8ECB-591A013A51EF@tzi.org> In-Reply-To: <9F1343E2-B330-4ED8-8ECB-591A013A51EF@tzi.org> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5fb8437f-d240-4f03-1336-08d9e66de223 x-ms-traffictypediagnostic: VI1PR07MB4525:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VVgLlQ9ec3npvFzt4yoZfr2VQ54KPFNh50i4m1F9/7eSPspbzAZ7VJrxt+fPmHB+rnX69Dr8JAtachkjIs7lx508MByKsFVwd7Nd742cDy1Ma7Yh7ve+WAb3tMSg3wFvKlJFk44l7t9PdSWSy1aCGlfKfBke8fY3FtMkfnjBZmGAPmmTVylAh+6rUzCCxodTS8o6CrvrwQFq0veg2JXrA6RtSS62mpKyBBgRLMk5KcHeZJPY5BkuR84fZgjCmzVBN7WfSR5KFnmjukGipjciVXyK6XqAypRdM+OKIZmeUf8d5Yx1IYV/GlKoku12AkLCAog9MOL0upC3qj2Rt4/+oI3jzEKjetBmptCQt9BnEDyMdBAFsqL8QvOULrK5omj/QyL49Bczzi8PamOQy4dZiqPFpnQcvO0MEbSUTkcBmiJvi2lUgL3796cJKYJ5OIlndte7+iOkQboMVKhoqqVCRivTyqnpg/KJc9A3N+QHD4PKTlaqtt01bwrdJpF3grPW3syraVSOjzfZtAZaqwuDrkU1JB0flD8AtrX4HNmnXC2uwKjrOSAN6Fu+855wP36vlBlfB0pRwlsH8r5h4BOF1V3Ki8N+C4dum96XE0wPJ5TZJwVkrAsA8o7kaOCCWAiMfUkZ6yYoKe3QxMNfNgb/FJX/38wBG7jfc6HyTLQFZwmu/i/eX4vt6NuAWUc2eLsVnSbxfQse1rMR9U+ykD1bQA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(38100700002)(44832011)(26005)(52536014)(33656002)(82960400001)(186003)(5660300002)(38070700005)(122000001)(508600001)(8676002)(6506007)(8936002)(66556008)(66946007)(7696005)(66476007)(71200400001)(53546011)(4326008)(9686003)(86362001)(64756008)(66446008)(54906003)(83380400001)(91956017)(316002)(2906002)(55016003)(6916009)(76116006)(15650500001)(66574015); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?e/A1xv1XcQ8LBHWZdfyxTuWfoE+inOrH0Da9w7zZumrPMjsNHZ8w7tuLf0?= =?iso-8859-1?Q?CP9GSmxKE5uStiMCdgACSnWgw9KaxmzKrCYuEgI/b4Wn76v8rjKFxttG+g?= =?iso-8859-1?Q?GIsn5r2dlGJ7DbkBtqZGrRxeIFMmREhpOz5Wml7L+HXgFq8nxga577Lm9M?= =?iso-8859-1?Q?PvDxijT7vCQ760NzM72kmesUhu1aN9CsOB+pXhtGxlSymlIV1DPHVqqkau?= =?iso-8859-1?Q?AV7ZLAhx/bq0vY2L6CF6+kIt1i65q1N5TWMNGisP0MuQvTa6afrv+f8bwd?= =?iso-8859-1?Q?0au6ktuzQnOSrj6LSvKHarWGOpFFjoEzMvkT4Ew36q7+qtJo4Fa+BVSQoF?= =?iso-8859-1?Q?eyYP2LKX3Gk0t/Ar95r5N7ya8zUVFOI1/XLEEeOXsurNQSNDIE7ZsZX7he?= =?iso-8859-1?Q?/1V/schOc25DvvNQmgsn7GCKmRWFy6SpJfQ2QA9C8HUXPsPQNjpvBGAHtz?= =?iso-8859-1?Q?O+nJssKB0QEyQpGbv07jj/w5ICeEYKuarva4OEI4Qwbaps2mbs346rqE/1?= =?iso-8859-1?Q?L3qW2Csp/KvkDZSjgsCOlOMD99wf0yU8WdCL/tg+mAyKILti4XHL/LfDDq?= =?iso-8859-1?Q?ChsqKiM23nGij3iA/0nNSqNKnhMhY6bZjqB/ynejpECA/m7cfDMin1AW31?= =?iso-8859-1?Q?+wPXoippsvDCH9w22ef+UOA4gSnuqY91UrnWJNRcAWgmE/+Wmx4RwcPx0P?= =?iso-8859-1?Q?RvSaXId3eCB5co7bjtNqM1unCzv/Yeapq2GgXiwQ1NnZmFAwvrLms+k6y3?= =?iso-8859-1?Q?lP3wupc3k/OAw6r8Gf6ws7fW/ZyvrG3+vrHhuElvGOIzNUCJ6u59ZwX8HH?= =?iso-8859-1?Q?dm0Zd/CHF30nYDUBDboFrJIooQk3U6iNxULIvukaYCqtX8SdZw8Dxf23AW?= =?iso-8859-1?Q?3XRm7mUx7Hlx0pFcBOAoANnfkqWuNbzBkFLFAJDBj8gh2IXuwnsM/XC4uU?= =?iso-8859-1?Q?W5S2pV3wqQ27foUpkqNpF7aQFWIo8DRmw/8P108Shplmil91UEbVrTWfJl?= =?iso-8859-1?Q?GL51qFH7N+M5dmfB3/ecFAdOmsrXWSJWqTUBpBVhHYz8LfYZbKErVpcC9i?= =?iso-8859-1?Q?Eo4KPHZOPQ32KBSZ7ORLUcjs2Ew9q/xjcw2QAb/F3gRKvP8im0xXiFJW8u?= =?iso-8859-1?Q?alv2mb/Fwn54hDLKF/neEnjRR6qRtnci/hfQe/wdTDRSUs7VWK/uzeZ0nX?= =?iso-8859-1?Q?m+xzgLEIsAIfWfeKPEH/Jei/Je8Fhb1jaF90hZoyx7ZzB1zFxLCIbFad7I?= =?iso-8859-1?Q?gGI/Nq6H+Mbt8j8BPlo456mA1xV2BLMEzfnf2QwDuNxiXK2bLjzDxWpq7o?= =?iso-8859-1?Q?ZJp4vNghnXTJfexDvn3dFPBawHAYeaFdItrcGV1ercg6pIy9ViyfUN/W66?= =?iso-8859-1?Q?hDZerR6PFTCIlp3Pv1RhwC/c35gJfhI9e796dzV04QawfWv0/9R3BjISr6?= =?iso-8859-1?Q?xYoYHeAJVLoT4UcgC1Tu/Z+KXPAInvw90oeccUpb3vHISEHYx/LqPk4h2K?= =?iso-8859-1?Q?AScTn4GdeD7VWBHn2WFnRVSQaHJ/HlHUJI+8QGBOQKdtUqSMgJuVuIMXep?= =?iso-8859-1?Q?U8BBCwzrKPsz4PhX8TqJUrnETzw7GBTycP0JqUHeT6CY97sIY9VPmXNNl3?= =?iso-8859-1?Q?qFP7TnsELgATWOiCnlkRGQY8+yrGuBKXxd+IGejf2GYvzryumfwg5eWPOp?= =?iso-8859-1?Q?EfdVoxYcVgsdJdV1W5I+vU/c2aDrD7drb0fvyL4BLh5TkPWodGfiAPMAf9?= =?iso-8859-1?Q?9nDDXqtWquO4iOuKtclcO+7G8=3D?= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB3050423B37F408F2C9F8B98689279HE1PR0701MB3050_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5fb8437f-d240-4f03-1336-08d9e66de223 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2022 17:03:06.8471 (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: JdARIHlDH1lcsn8c66YVPYaW9hhTGaFdKObUG5rKkrLAPd9M8mRpHCyApq1S5/mAK0OAsls2Q4NjGCAAf4VXPqkOyS1X8vPxTPp4D9uiy5Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4525 Archived-At: Subject: Re: [core] New Version Notification for draft-mattsson-core-coap-attacks-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 17:03:50 -0000 --_000_HE1PR0701MB3050423B37F408F2C9F8B98689279HE1PR0701MB3050_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Conclusion (at least my understanding) from todays interim: Split the current document in two different documents: 1. Attacks on CoAP 2. Attacks using CoAP (aplification attacks) CORE will have an adoption call on the first document. We will discuss where to work on the second part. Carsten suggested to work on amplification attacks purely in T2TRG. I think= I would be ok with that approach as long as we have a plan for what to do = in the mean time. I think all future IETF document (not only IoT and not on= ly CoAP) need to have much stricter requirements on denial-of-service mitig= ation. If IETF does not have a good DoS hygiene, likely nobody else will. As a security person, I would like to start with hard requirements like QUI= C and then soften the requirements when we have more knowledge, but I agree= that this is problematic for constrained IoT and not optimal at all. But D= oS mitigation do cost, and devices need to take that cost. The alternative = is that somebody else (services and infrastructure) has to take the cost, w= hich is unacceptable. From: Carsten Bormann Date: Wednesday, 2 February 2022 at 15:49 To: John Mattsson Cc: core@ietf.org , t2trg@irtf.org Subject: Re: [core] New Version Notification for draft-mattsson-core-coap-a= ttacks-02.txt On 2022-02-02, at 15:43, John Mattsson wrote: > > Publish I think we need to discuss what this means. In order of effort/time needed: 1 Publishing as a BCP > 2 Publishing as a (WG consensus) informational RFC > 3 Publishing as an (RG consensus) informational RFC > 4 Publishing as an (RG-sponsored) informational RFC > 5 Publishing as an Internet-Draft We already have (5); this could be improved by separating the DoS part (att= acking using CoAP) from the attacking CoAP part. Further improved by adopting (in RG or WG, depending on next step). Obviously, we also want to move forward on the attacking CoAP part. Similar considerations apply, but I think these should be run separately. Gr=FC=DFe, Carsten --_000_HE1PR0701MB3050423B37F408F2C9F8B98689279HE1PR0701MB3050_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Conclusion (at least my underst= anding) from todays interim:<= /o:p>

 

   Split = the current document in two different documents:

   1. Att= acks on CoAP

    2. At= tacks using CoAP (aplification attacks)

 

    CORE = will have an adoption call on the first document.

    We wi= ll discuss where to work on the second part.

 

Carsten suggested to work on amplification attacks p= urely in T2TRG. I think I would be ok with that approach as long as we have= a plan for what to do in the mean time. I think all future IETF document (= not only IoT and not only CoAP) need to have much stricter requirements on denial-of-service mitigation. If IETF does not have a good DoS hygiene, likely nobody else= will.

 

As a security person, I = would like to start with hard requirements like QUIC and then soften the requirements when we have more knowledge, but I= agree that this is problematic for constrained IoT and not optimal at all= . But DoS mitigation do cost, and devices need to take that cost. The alter= native is that somebody else (services and infrastructure) has to take the = cost, which is unacceptable.

 

 

From: Carsten Bormann <cabo@tzi.org>
Date: Wednesday, 2 February 2022 at 15:49
To: John Mattsson <john.mattsson@ericsson.com>
Cc: core@ietf.org <core@ietf.org>, t2trg@irtf.org <t2trg@ir= tf.org>
Subject: Re: [core] New Version Notification for draft-mattsson-core= -coap-attacks-02.txt

On 2022-02-02, at 15:43, John Mattsson <john.mattsson@ericsson= .com> wrote:
>
> Publish

I think we need to discuss what this means.

In order of effort/time needed:

1 Publishing as a BCP >
2 Publishing as a (WG consensus) informational RFC >
3 Publishing as an (RG consensus) informational RFC >
4 Publishing as an (RG-sponsored) informational RFC >
5 Publishing as an Internet-Draft

We already have (5); this could be improved by separating the DoS part (att= acking using CoAP) from the attacking CoAP part.
Further improved by adopting (in RG or WG, depending on next step).

Obviously, we also want to move forward on the attacking CoAP part.
Similar considerations apply, but I think these should be run separately.
Gr=FC=DFe, Carsten

--_000_HE1PR0701MB3050423B37F408F2C9F8B98689279HE1PR0701MB3050_-- From nobody Wed Feb 2 09:52:51 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0D33A16E6; Wed, 2 Feb 2022 09:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.81 X-Spam-Level: X-Spam-Status: No, score=-7.81 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, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMAFx1BvmLI9; Wed, 2 Feb 2022 09:52:44 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 7707F3A1833; Wed, 2 Feb 2022 09:52:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1643824350; bh=aSYnm/bnu0EcL1U3Q5NJGnhHMd09nxsYzgyW4yUYaVc=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=VBCN2+Lt/t4ZIcvSIJBb9cmo9Ri6d96fC6+nUJUBdPJi0uAOXrLhaXs7xg5s3V0uC GI9t2Gj2MIhZtbVRezQki3U9BQYO4LlyulOg/7GzjxRkDrvF8nRxm8E3o7+nSU0Pf4 CHKj0XiygJ6n1/4WyZ3B9xT4iB+cXBtZu8K9aTwc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.10] ([5.146.193.130]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1My32F-1mIZ4j32rP-00zXBE; Wed, 02 Feb 2022 18:52:30 +0100 Message-ID: Date: Wed, 2 Feb 2022 18:52:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: Carsten Bormann , john.mattsson@ericsson.com Cc: "t2trg@irtf.org" , "core@ietf.org" References: <164370592991.14136.4943780498822971831@ietfa.amsl.com> <5AFB6C76-9C15-4050-B478-711832318342@tzi.org> <9F1343E2-B330-4ED8-8ECB-591A013A51EF@tzi.org> From: Achim Kraus In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:8TCdd1WKt7kFGOtf1f7aNgFvUK1FoH2VtcstqbSxOgbeIxU5dH9 j/8F6nl+xx65epBLNcJ3gku5iXddy0cjGvxkyRZaIxIjiD4kAvva1ll6UZco96PKbZa6Sow YE8k2jx6+JzGcz0zr9rk0prJx8ks8+SXotf/IlTt6GU08Mc3c5H4lPMZelAuBk1XHKOvxJR aUdMdIbvsMSLVaxTMYUSA== X-UI-Out-Filterresults: notjunk:1;V03:K0:dmrm3eojS3Q=:9QExgqS4nl3aUtmijak6nB aVms810OWIAgdaq3J3diVizIR7PoznoTuReMqhjDg46AyVt8sPjSt91/g35a8TUaYE/+rwKrF pSpHZxwkNj51WHaHc6j9rmIKGxJwyMXf5l8ZXK1j5ULXIQcTUtq4hcdKTW8eqp96lhGHjGmYK 2QjA2UwosXXbt+JkgxiuNXvuflJhVeFqhOSwHFbpnbOLkF+Ll792W96GHG5t1N9SugqXygmFp xxDBTin4vR6Xj1oqKV6Iw5ufgS3GMGIsVbN0vtfJk/6EJq6NWWQMhJzcYUwLa7J8F+TBJ4bco u/aHbINDO9kxusoqh5r+7/J3wChUj2lJ9Rd1LfpvgSCeDrPBwS2b1N/l+Op93X/Lm43qoSOHt exO7/r/h0uNamHboAqfyvGMR7ahwYyqPbtLIWDZGi5GgkGkoAFoRVh/AnC9s05evrCf2184vk WwUDBL3bU41vsZZpw4jRAKwnO0Hw/OPKSt6RZhC9Z2uPIFkBvO5C/s9rFu/sX2kBTZbZ+cz9V 7D9ItAlzgceqCZHeRbFu/v5fAAHo+RbLe3D/XTc229/QwTmcG16xVzyL3px37oGq9sYciNpfQ /aL7U4Te874rAJQ3BFAPTnMtyQLBIGPYSSrD1ZZRpehyPuEPrVdPdKwmEObVfiKzwHYJ9rYXU sfZqURZfkcq1h1KNw87qQzANMllAO+Loxq6xdBsp83b/YoC5i94X/9rrkKUJuE6JVgUnrBMXF QXTFeiNa5BkayIxpCF3NfeFOO2/g+rx6CHqGq4EuwoRV3hfrYOF25FXY8F9MGXgp3m5/iG8nM kKVi4EP1AcnoYZVTgypuEZcSs1hC3de/0X3ciqipXgazuOYCrm0MElCG078P5XCMyPMz6WA4c 5nrlr2nUsVBTpCw1rSfxtWJ5s5hLieJee3502bZAj2pRUB8+1ubh8oc/9Ts8X58cEcTF4EqNB Ivk+cpXOne8zuWA8RG7iGeOBWImZrloCAcyBAbnkp78A+D7MEh9gDA5THsSwI3vXuOMr1EcJv iUMjbJW8Df8FUm5WsF7t809t+Zwzz0di4hKhjd0X4Goj6QRFrGHcm9WTOmED3Xt40MfxOasH6 CY+9aLG56OxufY= Archived-At: Subject: Re: [core] New Version Notification for draft-mattsson-core-coap-attacks-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 17:52:49 -0000 Hi John, Hi Carsten, Hi List, about the amplification attacks: Is there any newer or more concrete information about that then https://www.netscout.com/blog/asert/coap-attacks-wild ? (My impression is, that others mainly refer to the same. You may check my list on https://github.com/eclipse/californium/wiki/Links-to-CoAP-or-DTLS-1.2-rese= arch-information#security---dtls--coap ). I'm not sure, if there is a common, realistic understanding of the "nature" of such an attack. At least I have much more questions than answers. E.g. is amplification only relevant above some threshold? Means, if a request with 80 bytes is used and the response has 160, is that relevant? Or must the response be above 400 bytes in order to get relevant? So, in theory there may be a lot of rules, but I'm afraid, that these rules stay theoretical, complicated, and maybe practically wron= g. best regards Achim Kraus P.S.: The number of unencrypted coap devices is currently declining. It's now about 270.000 to 330.000. My own scan showed an average response size of 338 bytes, and a median of 143 bytes. https://github.com/eclipse/californium/wiki/Links-to-CoAP-or-DTLS-1.2-rese= arch-information#research-sites---current-scans Am 02.02.22 um 18:03 schrieb John Mattsson: > Conclusion (at least my understanding) from todays interim: > > =C2=A0=C2=A0=C2=A0Split the current document in two different documents= : > > 1. Attacks on CoAP > > 2. Attacks using CoAP (aplification attacks) > > CORE will have an adoption call on the first document. > > We will discuss where to work on the second part. > > Carsten suggested to work on amplification attacks purely in T2TRG. I > think I would be ok with that approach as long as we have a plan for > what to do in the mean time. I think all future IETF document (not only > IoT and not only CoAP) need to have much stricter requirements on > denial-of-service mitigation.If IETF does not have a good DoS hygiene, > likely nobody else will. > > As a security person, I would like to start with hard requirements like > QUIC and then soften the requirements when we have more knowledge, but I > agree that this is problematic for constrained IoT and not optimal at > all. But DoS mitigation do cost, and devices need to take that cost. The > alternative is that somebody else (services and infrastructure) has to > take the cost, which is unacceptable. > > *From: *Carsten Bormann > *Date: *Wednesday, 2 February 2022 at 15:49 > *To: *John Mattsson > *Cc: *core@ietf.org , t2trg@irtf.org > *Subject: *Re: [core] New Version Notification for > draft-mattsson-core-coap-attacks-02.txt > > On 2022-02-02, at 15:43, John Mattsson wrot= e: >> >> Publish > > I think we need to discuss what this means. > > In order of effort/time needed: > > 1 Publishing as a BCP > > 2 Publishing as a (WG consensus) informational RFC > > 3 Publishing as an (RG consensus) informational RFC > > 4 Publishing as an (RG-sponsored) informational RFC > > 5 Publishing as an Internet-Draft > > We already have (5); this could be improved by separating the DoS part > (attacking using CoAP) from the attacking CoAP part. > Further improved by adopting (in RG or WG, depending on next step). > > Obviously, we also want to move forward on the attacking CoAP part. > Similar considerations apply, but I think these should be run separately= . > > Gr=C3=BC=C3=9Fe, Carsten > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Feb 2 09:58:00 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC783A1812 for ; Wed, 2 Feb 2022 09:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 xNv7h1Qtq0gh for ; Wed, 2 Feb 2022 09:57:51 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36083A183A for ; Wed, 2 Feb 2022 09:57:50 -0800 (PST) Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JpqJn5yvLzDCcR; Wed, 2 Feb 2022 18:57:45 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Wed, 2 Feb 2022 18:57:45 +0100 Cc: John Mattsson , "t2trg@irtf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 665517465.321314-014d68d7dbb1e9436fc5bcd6bb119577 Content-Transfer-Encoding: quoted-printable Message-Id: <0E1DE32A-1762-46D0-B535-730E66FB2714@tzi.org> References: <164370592991.14136.4943780498822971831@ietfa.amsl.com> <5AFB6C76-9C15-4050-B478-711832318342@tzi.org> <9F1343E2-B330-4ED8-8ECB-591A013A51EF@tzi.org> To: Achim Kraus X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] New Version Notification for draft-mattsson-core-coap-attacks-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 17:57:53 -0000 Just picking one paragraph here: > On 2022-02-02, at 18:52, Achim Kraus wrote: >=20 > I'm not sure, if there is a common, realistic understanding of the > "nature" of such an attack. At least I have much more questions than > answers. E.g. is amplification only relevant above some threshold? > Means, if a request with 80 bytes is used and the response has 160, is > that relevant? Or must the response be above 400 bytes in order to get > relevant? So, in theory there may be a lot of rules, but I'm afraid, > that these rules stay theoretical, complicated, and maybe practically = wrong. That is exactly the issue that makes this so hard. We need to factor in how attackers are going to behave, so the answers = are neither exact nor stable. If there are better amplification sources, there will be much fewer = attacks using public CoAP servers. But once these go away, CoAP server suddenly seem interesting again. So the fixes in other protocols and implementations are our enemy = here=E2=80=A6 It seems you have data, and that is what I=E2=80=99d like to collect in = the T2TRG effort, together with what went wrong in the specific = instances. Then we need to forge these data into an assessment of the situation and = finally rules with a bit harder boundaries than the ones we already = have. That will be the BCP. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Feb 4 00:09:42 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132E03A0D7B; Fri, 4 Feb 2022 00:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 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, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39IBN7yCczg3; Fri, 4 Feb 2022 00:09:38 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 88F333A0D5F; Fri, 4 Feb 2022 00:09:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1643962163; bh=ME3ANMaGEKZRLeu1Hkmuuvxf0IkGJKIvLavtJnktYvk=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=jwdF+Klbmul9ZwpNVkBR6svWafz5PuU55p/0U31FNj64fmHuA2Zg/iS0/WTTq1Tp0 Poc1P6dYk50G1x8aU0Dh+lpNGcUUdSXSgP4tEc8mV3inEDhBb5U+T8077LNhxYJAlD 39fM/EZndtRlMJUEo7aHM73s/KuPsQ4/yDnMGCdo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.10] ([5.146.193.130]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MQe5u-1mtFvp0tlO-00NkZ8; Fri, 04 Feb 2022 09:09:23 +0100 Message-ID: <16853d5f-a795-3a59-f8d9-e5c2652d0d9d@gmx.net> Date: Fri, 4 Feb 2022 09:09:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: Carsten Bormann Cc: John Mattsson , "t2trg@irtf.org" , "core@ietf.org" References: <164370592991.14136.4943780498822971831@ietfa.amsl.com> <5AFB6C76-9C15-4050-B478-711832318342@tzi.org> <9F1343E2-B330-4ED8-8ECB-591A013A51EF@tzi.org> <0E1DE32A-1762-46D0-B535-730E66FB2714@tzi.org> From: Achim Kraus In-Reply-To: <0E1DE32A-1762-46D0-B535-730E66FB2714@tzi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:yeWwLQ7/cEomHAzh3cEQQZCTHiW4zzQyIlrQXl6gkOBZx6oHA/D 1q/aLG1aV8v6ejaojtKNvkfHWMtpSl62Yz7hoZcKEvzDFWm/Mivl6ngxKIfyn2bTZERLwx/ 3Q6EFGhiNltPxr3chiK9RNMVEKrB0U9haDpwBbsPmZzzMTMKp3L07A+km1iTcqwkgBmzcgq nIF3Z44IRMXK/pM6tFdTA== X-UI-Out-Filterresults: notjunk:1;V03:K0:9vrwnmefIbc=:G4aOzuJlQq0nG3TPJHx7Xf FgWtHE0gMX7wlrHUdfHGphgBEY7VIBpVbLE5pFy1AM9RBi8uiHRi4G45m1OitX6+eEawax78i 5/Rh28/sShY++p11FPToVFVwoecjH0gU5hTvMhI3A310B+epmfeCdzmC2N9Ag4Rp+/Ya+w0ko Z3Run9pu0Zimg0J4qoY/zWIgCQPQNJr3SW4HyywOYouViXFFlelYlu8vLCMaW4CQhOBHhbK9H PIQ0Yq5ZuCtNNun5mYf53tCFzYNnZa+A/2E2+ksN0hF93aGJzYR9L9AriYkufwRYh+Wz8AoX6 Eyg65yxeo+kx/QXYR/XFgBsYy2TZ/Vh+LSlLBltoiBDj+PTOHIbK4t5pYb5vh6fCjNIJFgsBO BfSCGhvEY7SKBIi+pyzikNdCmvotZzbKAvYV5oPrOSATBJysPQeudtmEO+OKX8cLqoKFIxPa8 idJUAFFz43Lk1NJZhQmWTVB2oNWC0yB1WvdbtORQgihwnpm1DkKCtvazwiYmlj+BxgCv82dOD bvTJ78hshKZyKubCslviAI6291teTMqXuTE6RMfWf09q8XN5RatyZL1urk7AEP8qMdL/rxtdV lZ2NJERdBsl45Onc9NPMuO4vEJDnYXoB364ZSjnHyBPJ7A1w73KLxUPhzWD+Xs0gPixSK5qII ikpFCwIY3mWuKOwmpbvq7AOa8qxSlwWk+dWEfeKlATGJaSdwv+8AmlZCjXicDvU3xTPuu31nI 8bKtFl/q102wwEGfQ/HyxHd7XLs4E3D/aHlbk+DNRVqlH0ohc/Jrex07uRW+8br1nXcy8wETj Cbt2stoT6Gr4OAekZnXKBQlq4vudXH4r2NDfUFJb/NXf9yIyw3X9oy1mse7M84VDZ0PFyEmuV HCTdiEci3HrqrqX91zRTIbzGT9Wx9M0vQO0ST4BJI0ml0jsjFmGFmU/6aeXhzQEkUdi+WTk/c eLuDHCacIls5PzDhfK1An8HWMzzw+Z9tQ77DnNI/t3atGMTVxs/LHd9R9MJiUJPwUYlimLUqg 4KpJbYbXPgZ/J33R2AHqe/y5etEVbMdechu6J0s/nyW6AgsjO9LW+UKOVupA9l5YkgwhdEAbb xrS63QjG6TUXfc= Archived-At: Subject: Re: [core] New Version Notification for draft-mattsson-core-coap-attacks-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2022 08:09:40 -0000 Hi Carsten, > That is exactly the issue that makes this so hard. > We need to factor in how attackers are going to behave, so the answers are neither exact nor stable. > If there are better amplification sources, there will be much fewer attacks using public CoAP servers. > But once these go away, CoAP server suddenly seem interesting again. > So the fixes in other protocols and implementations are our enemy here= =E2=80=A6 For the future there may be several ways to go. Amplification attacks: AFAIK requires address spoofing and that seems to get harder. One way is to try to give guidance to use "plain" CoAP in a saver way, the other is to give the guidance to use CoAP over DTLS, which reduces such amplification as well. I'm unfortunately not common with OSCORE, so I don't know, if that changes something in that scope or not. Attacks by "captured" devices: Such attacks don't require spoofing, but the protection against capturing a device have a larger scope than just the protocols. What is required according the protocols, is to harden the implementations. FMPOV, it's again a difference, to focus on CoAP or DTLS. AFAIK, hardening DTLS makes progress, seems that many researches have put an eye on it. At least the open source project received a lot of input to improve (e.g. californium, tinydtls, pion/dtls). In the past years I missed some guidance about protecting the "systems under attack". Years ago, the major general recommendation seems to have been "block UDP at all at the very first firewall". That obviously doesn't work for CoAP over UDP or DTLS. In the scope of Eclipse/Californium I added therefore instruction to use firewall rules for DTLS (see https://github.com/eclipse/californium/wiki/DTLS-1.2-based-firewall), if that is possible (obvious, that mostly isn't possible at the very first firewall, but later on the own machines). For plain CoAP, I don't see, how malicious traffic can be filtered out at that level. (And yes, that protects only from non-DTLS traffic, as explained in the wiki.) For me the question is therefore more: Stick to try to give guidance to use plain CoAP, or start to stronger recommend DTLS. > It seems you have data, and that is what I=E2=80=99d like to collect in= the T2TRG effort, together with what went wrong in the specific instances. I setup some time ago https://github.com/eclipse/californium/wiki and update the information there. best regards Achim Kraus Am 02.02.22 um 18:57 schrieb Carsten Bormann: > Just picking one paragraph here: > >> On 2022-02-02, at 18:52, Achim Kraus wrote: >> >> I'm not sure, if there is a common, realistic understanding of the >> "nature" of such an attack. At least I have much more questions than >> answers. E.g. is amplification only relevant above some threshold? >> Means, if a request with 80 bytes is used and the response has 160, is >> that relevant? Or must the response be above 400 bytes in order to get >> relevant? So, in theory there may be a lot of rules, but I'm afraid, >> that these rules stay theoretical, complicated, and maybe practically w= rong. > > That is exactly the issue that makes this so hard. > We need to factor in how attackers are going to behave, so the answers a= re neither exact nor stable. > If there are better amplification sources, there will be much fewer atta= cks using public CoAP servers. > But once these go away, CoAP server suddenly seem interesting again. > So the fixes in other protocols and implementations are our enemy here= =E2=80=A6 > > It seems you have data, and that is what I=E2=80=99d like to collect in = the T2TRG effort, together with what went wrong in the specific instances. > > Then we need to forge these data into an assessment of the situation and= finally rules with a bit harder boundaries than the ones we already have.= That will be the BCP. > > Gr=C3=BC=C3=9Fe, Carsten > From nobody Fri Feb 4 06:57:39 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B83D3A1585 for ; Fri, 4 Feb 2022 06:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 LICGcr7a4tSg for ; Fri, 4 Feb 2022 06:57:29 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on061b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::61b]) (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 A4B9E3A1592 for ; Fri, 4 Feb 2022 06:57:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EJQ4DEwGYnVqsKfIR4m7px5kxAJruqC+K5gY6ewAh4//EdkuqbiyMWov6wFSL/a4J6/DFzRWVjFtdPgizn+aZ3LK3aki3cHaPOUMENNDAr769y5d1SQ95D3fzbX9DsKlC7gcX6kWmMw0kMEIaFEqyWGb6bVcu400L+fS4vA7tevU/J36oRXew/K+DbB0XJMv2jdYzsxn+zgWCwFF3M7MMXs4tMS7rfXINiQzBfwnHQAbQkviZU/2V9B3IQF9be26iE5SOLhiJ2srvjo7v0VCCVATx0grXmOQPA7iD0YWGWuEW6kyik+psGVEghtXDJge0CCtV3VgwlxVQpl5rkEamQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3jqQFmr+N6FWdlr5t2nu4bfvrvFuAMpNXpoD2L3K4y8=; b=PkGlQDPDbcVFTqXvTcFywV74d+OeVYly+0Ky9yWKWBIKMqfCsCXLjinHF5GUEwI7s8hav11ydLg4xYRH16DD9tSVj6HM85mQfn6qzHV6bun5SCMtmHv5AAnFRpm3iqwXKJtJIS+/T3aru+wp/RXEtTNgeolDYxDXwoT3/xRgUi1XZ4VYKYOJQf2V+eqZ88z8GbLItJdVGD4FMp+IZS6dTpjZli6MHIJRJlZqmrZPr3M4DnWI+Nqj28GlKdJFN73E+O5DDHjAO1mPHEINkXQ2QmbVJuHj8c/PNgG0yTNSUw/AAcrWhfk0xAzipQ5cXcz8Z5VbHN8Qkx8rpsQ6tj99ZA== 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=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3jqQFmr+N6FWdlr5t2nu4bfvrvFuAMpNXpoD2L3K4y8=; b=AEz5/Clgk6SiyonZuwLVx0pZMyG9CdnJ3QqmexOtNqtmfRJwVTB4btLb2OBbAbL/gU+4QeGhBP6oE03JiNdPiftEYRrGZVneZUOMW6edmu/2BvinFnRV4A5C1siHqylrHMnintj0+zKxg/9Al4GW39rRVtmit5/nYQX/G8rKoAU= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by AM6PR07MB5976.eurprd07.prod.outlook.com (2603:10a6:20b:95::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.11; Fri, 4 Feb 2022 14:57:21 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b462:480e:b937:c62c]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b462:480e:b937:c62c%7]) with mapi id 15.20.4951.014; Fri, 4 Feb 2022 14:57:20 +0000 From: John Mattsson To: "core@ietf.org" , "t2trg@irtf.org" Thread-Topic: New Version Notification for draft-mattsson-core-coap-attacks-03.txt Thread-Index: AQHYGdZ0OaKH4cWPbUaWA1d8QDaoZqyDet2M Date: Fri, 4 Feb 2022 14:57:20 +0000 Message-ID: References: <164398617596.31288.8774123387724574069@ietfa.amsl.com> In-Reply-To: <164398617596.31288.8774123387724574069@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d2e21852-eb0d-49d8-00fe-08d9e7eea531 x-ms-traffictypediagnostic: AM6PR07MB5976:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: J4X5/hWFq4Goca/AnnEdjl5+cx/pRqUHvBDYx8D8eVZidE0hEqaFX1Sn1NYtmbPotRrDkX6Z0oqHKOoebej5Ykv9BNeeop4cMJA8i6sWpV7kFCJz8vcchvY/TjKIjVCg7MLS/xdWp3UoNoWVRQ1K9nxYX+s79rw7wTm48CVCTAffSIXcC9rgAngT/e7/U8Z6EPvgOe10TbS+BTQV9Z2awa5SJzpgU2tvGQqDP1wmTBLC6wO0cEByJB8+vIfG3TVTn1c+rMrVBMiwY41D9f9sh7QCgAd9aofXTzbj94c/TRB7sPtLvrRWvtje/1gIgytU+8TR1hbnWEqySSk3uTvyafhZAaRLH48MQFBDg7P+JB8P2t5xjTP4ZG2Z+uZaqpNjw0a7ZxdPfRUQ7QI4pcGJNmQhWhY5evfFIY9gE1bKtqaqAEPmjgW0T6tz7f1t59y+Gf82aikVMGQZJuae036oT3Jv1O93gdQS7Og+O7lMgSuBIaEw5zCnbfxxKXJjqOj1Hc3M1MaifHjU74VVDjYAKS/9/nCr80GnE5ZSSBlQHJvuhsHh+WPKQtXo+nVgTVM3cK86vxbTgdfNW1KVxszluLE8Wd/W3ZYzrFHtcCkUkx3+eEd9YWuMAYt7zUC0yQ46MHApr9AhfdqmLAzuXHXiM4AUygxdFumHIAz7xDyAA6XiftuGDVp+Zq+9L+n/4kq/vYIn8KMTD3FcB3zX/fNWj14+dLhKDtyimzg+Y0A0stXPTOH6J3vr8m7dnkiU7oU+5C81gO9XQzqULMvMG/47hl5WiZP2XaLPj0cHCPiJ/x7h9dipFOqo57RcfBcV5yqPK5zAuw+mLj+in9KjKtqjziOe+p4MJERHfrytwhZp+QbswMySyH+N7Bi681igAU8g x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(508600001)(966005)(66574015)(316002)(110136005)(33656002)(71200400001)(21615005)(38100700002)(38070700005)(122000001)(44832011)(186003)(5660300002)(66556008)(82960400001)(7696005)(66476007)(26005)(166002)(52536014)(8936002)(15650500001)(55016003)(66446008)(83380400001)(53546011)(6506007)(91956017)(66946007)(86362001)(8676002)(2906002)(9686003)(76116006)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?qwi577+GrvtgcTgyhqqdowgm8NYGBlF6Y9ZxW7Iq53mGdD40OrZdP2NJ10?= =?iso-8859-1?Q?OS8AitXivDF5VElWwOT7yIVgI24VWqjedEnXu3HrUdjd8iTVJfg+qZyW19?= =?iso-8859-1?Q?hBbK7L5k7vpccX/FMyePYXTgH+FW1icrgiS9dYvgyu5iFbkxgnzyaZUnCq?= =?iso-8859-1?Q?AoH2YXq560QfRECfBqbiWgqA17W0GaGPU4tas0zi9psgw7w4+dXmZATJ7k?= =?iso-8859-1?Q?Un0XZAmQ4OjqHz1r7VWjUi0TiZOeIcTO0feE8mbNAiRL8jTLeP7DdWxN5f?= =?iso-8859-1?Q?+spVLleOllXg9Sz86ycbN/er+utA5kqyhu9EdW1cGnrkCxBL2kF2ow14V1?= =?iso-8859-1?Q?bXCiy7TNguZBCE5Hr0d6L3mAh/Qwl74g/0Q80A3FH2uyB25a2CVHxOQNZY?= =?iso-8859-1?Q?Weg8xy63GoD69ueWHt57t/FTddiRJn+cf0v7hoXyFXghYzIuJx4OSKQg5M?= =?iso-8859-1?Q?awrASakzre8triabwcCjdGXO5SINe4ZCj4i/Xs/IAnlmFq3cL/as3bSh3u?= =?iso-8859-1?Q?bZFd4Xy6VJcbJ1oWgKjjZtrFGXeqRYB7c/e8x2gWlHTDdEZ9jbx4/iUtpt?= =?iso-8859-1?Q?9F6XW/sKvgF6UTjgZJtiBc9F0fT/u53t7wV7jkr/0N+MnNYttvQk87kPeA?= =?iso-8859-1?Q?U/JjP5xpNGRlcsbKasHyGGRqpWOCMOSxGHwGgx2Uz22uvERJSPQFG47jan?= =?iso-8859-1?Q?k57hUSLEFVOH7vY1NMsyMTgDBEUGPGsIbbPHkGSSme95hVpO4myi3gJ1b0?= =?iso-8859-1?Q?xAePWToof0TASv1r71ky3zE+pcn9Jnf2d9znZBDBt82MHhk/QxEPK8ZuZF?= =?iso-8859-1?Q?+rW8f/Q+dqqGRLMsaaSp9AZG/9r2XMxs9iHc5uyYMYoMctTLuQIFT8Q+K/?= =?iso-8859-1?Q?BpHpV/zGWth0y5iI+w4c6jur0FeJEH+TSbrF3t2NgqXWNF9zUh/LqUXNSL?= =?iso-8859-1?Q?UOI489Xb1LKiLv/iQ6kV/dVh+Ffj92XrehGNN0SrmtAhMostLo0/rFBSSw?= =?iso-8859-1?Q?G7s0nMDiBhtyDgFpAsqT9jVCS24DIbWbKGxbKYow9KInjMt2ng0MbjyNFD?= =?iso-8859-1?Q?Y8t4tjs51awoB35+MjmESa4s8fFQ/sa898WLTC/0OvLq7Wq4obXbJ7iqUO?= =?iso-8859-1?Q?goTwxD+y5M33RCiLePZgGdcO0zTst9ORDyRrbWNQWTEsQgBW/juNjUUsmq?= =?iso-8859-1?Q?UH9PLr+pbjdruT7PkiO3CviABcb+8/glv4K6gwO5mUSFHXXA4CfRQCgwRy?= =?iso-8859-1?Q?T/aTscqViaEsD5MMh3y6NUf9cNYfMUgrTOr+LNcpLvcCjUKQCLzaK0Af2p?= =?iso-8859-1?Q?t8zMbT4yRrE8Xvxt+J+vTxBmS0yhmTxRwDQYhNmRzRoSVEebtI4jn86QEl?= =?iso-8859-1?Q?nT3HhIQjBOuNfRYH5k75CjWFSXeJZvLG0ZrIvugZx1hYxm+AifgnW1fVEc?= =?iso-8859-1?Q?Tip8kAqJ49cpcSt8CjBUFhBG4dYbVWE/yVMaq+uootmMB2UqyksHgHt6s4?= =?iso-8859-1?Q?4/KLM5as4LNUnbMcRn9K3BgGnx7KU0h5S0TU5eoqwpxaOWAd6k7g672xhh?= =?iso-8859-1?Q?VWEO+GPaWCK0NjzAgnZSGfA3H0YCsmqPwdMwoHZt/ad6JRHYEV1Ak/S5Sg?= =?iso-8859-1?Q?hVVsw75ScGJW7aI8o6UZEDVuhAu4wJ5C68OyfoHhiV6sgShc5mkeo6VW3J?= =?iso-8859-1?Q?CkyUC0hGwKAv01CLWPBnuxfjD2tGEjBOsiUZLvn0CEZFrJkXJ/7ZiyN+UY?= =?iso-8859-1?Q?sdOEdK69KBXMA02aARLfyeBus=3D?= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB3050F68CD5C73FF76170335F89299HE1PR0701MB3050_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d2e21852-eb0d-49d8-00fe-08d9e7eea531 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2022 14:57:20.7914 (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: oQMXPtR5c5urOVb9stjw7weyVsIzr3VbPSlgGeVytYcz2Xv0tZbbQpRR0v+5QXwRWqcIHp73ax7eDf/Q3pdXO3YT4tvtlUu5j5k/OWAeUiQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5976 Archived-At: Subject: [core] FW: New Version Notification for draft-mattsson-core-coap-attacks-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2022 14:57:33 -0000 --_000_HE1PR0701MB3050F68CD5C73FF76170335F89299HE1PR0701MB3050_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As discussed during the CORE interim, the part about amplification attacks = have been removed from this document. The amplification attacks will soon b= e submitted to T2TRG as a new draft. I think it is great if T2TRG starts wo= rking on (D)DoS attacks as part of the suggested SECCORE activity. Two big = enablers for DDoS are devices that are easy to hack and protocols/implement= ations with large amplification factors. A T2TRG activity would help to rai= se awareness, increase understanding, and hopefully suggest mitigations sui= table for constrained devices and networks. Changes in -03 - The section on amplification attacks has been removed. - Merged a PR from Carsten with Nits - Merged a PR from Christian with a new section (2.4.3) describing the at= tack difficulty of the fragment rearrangement attack. This PR was based on = an issue opened by Achim. Cheers, John From: internet-drafts@ietf.org Date: Friday, 4 February 2022 at 15:49 To: Christian Ams=FCss , G=F6ran Selander , John Mattsson , Ch= ristian Amsuess , Francesca Palombini , G=F6ran Selander , John Fornehed , John Mattsson Subject: New Version Notification for draft-mattsson-core-coap-attacks-03.t= xt A new version of I-D, draft-mattsson-core-coap-attacks-03.txt has been successfully submitted by John Preu=DF Mattsson and posted to the IETF repository. Name: draft-mattsson-core-coap-attacks Revision: 03 Title: Attacks on the Constrained Application Protocol (CoAP) Document date: 2022-02-04 Group: Individual Submission Pages: 20 URL: https://www.ietf.org/archive/id/draft-mattsson-core-coap-at= tacks-03.txt Status: https://datatracker.ietf.org/doc/draft-mattsson-core-coap-a= ttacks/ Html: https://www.ietf.org/archive/id/draft-mattsson-core-coap-at= tacks-03.html Htmlized: https://datatracker.ietf.org/doc/html/draft-mattsson-core-c= oap-attacks Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mattsson-core-coa= p-attacks-03 Abstract: Being able to securely read information from sensors, to securely control actuators, and to not enable distributed denial-of-service attacks are essential in a world of connected and networking things interacting with the physical world. This document summarizes a number of known attacks on CoAP and show that just using CoAP with a security protocol like DTLS, TLS, or OSCORE is not enough for secure operation. Several of the discussed attacks can be mitigated with the solutions in draft-ietf-core-echo-request-tag. The IETF Secretariat --_000_HE1PR0701MB3050F68CD5C73FF76170335F89299HE1PR0701MB3050_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

As discussed during the CORE interim<= /span>, = the part about amplification attacks have been removed from this document. The amplification attacks will soo= n be submi= tted to T2TRG as a new draft. I think it is great if T2TRG starts working on (D)DoS attacks as part of the suggeste= d SECCORE activity. Two big enablers for DDoS are devi= ces that are easy to hack and protocols/implementations with large amplific= ation factors. A T2TRG activity would help to raise awareness, increase und= erstanding, and hopefully suggest mitigations suitable for constrained devices and networks.

 

Changes in -03

  - The section on amplification attacks has been removed.

  - Merged a PR from Carsten with Nits

  - Merged a PR from Christian with a new section (2.4.3) desc= ribing the attack difficulty of the fragment rearrangement attack. This PR = was based on an issue opened by Achim.

 

Cheers,

John

 

From: internet-drafts@ietf.org <internet-dr= afts@ietf.org>
Date: Friday, 4 February 2022 at 15:49
To: Christian Ams=FCss <c.amsuess@energyharvesting.at>, G=F6ra= n Selander <goran.selander@ericsson.com>, John Mattsson <john.matt= sson@ericsson.com>, Christian Amsuess <c.amsuess@energyharvesting.at&= gt;, Francesca Palombini <francesca.palombini@ericsson.com>, G=F6ran Selander <goran.selander@ericsson.com>, John Fornehed <jo= hn.fornehed@ericsson.com>, John Mattsson <john.mattsson@ericsson.com&= gt;
Subject: New Version Notification for draft-mattsson-core-coap-attac= ks-03.txt


A new version of I-D, draft-mattsson-core-coap-attacks-03.txt
has been successfully submitted by John Preu=DF Mattsson and posted to the<= br> IETF repository.

Name:           draft-mat= tsson-core-coap-attacks
Revision:       03
Title:          Attacks on the= Constrained Application Protocol (CoAP)
Document date:  2022-02-04
Group:          Individual Sub= mission
Pages:          20
URL:            https://www.ietf.org/archive/id/draft-mattsson-core-coap-attacks-03.txt=
Status:         https://datatracker.ietf.org/doc/draft-mattsson-core-coap-attacks/
Html:           https://www.ietf.org/archive/id/draft-mattsson-core-coap-attacks-03.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mattsson-core-coap-attacks<= br> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-mattsson-core-coap-attacks-03=

Abstract:
   Being able to securely read information from sensors, to secur= ely
   control actuators, and to not enable distributed denial-of-ser= vice
   attacks are essential in a world of connected and networking t= hings
   interacting with the physical world.  This document summa= rizes a
   number of known attacks on CoAP and show that just using CoAP = with a
   security protocol like DTLS, TLS, or OSCORE is not enough for = secure
   operation.  Several of the discussed attacks can be mitig= ated with
   the solutions in draft-ietf-core-echo-request-tag.

            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


The IETF Secretariat

--_000_HE1PR0701MB3050F68CD5C73FF76170335F89299HE1PR0701MB3050_-- From nobody Wed Feb 9 01:17:13 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A423A0C2D for ; Wed, 9 Feb 2022 01:17:11 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8Dh8T04HrTQ for ; Wed, 9 Feb 2022 01:17:07 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E530C3A122F for ; Wed, 9 Feb 2022 01:17:06 -0800 (PST) Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JtvPv4CYPz67NNV for ; Wed, 9 Feb 2022 17:16:19 +0800 (CST) Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 9 Feb 2022 10:17:02 +0100 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2308.021; Wed, 9 Feb 2022 10:17:02 +0100 From: Giuseppe Fioccola To: "core@ietf.org" Thread-Topic: New Version Notification for draft-fz-core-coap-pm-01.txt Thread-Index: AQHYHZSWU6s+4rOCik6phhhmLJr1YqyK7nlg Date: Wed, 9 Feb 2022 09:17:02 +0000 Message-ID: References: <164439769614.21882.15007910299358423232@ietfa.amsl.com> In-Reply-To: <164439769614.21882.15007910299358423232@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.220.180] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [core] FW: New Version Notification for draft-fz-core-coap-pm-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2022 09:17:12 -0000 RGVhciBBbGwsDQpXZSBqdXN0IHB1Ymxpc2hlZCBhIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWZ6LWNv cmUtY29hcC1wbSB0byBhZGRyZXNzIHRoZSBjb21tZW50cyByZWNlaXZlZCBhZnRlciB0aGUgbGFz dCBJRVRGLg0KSW4gcGFydGljdWxhciwgd2UgaGF2ZSBpbmNsdWRlZCBhIG5ldyBzZWN0aW9uIG9u ICJBcHBsaWNhdGlvbiBTY2VuYXJpb3MiIHRvIGJldHRlciBkZXNjcmliZSB0aGUgdXNhZ2Ugb2Yg dGhlIE9wdGlvbiBhbmQgd2UgYWxzbyByZXZpc2VkIHRoZSAiU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMiIHNlY3Rpb24uDQoNCldlIGFsd2F5cyB3ZWxjb21lIHlvdXIgcmV2aWV3cyBhbmQgc3VnZ2Vz dGlvbnMNCg0KUmVnYXJkcywNCg0KR2l1c2VwcGUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyA8aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPiANClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgOSwgMjAyMiAxMDowOCBBTQ0KVG86IEZh YmlvIEJ1bGdhcmVsbGEgPGZhYmlvLmJ1bGdhcmVsbGFAZ3Vlc3QudGVsZWNvbWl0YWxpYS5pdD47 IEdpdXNlcHBlIEZpb2Njb2xhIDxnaXVzZXBwZS5maW9jY29sYUBodWF3ZWkuY29tPjsgTWFzc2lt byBOaWxvIDxtYXNzaW1vLm5pbG9AdGVsZWNvbWl0YWxpYS5pdD47IE1hdXJvIENvY2lnbGlvIDxt YXVyby5jb2NpZ2xpb0B0ZWxlY29taXRhbGlhLml0PjsgVGlhbnJhbiBaaG91IDx6aG91dGlhbnJh bkBodWF3ZWkuY29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1mei1jb3JlLWNvYXAtcG0tMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LWZ6LWNvcmUtY29hcC1wbS0wMS50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBHaXVzZXBwZSBGaW9jY29sYSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoN Ck5hbWU6CQlkcmFmdC1mei1jb3JlLWNvYXAtcG0NClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlDb25z dHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgUGVyZm9ybWFuY2UgTWVhc3VyZW1l bnQgT3B0aW9uDQpEb2N1bWVudCBkYXRlOgkyMDIyLTAyLTA5DQpHcm91cDoJCUluZGl2aWR1YWwg U3VibWlzc2lvbg0KUGFnZXM6CQkxMQ0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL2FyY2hpdmUvaWQvZHJhZnQtZnotY29yZS1jb2FwLXBtLTAxLnR4dA0KU3RhdHVzOiAgICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZ6LWNvcmUtY29hcC1w bS8NCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LWZ6LWNvcmUtY29hcC1wbQ0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1mei1jb3JlLWNvYXAtcG0tMDENCg0KQWJzdHJhY3Q6DQog ICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIG1ldGhvZCBmb3IgdGhlIFBlcmZvcm1hbmNlIE1l YXN1cmVtZW50IG9mDQogICB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENv QVApLiAgQSBuZXcgQ29BUCBvcHRpb24gaXMNCiAgIGRlZmluZWQgaW4gb3JkZXIgdG8gZW5hYmxl IG5ldHdvcmsgdGVsZW1ldHJ5IGJvdGggZW5kLXRvLWVuZCBhbmQgb24tDQogICBwYXRoLg0KDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoN Cg== From nobody Wed Feb 9 05:29:25 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A6A3A0819 for ; Wed, 9 Feb 2022 05:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 tu3m2Zv2kFXb for ; Wed, 9 Feb 2022 05:29:12 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0623.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::623]) (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 0BE693A082C for ; Wed, 9 Feb 2022 05:29:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WDoSB1uSmJ1ctAf7nlAx8MVm43Fs4DIQmNiWwAU84bTjUpc2zdf2Ga+BBO25Mkuck7IC2JsqgVJs5a4o5dpmwqWNuO6qLwY3Ka8OCpAm5l+gyO754Be1IuJd65lnWesWNSxvam4vbYGwqXvYe6n8OP+LZR+Lmwri/ki7B7TQ4MDADL+CDOMbGIL+I/PkhbOEbmYdHCIwenKdXawu5GO8IC47e9Pe2477e0b5gjBDMaJa1vST8hzoKQf/4aepGRImUQbqTaihunXU/jU8G+CKYReJQLXfw6UyDJp+/vNXmshw0u+TRd6XWqntBXH6QVk8v3BB7ITveoylYYiVokRyig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NagJLMijnxD512qrtBG7/Dqhw3XZZyLIJxV69bq2oHQ=; b=fErsGUTyDvKC4YRzzkGsGubhV/9FkUh5IbsfACuaiOMi8lvAdecmhOmTm5V7i6d5p7Rkki68MoPb3fzjn26aL/SNjv5leFaFnIC6VBhi4heMCQ4PbEpRGmmDz8D9AofDcZhO/MdLbiAJ/V9/6mIU1QyyBpSkEyZijf7M1PG/8MsfLdHyMYE6FIubqDbXYTjE6yYMCt56jOF4zi+KwHhpBIR42RCsDonU0ZaEN6WBjakeFhEwoB03Q5L77hJPU6cSIUeQd7ADCR0iWSQuDT+FAakxN4/gbiVNlQarDixbD0XY5Brt2kZKmnfL01hPjUpDh6aKF+vuSzlngEEK9j6+PQ== 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=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NagJLMijnxD512qrtBG7/Dqhw3XZZyLIJxV69bq2oHQ=; b=LTRsUpxX9CO9HS3mQx0RCosDcsux6He20FkJEQpnqXPYvWiGWBRSjepzLrbzoBTEi91DlqbmR442icUbafs2YrudLy42PJ+XPJsdnmsHsoMuE97pEvU1YZRzfJ94Kain9S96PVjPGjUZxNcJKOfYZ6tqgln0C4vcFhDDM3THgeQ= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by DB9PR07MB7129.eurprd07.prod.outlook.com (2603:10a6:10:1fa::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.10; Wed, 9 Feb 2022 13:29:03 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b462:480e:b937:c62c]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b462:480e:b937:c62c%7]) with mapi id 15.20.4975.011; Wed, 9 Feb 2022 13:29:03 +0000 From: John Mattsson To: Achim Kraus , Carsten Bormann CC: "t2trg@irtf.org" , "core@ietf.org" Thread-Topic: [core] New Version Notification for draft-mattsson-core-coap-attacks-02.txt Thread-Index: AQHYF0n1JcPl+afQf0+0QyaIhsj8LKx+azISgAHQe4CAABjvRIAABQ6AgAAkrDOAAA5ggIAKtjpQ Date: Wed, 9 Feb 2022 13:29:03 +0000 Message-ID: References: <164370592991.14136.4943780498822971831@ietfa.amsl.com> <5AFB6C76-9C15-4050-B478-711832318342@tzi.org> <9F1343E2-B330-4ED8-8ECB-591A013A51EF@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dcc28908-6513-4097-8f5f-08d9ebd023e7 x-ms-traffictypediagnostic: DB9PR07MB7129:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hNV1vUo69MTxX1KLqDGtbuK/MHdE8mzF7CpRIZWEznKBF1mTABGwaYCv4LhTJnPWslLDRIyJylrBe8kVNNzsbl5QwuF7HebLxHKYBpcQeTF9srsBtG/bZEMX72pjVHFos/o729Wvc7MNqG7h/ev5W6KPXzl4HdH6jx5arNOzcFUQH/3dyd/4EASbJDo1OtsrRXrhHyCdBBUn0gxgI7Zj0amoeG7/PnYGZ/e6MOidl/79Yx1BtC9pGy4D9Rx9S25YdOhHh2z4u3ymeJVAmtINygiPuUR3uDXe+TC2ilCZy6NHAcz9BdwC1rExMQA7cJho7BH11LtMEb1ix5AKtH3eteqgv1mNAgNKCaTVMNhTUPTc8PdgFgiRRkHIFoJMGCT3TyxE8oobZPPNTpBjVtW1vSBDG7GR6yq8pZ7b8DCrBf/JF72xl/7nt0Hx30gIbEuK4keNBv7HzS0m26pgnq9MwwyoN9/X1ZyM3kemAu6QRDh1ap1LwWF0IKOLLW+s2LxXdG8goCnqSu8dfUNlE3cORCg9nJoHh0JkF02cKfJfMVKYUoRu9I49G3Fw+QmhfRR34imvdSrl1uDLCJNlGkvQ3SWR+PfN9Bvj/ToMGsHBjo97oJR/NogpGyU5e/q4X+pbVnX478k5eC6GW4B0Opf1yJ7Tmz8Ndnr5O0oxBjfCaAi7DzwnbTxYf7e8z1OLYzEO//EcJ+Pk/F07cnOqQ6r29zT0Wi6mqvi/M7foetKLKSPXNPbLsROLEkaoIzsCh+8LNrUaIKU7riNNRoL2vHHxhoNaGemoSgP3ar1Yw8K4yuu0j4DErmsROSRH+0D7bgrquJkYVz8LePohW0Fn/E1R4w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(5660300002)(8676002)(122000001)(2906002)(66574015)(76116006)(66946007)(66446008)(66556008)(66476007)(91956017)(64756008)(33656002)(71200400001)(8936002)(44832011)(52536014)(38070700005)(83380400001)(186003)(15650500001)(508600001)(82960400001)(26005)(166002)(38100700002)(4326008)(6506007)(7696005)(53546011)(55016003)(86362001)(9686003)(966005)(316002)(110136005)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?gaRnFZFySOO7+onmFFqcuKlGEosbOloxX8SGDP0ILuPlCNOH3V6fi18qGL?= =?iso-8859-1?Q?ddo9pmVA2jWbq0EeB0T/TLIW5DrWtO0cRA+NhP0RtcamNMSw8X4farq1zQ?= =?iso-8859-1?Q?k8O5EVmyEudQ/UjC7aRsDodZ6IanXB/szYYURYx+ABcTIXAjkcD7w33BUg?= =?iso-8859-1?Q?qTLi6v//TG9XM2SVmtysG1B1iU1qoTLU7Onw9DSgrEemErG/z6YN7dvCZF?= =?iso-8859-1?Q?Arg4gZc9CRpHv42auS4DumrfKsm/VJU6fX36KLbqO2OE9SBdIVlH1KhbxL?= =?iso-8859-1?Q?W8AN1KRIU2BmG7yQt9D+du6HnT4BuaP0KaYIfEKKElp3PwOx27QMA5/7xB?= =?iso-8859-1?Q?u37z1dmUQ0rVWO0gD5HrucksK5Mh5tNH9wKrPT5HqjpOyMoDyOHL1j4rcb?= =?iso-8859-1?Q?fQvZthZ3gsXLj5IskuO/79JDo1elNWfFEwNZiVfXA73XqQCOE4IgcdrjDw?= =?iso-8859-1?Q?YeoFajsk+N301D9wxJQs1aK31zBL9CRtCQbltkatVZLcEvZAK/bA1/u/3p?= =?iso-8859-1?Q?gaJ2wHmeiwyGfWS/Ln/5Q4o+7IBwb4+TmEkgTYMqpbQjGivzKBIDlk0fu+?= =?iso-8859-1?Q?8SnKepGjkr8TqOTGejMeh7JWgd4UFBD6yLHjHWcXICE7nfhQPN4eBQVdiu?= =?iso-8859-1?Q?KJTabASM4UQQJaya/6+RcX1KzyjDEkHFz6Y0ADFgYnsPJ6RZYtStdPeBbR?= =?iso-8859-1?Q?QLgsL/2axwjq+UCqhmK5BS9S+rdwoFDhEgVrL+48ImfAR2n57xq9yoDkiF?= =?iso-8859-1?Q?f9nC7vLfPzp95Hh4I2+F+JNfuPiJDagi6Y5akevUjJsS/i8TJ84WakosKR?= =?iso-8859-1?Q?umjwR/Y7ixw6JONekfBa5fat6ubNe64eyP/L5kMxbJPrldiIsCFqdAwWWf?= =?iso-8859-1?Q?Q0cdC4VhS8DTMW4ibVFsis7XtATvujD4nIIuId49PgqTolgNEia3GoLbNo?= =?iso-8859-1?Q?E0cb1jsaZCaVhPSPDsV+QBvapEa5TrVg9j4W+Xe1MnAg8tfygcunoyCfTM?= =?iso-8859-1?Q?AzjIuzq+2fId6Z4pdfG0Xme0Ubj60Yk4MGZn8tn1TATlYihQ0E+QWOYc3J?= =?iso-8859-1?Q?M/cM6gb8maX/LMTBKOC9tzqevWVD6Nhc2PAeO6HX8EsgrFL3CvPA3NZlLg?= =?iso-8859-1?Q?UZu0382IeGGmzreDC5zhS0l0HTfKtVS4AIZlmUWb4+9j5KzRDVOnAq0sH1?= =?iso-8859-1?Q?VMMbplAbKGzYVLaIA41Yk+4yQSp4nGSGP5pMLYdgqWnuYEYvh8mRtZrEEu?= =?iso-8859-1?Q?2n6oa61PVf4b9S/Ykco2gP8Nqfi6RTFwFTksLsDWDEkV1+USoleCyqgK7q?= =?iso-8859-1?Q?wfa/5IMDfjh1XLtns2UngG+5B54qCNPKSA/e78nZY/d/rK4Wm5VsBELB8f?= =?iso-8859-1?Q?9mnecGZQj/elodsdzkHcTLG5A77dKnUO/r6g4c5nOSVrhHYAW/luC7JgNI?= =?iso-8859-1?Q?DNYlEH4T27Dq2BPZVnmgU4vLRUNu/d2M0THhxHkOg6FbJSGw5KY7Xc+X9Q?= =?iso-8859-1?Q?tP6Arr/oHF6PTStU1NAIpgH5q24QvgYVtyzpXdVl56RzHKkQ+s6xqYhPQZ?= =?iso-8859-1?Q?D3kR52tNELZ8CKmBln/VAPCh7ZubawoMR3cb/ZSE8Rvtu26u7tDl1gVmse?= =?iso-8859-1?Q?u/yhS5DoRjm7Si70FVvARqluth1bXk0CFiwSdxVuGpbYcL3meykE3Qqutp?= =?iso-8859-1?Q?mDbt+F/tnyZErQ3rjNCT9AxRCP3P5EBkATIzMoqjeRjqzBmI8MfMR2x/En?= =?iso-8859-1?Q?peBE7lB0fzxfY+ymCZ5xl1l18=3D?= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB30503EC598B053F7B529C54D892E9HE1PR0701MB3050_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dcc28908-6513-4097-8f5f-08d9ebd023e7 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2022 13:29:03.6645 (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: OKA9STlZDNfBRbUV0b2sCQWfDmak0rqQ5ZH25vgu1ch2Re1d3wwhLzW9hdTMxR281OkXIlfQV+bah9eje87V38IVZsDiAwRNO904x1SWNw8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR07MB7129 Archived-At: Subject: Re: [core] New Version Notification for draft-mattsson-core-coap-attacks-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2022 13:29:17 -0000 --_000_HE1PR0701MB30503EC598B053F7B529C54D892E9HE1PR0701MB3050_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Achim Kraus wrote: >Is there any newer or more concrete information about that then >https://www.netscout.com/blog/asert/coap-attacks-wild ? I know that Achim already saw this info on Github, but It might be interest= ing for the rest of the list as well. Looking for newer information on CoAP amplification attacks I found a repor= t from Radware. One of their figures show that CoAP was behind a significan= t part (around 15% maybe) of global DDoS attacks in Q4 2020 and Q1 2021, bu= t not at all in Q2 and Q3 of 2021. https://www.radware.com/2021q3-ddos-report/ Seems unclear how the attacks was done, why they stopped, and if CoAP DDoS = are likely to come back. Cheers, John From: Achim Kraus Date: Wednesday, 2 February 2022 at 18:52 To: Carsten Bormann , John Mattsson Cc: t2trg@irtf.org , core@ietf.org Subject: Re: [core] New Version Notification for draft-mattsson-core-coap-a= ttacks-02.txt Hi John, Hi Carsten, Hi List, about the amplification attacks: Is there any newer or more concrete information about that then https://www.netscout.com/blog/asert/coap-attacks-wild ? (My impression is, that others mainly refer to the same. You may check my list on https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-313273af-45444555= 5731-f151667455ba3294&q=3D1&e=3Dba594369-81be-478d-ad1c-c54a4aece9d1&u=3Dht= tps%3A%2F%2Fgithub.com%2Feclipse%2Fcalifornium%2Fwiki%2FLinks-to-CoAP-or-DT= LS-1.2-research-information%23security---dtls--coap ). I'm not sure, if there is a common, realistic understanding of the "nature" of such an attack. At least I have much more questions than answers. E.g. is amplification only relevant above some threshold? Means, if a request with 80 bytes is used and the response has 160, is that relevant? Or must the response be above 400 bytes in order to get relevant? So, in theory there may be a lot of rules, but I'm afraid, that these rules stay theoretical, complicated, and maybe practically wrong= . best regards Achim Kraus P.S.: The number of unencrypted coap devices is currently declining. It's now about 270.000 to 330.000. My own scan showed an average response size of 338 bytes, and a median of 143 bytes. https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-313273af-45444555= 5731-6ff451ba6e3cd1ef&q=3D1&e=3Dba594369-81be-478d-ad1c-c54a4aece9d1&u=3Dht= tps%3A%2F%2Fgithub.com%2Feclipse%2Fcalifornium%2Fwiki%2FLinks-to-CoAP-or-DT= LS-1.2-research-information%23research-sites---current-scans Am 02.02.22 um 18:03 schrieb John Mattsson: > Conclusion (at least my understanding) from todays interim: > > Split the current document in two different documents: > > 1. Attacks on CoAP > > 2. Attacks using CoAP (aplification attacks) > > CORE will have an adoption call on the first document. > > We will discuss where to work on the second part. > > Carsten suggested to work on amplification attacks purely in T2TRG. I > think I would be ok with that approach as long as we have a plan for > what to do in the mean time. I think all future IETF document (not only > IoT and not only CoAP) need to have much stricter requirements on > denial-of-service mitigation.If IETF does not have a good DoS hygiene, > likely nobody else will. > > As a security person, I would like to start with hard requirements like > QUIC and then soften the requirements when we have more knowledge, but I > agree that this is problematic for constrained IoT and not optimal at > all. But DoS mitigation do cost, and devices need to take that cost. The > alternative is that somebody else (services and infrastructure) has to > take the cost, which is unacceptable. > > *From: *Carsten Bormann > *Date: *Wednesday, 2 February 2022 at 15:49 > *To: *John Mattsson > *Cc: *core@ietf.org , t2trg@irtf.org > *Subject: *Re: [core] New Version Notification for > draft-mattsson-core-coap-attacks-02.txt > > On 2022-02-02, at 15:43, John Mattsson wrote= : >> >> Publish > > I think we need to discuss what this means. > > In order of effort/time needed: > > 1 Publishing as a BCP > > 2 Publishing as a (WG consensus) informational RFC > > 3 Publishing as an (RG consensus) informational RFC > > 4 Publishing as an (RG-sponsored) informational RFC > > 5 Publishing as an Internet-Draft > > We already have (5); this could be improved by separating the DoS part > (attacking using CoAP) from the attacking CoAP part. > Further improved by adopting (in RG or WG, depending on next step). > > Obviously, we also want to move forward on the attacking CoAP part. > Similar considerations apply, but I think these should be run separately. > > Gr=FC=DFe, Carsten > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --_000_HE1PR0701MB30503EC598B053F7B529C54D892E9HE1PR0701MB3050_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Achim Kra= us wrote:

>Is th= ere any newer or more concrete information about that then

>https= ://www.netscout.com/blog/asert/coap-attacks-wild ?

&nbs= p;

I = know that Achim already saw this info on Gith= ub, but It might be inter= esting for the rest of the list as well.

&nbs= p;

Looking f= or newer information on CoAP amplification attacks I found a report from Ra= dware. One of their figures show that CoAP was behind a significant part (a= round 15% maybe) of global DDoS attacks in Q4 2020 and Q1 2021, but not at all in Q2 and Q3 of 2021.

https://w= ww.radware.com/2021q3-ddos-report/

&nbs= p;

Seems unc= lear how the attacks was done, why they stopped, and if CoAP DDoS are likel= y to come back.

&nbs= p;

Cheers,

John=

&nbs= p;

From: Achim Kraus <achimkraus@gmx.net> Date: Wednesday, 2 February 2022 at 18:52
To: Carsten Bormann <cabo@tzi.org>, John Mattsson <john.mat= tsson@ericsson.com>
Cc: t2trg@irtf.org <t2trg@irtf.org>, core@ietf.org <core@ie= tf.org>
Subject: Re: [core] New Version Notification for draft-mattsson-core= -coap-attacks-02.txt

Hi John,
Hi Carsten,
Hi List,

about the amplification attacks:

Is there any newer or more concrete information about that then
https://w= ww.netscout.com/blog/asert/coap-attacks-wild ?

(My impression is, that others mainly refer to the same.
You may check my list on
https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-313273af-4544455= 55731-f151667455ba3294&q=3D1&e=3Dba594369-81be-478d-ad1c-c54a4aece9= d1&u=3Dhttps%3A%2F%2Fgithub.com%2Feclipse%2Fcalifornium%2Fwiki%2FLinks-= to-CoAP-or-DTLS-1.2-research-information%23security---dtls--coap
).

I'm not sure, if there is a common, realistic understanding of the
"nature" of such an attack. At least I have much more questions t= han
answers. E.g. is amplification only relevant above some threshold?
Means, if a request with 80 bytes is used and the response has 160, is
that relevant? Or must the response be above 400 bytes in order to get
relevant? So, in theory there may be a lot of rules, but I'm afraid,
that these rules stay theoretical, complicated, and maybe practically wrong= .

best regards
Achim Kraus

P.S.:
The number of unencrypted coap devices is currently declining.
It's now about 270.000 to 330.000. My own scan showed
an average response size of 338 bytes, and a median of 143 bytes.

https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-313273a= f-454445555731-6ff451ba6e3cd1ef&q=3D1&e=3Dba594369-81be-478d-ad1c-c= 54a4aece9d1&u=3Dhttps%3A%2F%2Fgithub.com%2Feclipse%2Fcalifornium%2Fwiki= %2FLinks-to-CoAP-or-DTLS-1.2-research-information%23research-sites---curren= t-scans

Am 02.02.22 um 18:03 schrieb John Mattsson:
> Conclusion (at least my understanding) from todays interim:
>
>     Split the current document in two different do= cuments:
>
> 1. Attacks on CoAP
>
> 2. Attacks using CoAP (aplification attacks)
>
> CORE will have an adoption call on the first document.
>
> We will discuss where to work on the second part.
>
> Carsten suggested to work on amplification attacks purely in T2TRG. I<= br> > think I would be ok with that approach as long as we have a plan for > what to do in the mean time. I think all future IETF document (not onl= y
> IoT and not only CoAP) need to have much stricter requirements on
> denial-of-service mitigation.If IETF does not have a good DoS hygiene,=
> likely nobody else will.
>
> As a security person, I would like to start with hard requirements lik= e
> QUIC and then soften the requirements when we have more knowledge, but= I
> agree that this is problematic for constrained IoT and not optimal at<= br> > all. But DoS mitigation do cost, and devices need to take that cost. T= he
> alternative is that somebody else (services and infrastructure) has to=
> take the cost, which is unacceptable.
>
> *From: *Carsten Bormann <cabo@tzi.org>
> *Date: *Wednesday, 2 February 2022 at 15:49
> *To: *John Mattsson <john.mattsson@ericsson.com>
> *Cc: *core@ietf.org <core@ietf.org>, t2trg@irtf.org <t2trg@ir= tf.org>
> *Subject: *Re: [core] New Version Notification for
> draft-mattsson-core-coap-attacks-02.txt
>
> On 2022-02-02, at 15:43, John Mattsson <john.mattsson@ericsson.com&= gt; wrote:
>>
>> Publish
>
> I think we need to discuss what this means.
>
> In order of effort/time needed:
>
> 1 Publishing as a BCP >
> 2 Publishing as a (WG consensus) informational RFC >
> 3 Publishing as an (RG consensus) informational RFC >
> 4 Publishing as an (RG-sponsored) informational RFC >
> 5 Publishing as an Internet-Draft
>
> We already have (5); this could be improved by separating the DoS part=
> (attacking using CoAP) from the attacking CoAP part.
> Further improved by adopting (in RG or WG, depending on next step). >
> Obviously, we also want to move forward on the attacking CoAP part. > Similar considerations apply, but I think these should be run separate= ly.
>
> Gr=FC=DFe, Carsten
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.iet= f.org/mailman/listinfo/core

--_000_HE1PR0701MB30503EC598B053F7B529C54D892E9HE1PR0701MB3050_-- From nobody Fri Feb 18 15:41:40 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63CE3A13A5; Fri, 18 Feb 2022 15:41:14 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 0GcYhwlygO_V; Fri, 18 Feb 2022 15:41:11 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F813A13A3; Fri, 18 Feb 2022 15:41:08 -0800 (PST) Received: from client-0015.vpn.uni-bremen.de (client-0015.vpn.uni-bremen.de [134.102.107.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4K0p9Y6ymhzDCbb; Sat, 19 Feb 2022 00:41:05 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 666920465.195914-c9fda2bea1eb16ac828ae183f222b4d5 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Sat, 19 Feb 2022 00:41:05 +0100 Message-Id: <8441FB7C-7D73-4CB6-9D7A-EB60194309C8@tzi.org> To: ace@ietf.org, "core@ietf.org WG (core@ietf.org)" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF113: DRAFT AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2022 23:41:15 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF113. Remember that there is still quite some potential for changes. The IoT-relevant conflicts that most meet the eye this time are LPWAN/ACE (probably little actual overlap) and DRIP/ROLL/RATS (probably a little more overlap, but not that much). CFRG and ICNRG are the only RGs not on top of IoT meetings (T2TRG, like e.g. CBOR and JSONPATH, decided to go for interims instead). All times are in UTC. Note that the third and fourth weeks in March (W11 =3D pre-IETF week, W12 =3D IETF week) are Weeks of Confusion, where DST has not yet started in Europe but did already start in North America. https://datatracker.ietf.org/meeting/agenda-utc might be handy. Gr=C3=BC=C3=9Fe, Carsten SATURDAY, March 19, 2022 0830-2000 Hackathon - Grand Klimt Hall 1/2 0930-1000 Hackathon Kickoff - Grand Klimt Hall 1/2 SUNDAY, March 20, 2022 0830-1500 Hackathon - Grand Klimt Hall 1/2 (0900-1700 IETF Registration - Park Ensemble) 1300-1500 Hackathon Results Presentations - Grand Klimt Hall 1/2 (1600-1800 Welcome Reception - Grand Park Hall 1/2/3) MONDAY, March 21, 2022 0900-1100 Morning Session I G Park Hall 3 ART dispatch Dispatch WG - Joint with ARTAREA G Park Hall 1 OPS v6ops IPv6 Operations WG G Klimt Hall 2 RTG raw Reliable and Available Wireless WG G Park Hall 2 SEC dance DANE Authentication for Network Clients = Everywhere WG Park Suite 3 SEC *** teep Trusted Execution Environment = Provisioning WG 1200-1300 Afternoon session I Park Suite 8 ART sedate Serialising Extended Data About Times = and Events WG G Park Hall 2 IRTF pearg Privacy Enhancements and Assessments = Research Group Park Suite 3 SEC acme Automated Certificate Management = Environment WG Park Suite 9 SEC *** cose CBOR Object Signing and Encryption WG G Park Hall 3 TSV tsvwg Transport Area Working Group WG 1330-1530 Afternoon Session II G Klimt Hall 2 SEC *** lake Lightweight Authenticated Key Exchange = WG Park Suite 8 SEC oauth Web Authorization Protocol WG G Park Hall 1 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG TUESDAY, March 22, 2022 0900-1100 Morning Session I Park Suite 9 INT 6man IPv6 Maintenance WG G Park Hall 1 RTG can Computing-Aware Networking BOF Park Suite 3 SEC *** rats Remote ATtestation ProcedureS WG G Park Hall 3 TSV quic QUIC WG 1200-1300 Afternoon session I G Park Hall 2 INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG G Park Hall 1 IRTF qirg Quantum Internet Research Group Park Suite 3 SEC *** ace Authentication and Authorization for = Constrained Environments WG Park Suite 8 SEC emu EAP Method Update WG Park Suite 9 TSV tsvarea Transport Area Open Meeting 1330-1530 Afternoon Session II G Park Hall 1 ART httpapi Building Blocks for HTTP APIs WG Park Suite 8 INT intarea Internet Area Working Group WG G Park Hall 2 IRTF irtfopen IRTF Open Meeting Park Suite 9 RTG detnet Deterministic Networking WG G Park Hall 3 SEC secdispatch Security Dispatch WG WEDNESDAY, March 23, 2022 0900-1100 Morning Session I G Klimt Hall 2 ART moq Media Over QUIC BOF Park Suite 8 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Park Suite 9 IRTF maprg Measurement and Analysis for Protocols G Park Hall 2 RTG rtgarea Routing Area Open Meeting G Park Hall 3 SEC tls Transport Layer Security WG 1200-1300 Afternoon session I Park Suite 2 ART mediaman Media Type Maintenance WG G Park Hall 1 INT *** drip Drone Remote ID Protocol WG Park Suite 8 RTG *** roll Routing Over Low power and Lossy = networks WG Park Suite 3 SEC mls Messaging Layer Security WG G Park Hall 3 SEC *** rats Remote ATtestation ProcedureS WG G Park Hall 2 TSV taps Transport Services WG 1330-1530 Afternoon Session II Park Suite 3 RTG bier Bit Indexed Explicit Replication WG 1600-1800 IETF Plenary - Grand Park Hall 1-3 THURSDAY, March 24, 2022 0900-1100 Morning Session I G Park Hall 1 INT savnet Source Address Validation in = Intra-domain and Inter-domain Networks BOF G Park Hall 2 IRTF coinrg Computing in the Network Research Group Park Suite 9 OPS *** iotops IOT Operations WG G Park Hall 3 SEC saag Security Area Open Meeting 1200-1300 Afternoon session I G Park Hall 3 INT madinas MAC Address Device Identification for = Network and Application Services WG G Klimt Hall 2 IRTF panrg Path Aware Networking RG Park Suite 8 RTG rift Routing In Fat Trees WG Park Suite 3 SEC privacypass Privacy Pass WG G Park Hall 2 SEC *** suit Software Updates for Internet of Things = WG 1330-1530 Afternoon Session II G Klimt Hall 2 ART webtrans WebTransport WG G Park Hall 3 IRTF cfrg Crypto Forum Park Suite 2 SEC oauth Web Authorization Protocol WG FRIDAY, March 25, 2022 0900-1100 Morning Session I G Klimt Hall 2 ART *** core Constrained RESTful Environments WG G Park Hall 3 INT add Adaptive DNS Discovery WG G Park Hall 2 SEC gnap Grant Negotiation and Authorization = Protocol WG Park Suite 8 SEC openpgp Open Specification for Pretty Good = Privacy WG 1130-1330 Afternoon Session I Park Suite 3 IRTF icnrg Information-Centric Networking G Klimt Hall 2 OPS anima Autonomic Networking Integrated Model = and Approach WG G Park Hall 3 TSV tsvwg Transport Area Working Group WG (### DST STARTS IN EUROPE ON SUNDAY ###) From nobody Tue Feb 22 10:48:39 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C569C3A12BA for ; Tue, 22 Feb 2022 10:48:36 -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 (1024-bit key) header.d=ri.se 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 6CJb1KyqSZce for ; Tue, 22 Feb 2022 10:48:31 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on0606.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::606]) (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 1FA423A127C for ; Tue, 22 Feb 2022 10:48:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AsQZJX21lfO9E6FjCv8NaALrGAuH+B8EQ17zj5y0fOi+qGasOWEB3NFjdaODhDLvJ7IXh+brZxE6WY2D19vWikbkajHde6rPZeiCKUaP5kDF2d/hAqy5JsfvNTpUn9NDObjVhf115cigknzq9ondDyA5Q8ndS6ybi8ggPswTvEdvoTLZZgwO96rpsM3lKqNUGqqznqd7zOLSvj4ciyx3cKH5nnGoz5M0+0dzf87NtblBkV54ZeNLZYdmGlAxVm88WAts/a52aD6+UTf8tlEhurfb6XP/uFLnS7TsKWhPsIpxmWGzIoXVxKNyfIaEI/KMjygHWC6wymH9wFgdiIJduQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3rVqGmUNaWclNheRnkBUVb7dmHgI3z+wbT++mnfy/DY=; b=HBPqOOQtbfbIs0vqGGrN+nNNQ6+dqfMTwmGz+DxQfoQLmtD1vuEbp76oYirLhbO6CbvnGap1qrg9+VrWnqYksekgEabIo8fscMRYV7hOjqb4FlHRQa+uWOWWx6KiTOQTvi9BDSGaoQIO9o04PZLWh+Y2nfQUvigST/hIoxKchsIRlUhKiD1wqe5ALLr6nSSBUuGXSibWvSq0gdUflkS3uK7eHr5mnjLSE6qbJFvvrD1dC9A/FLSp3kyV6sD6/fwaPqHZpED72QlztgTRMruM+XlpvQwvb6mCU2Nw1cRD4d8Y03B0WZOlMzsUakrGn9b6ggz+E5UettHupFcO+hJ0Tg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3rVqGmUNaWclNheRnkBUVb7dmHgI3z+wbT++mnfy/DY=; b=ReH95/YIFCISxn19i+3knG66FQGdirey7AYefajiai/4wKBPEtSBef2WVu6+50pYxNmxkjOvfW/zLGBH1XAL0PhlhYJ/dwtPYRVb0wswNLG3Hxvk8WVtLNtnGlXAabGlmvP2erUZY/4nCkIHlBXY6anBZsQq1GPEydgXsajK62U= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ri.se; Received: from PR3P189MB1034.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:40::19) by DB9P189MB1691.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:2a7::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.21; Tue, 22 Feb 2022 18:48:25 +0000 Received: from PR3P189MB1034.EURP189.PROD.OUTLOOK.COM ([fe80::49f3:446d:50d3:b2fe]) by PR3P189MB1034.EURP189.PROD.OUTLOOK.COM ([fe80::49f3:446d:50d3:b2fe%5]) with mapi id 15.20.4995.027; Tue, 22 Feb 2022 18:48:25 +0000 Message-ID: Date: Tue, 22 Feb 2022 19:48:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------vLj8xu0KF0Y6YKMFqhpG1QxI" X-ClientProxiedBy: GV3P280CA0095.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:8::6) To PR3P189MB1034.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:40::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 78424b05-e63a-40ad-a09d-08d9f633e821 X-MS-TrafficTypeDiagnostic: DB9P189MB1691:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IZeN7/yftq2jcEepKmjaO6ZFymg1L6pD7oy9KNGP5hWSomoB0bBTxqnLg2S5pf9o+07TIhb/QpIY/8Xd9FiR9h2hbSYNGnLGc94kt9vL4RG5Jr3gYxrh/UfH3v5V+H+hpy/fF8Mn1cwyd1jGmp3Ex4jzV9keIzx3VuoYH6+Ksc8p5o0YXk2jPGw9tKQw6B0vcF08CwJWXysiLqfoaAN0P9t8QXWhkvPnZn9NI4ZBA3s2LnF2ZAbuZvHbGlGVfIL10XkXKHMN/T8UZ5aLiZ0JeBG5W2b3tlkpUl87hI1j9mQQj6mf4bNN0Ph+1PwAfYH+031pHO6ALOQtl8eUK6z/O+IRmxzukZKpUvaOkNeEbNpWeViIr1TPD0AJ2uqHS1ngDsCZA0qhClvbB/pwutHgl8mimkFsgzi0sbzKpiYriPBM1yHZ5yiV96kPWdsuaXcL7Kp+l7axBNWRM1BSytXZ1WcXE2E5VcfL+4Z0f7KCPDIyNJExEzhaR1dMVL12uo2gBJkm3ClCb+iz5kgpYP8wRGdKrsCz3ssu3STpGdkmRJfpsNwtg3hQl2h94AqPpcJY3q+GA+BGwcr70+IWoAdcq5qdoMrBXhiPLrLsF4FJKEM9eOOpx8VXkBVjIb4obNTkeuO5c5zbYO6Oapu+Mz1AtqHF/MWmJx3kI09qWAU4Z6UaTkgQSE5EaVs/M9aUeTYE7wrTUpR2LMmHEusq/xPc0gRM13o6XjgYwUF1zf/e8mfGYbcNfpGhh9TYQAqhC1WLdZ96qqK/83xgJYLIqMJpUb2qN1pzs9AoVVATLUedl1z5AWoogKxsp5K0C3W1E2r/ X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3P189MB1034.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(5660300002)(235185007)(44832011)(2616005)(186003)(66574015)(508600001)(966005)(26005)(38100700002)(2906002)(8936002)(6486002)(86362001)(31696002)(6506007)(6512007)(6666004)(36756003)(33964004)(316002)(31686004)(83380400001)(6916009)(8676002)(66476007)(66946007)(66556008)(21480400003)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SFV0NjZhbU5qNmJMeG1jb1FNK2VXUStTYmg0ZjhYWnJFSzVwRFhXcmZEUlVt?= =?utf-8?B?NjNXUkNYM01DZlNTd2prdTRnV0R0UWdBb1BEZXJDbEhpb2dOTWFVYmpCamdP?= =?utf-8?B?SmVXOXlsTGpCR29FQzlzbGwwV1E3Zm9qY253cnVWdmk1L3pXaDRrTEd0Z1pU?= =?utf-8?B?eVZ4OFRkSEVjZFVUZEIwQzdsN2Y2SnZQa2ltQXlhbk1MOGVPNDR2NGVZY3ha?= =?utf-8?B?dWk0UHVjSFZNZWcwZ2dVeURQWlpDR3BjY0VmZ1krZXVSVndTQjlSdlZnTHR4?= =?utf-8?B?bDFac0doQXM5ekl4a1crM3BGd2cxcC9jYkVCbWd2aVc1MFZ0S2pwOHlBWHE2?= =?utf-8?B?RnRkemV0UlpQOGl1NWs3MzkzM2ZucjFaV0s1dWdlRW0weTliVDlmc0w3YUZy?= =?utf-8?B?Nm9UVmNXME1xWjJqYWtpRC85YldqYnUwSzFGUy91Rk92RmNOb3lhVjZWMVdP?= =?utf-8?B?UTF5dDZRSzBnc2VCY0pzN2ZQSU5qbTRYZzdQendaTzFLdXNFcnY0SHU2THpy?= =?utf-8?B?eC85VnpreG5HdHUvZGpORjdTT0daQnZFRzZobVNrL1h5S1p4eDNGdWx5L1c5?= =?utf-8?B?a1pGL01yNHppS1BFSHlSeitoRytpVHptdCtoeW1kWmwxd2g4bGxxbGVxa0ZR?= =?utf-8?B?VFdTd01LTXNQVThTM05PMG1sQ1FpeWNlRlEzVmJHZHY4alBzcjNxem1nZ1o5?= =?utf-8?B?Q1lxWi9tOFlUcXdIV2dJYjVOWGdRSHRXeTdHcmtsUElhYmx0Qlg0YytCeW1u?= =?utf-8?B?UVdrZ1BpYTA2UU54bDZxN3M0OEZGdmtqVVc0dFBQMlJvSVkydDRSd0lzdEQr?= =?utf-8?B?ZFl1TVRjNzNqZE5iOUVhUVRyUDBGVWt2NzNNTW5VR1hpOUUwcGhzdTZLVnJ2?= =?utf-8?B?cGNpMTBLYXJLc3U1NkxUOXhCRjMxOThXR3lXR215bTcyNEdyOEkybHoyM3Vk?= =?utf-8?B?TWpyaWV4RTFTMW5PYjZ6K25kVVlPcEdrdm5QYzdNcGwwd1o5emthRzE3ZDBZ?= =?utf-8?B?blpKeEZkZEZhZmZiYVpadWxrZ000eko0WGxuSFljTzdSNVFCb041UmRoZ25L?= =?utf-8?B?MGF1QUJUT29ESHJZckNOMXBheVY1RXFVTUZURWkwVk4vcS9rRXRjSi9ld1hm?= =?utf-8?B?VzcvbXgwOHVuYnpnZ0dEZWlleUNCcEpnaUVpM09FQWZpNDRVdjBwWnhGZ0NV?= =?utf-8?B?M2RxeEpxYkJPbUNjODErSGYzMnMrL00ycEEreHdDR1hkSjJRRmtoaHhFZm8v?= =?utf-8?B?L0hzNlp3YS8zR0REUkd3NGtKY2JEalRTZHNtcGxRRDBMbzI2azdWS21BdVR4?= =?utf-8?B?cG5VaDRaQ1dLa2gxZGFjeTFLN05Ib0ZWWWcwcWluY2RuRjhhMDdGWTFjcU9D?= =?utf-8?B?RGk0T1pjb3hpYzhsUy9Ua1Z3TG81SmVrcnZjLzFra3R5UkdtbzVuMTIwQmxz?= =?utf-8?B?QUc1QlBONndkeG04TlBKdDJiT0VHMzdjNHR5YWhYWTQ3KzdPZy92bnhpQWxD?= =?utf-8?B?bHZsbDR3TjJJbXd2dTdvdGlwcy9ieS80WnZCTmhqWU1HU0dpWk1CdWtsWDMz?= =?utf-8?B?TGhwTGpxMXpSOFpId3lmQ2RyYnpaSHVKbDNxMUhFRW15NHVJdmVEdFVIZG8v?= =?utf-8?B?d3BOTTNyZnBsM1ozVGdEYURiR0hIZ2lZRzlSTXQ5VWNCdDlFcWhvRFRFek5r?= =?utf-8?B?cTJqSW1yVWk0UzBYRU1BVGVxS3JYbFZUYzRzbG5vVzQveERwM1NydUl4cy94?= =?utf-8?B?S1RsZklHZVFad0g5RlhJNDFZc2loWk1YQXNpVXRHb2wvN3NFd3NBTWo4WGxC?= =?utf-8?B?dXJwUjFIV1V5MnNrK1hGQTBteFZ6VkM4WVMxbUtmVThVWkRta2tBdXBydUlI?= =?utf-8?B?K21SZUpRTWdoUlViT2FvdnZnTzZ6V2Ryd2FaVTlxQUZyYndHZExBSDl1dTVU?= =?utf-8?B?OXFPS084Nk5zaDRSYTY0K3F3ckYyaXQyaEFua3RvUW53dnVHeUhZcmY5dkYx?= =?utf-8?B?WFlMY05JUDkzQ21VSUMyWEJlODI0Q1BFMW5CeXBJS1VBR2pQNWwxWjR4WW5P?= =?utf-8?B?RUthaGFOQ0VSMzVMNzB1cmdWek1wWFlrQkQxK2hrbFFvUzlFUllUb2U1a295?= =?utf-8?B?RnNzUjMwMlNkL1N6dzVVaXAzNXRraFhsK0tWYVljd1lVdGVHRzNseG9YTkJx?= =?utf-8?Q?LCeHvFNmIbN6GvABAC+Q5To=3D?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 78424b05-e63a-40ad-a09d-08d9f633e821 X-MS-Exchange-CrossTenant-AuthSource: PR3P189MB1034.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2022 18:48:25.1658 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: EWbPNfZYgLajwYE9xnzubzZADOk1rx1yZXiL3Cejoc+B4L/kF68QceFx/A+jph8kI7i5r45t9iS0RLzTM9zjdw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P189MB1691 Archived-At: Subject: [core] CoRE WG Virtual Interim 2022-02-24 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2022 18:48:37 -0000 --------------vLj8xu0KF0Y6YKMFqhpG1QxI Content-Type: multipart/mixed; boundary="------------XCFuUsbRslbydyEKjzFCzkH9"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: [core] CoRE WG Virtual Interim 2022-02-24 --------------XCFuUsbRslbydyEKjzFCzkH9 Content-Type: multipart/mixed; boundary="------------ZhMtZb2LuJ0Fn06f0DuFOI0S" --------------ZhMtZb2LuJ0Fn06f0DuFOI0S Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkp1c3QgYSByZW1pbmRlciB0aGF0IHdlIHdpbGwgaGF2ZSBhIHZpcnR1 YWwgaW50ZXJpbSBtZWV0aW5nIG9uIFRodXJzZGF5LCANCkZlYnJ1YXJ5IDI0dGggYXQgMTU6 MDAgVVRDLiBUaGUgYWdlbmRhIGlzIGF2YWlsYWJsZSBhdCBbMV0uDQoNClRoZSBtZWV0aW5n IHdpbGwgYmUgb24gTWVldGVjaG8gWzJdIGFuZCBtaW51dGVzIHdpbGwgYmUgdGFrZW4gYXQg WzNdLg0KDQpCZXN0LA0KTWFyY28gYW5kIEphaW1lDQoNCg0KWzFdIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMjItY29yZS0wMy9zZXNzaW9uL2Nv cmUNCg0KWzJdIA0KaHR0cHM6Ly9tZWV0aW5ncy5jb25mLm1lZXRlY2hvLmNvbS9pbnRlcmlt Lz9zaG9ydD1kY2E3Njc3YS1hN2U0LTRmNjMtODEyYS0xOWI5YTA0MWM5NTgNCg0KWzNdIGh0 dHBzOi8vbm90ZXMuaWV0Zi5vcmcvbm90ZXMtaWV0Zi1pbnRlcmltLTIwMjItY29yZS0wMy1j b3JlDQoNCi0tIA0KTWFyY28gVGlsb2NhDQpQaC5ELiwgU2VuaW9yIFJlc2VhcmNoZXINCg0K RGl2aXNpb246IERpZ2l0YWwgU3lzdGVtDQpEZXBhcnRtZW50OiBDb21wdXRlciBTY2llbmNl DQpVbml0OiBDeWJlcnNlY3VyaXR5DQoNClJJU0UgUmVzZWFyY2ggSW5zdGl0dXRlcyBvZiBT d2VkZW4NCmh0dHBzOi8vd3d3LnJpLnNlDQoNClBob25lOiArNDYgKDApNzAgNjAgNDYgNTAx DQpJc2Fmam9yZHNnYXRhbiAyMiAvIEtpc3RhZ8OlbmdlbiAxNg0KU0UtMTY0IDQwIEtpc3Rh IChTd2VkZW4pDQoNCg== --------------ZhMtZb2LuJ0Fn06f0DuFOI0S Content-Type: application/pgp-keys; name="OpenPGP_0xEE2664B40E58DA43.asc" Content-Disposition: attachment; filename="OpenPGP_0xEE2664B40E58DA43.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLN R8ZhDz6ZaRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD +QBdf29pQadrVZAt0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGN dsY6kPSVzMRyedX7ArLXyF+0Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZX kLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+NrSetJlljT0QOXrXMGh98GLfNnLAl6gJ ryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEBAAHNJ01hcmNvIFRpbG9jYSA8 bWFyY28udGlsb2NhODRAZ21haWwuY29tPsLAewQTAQIAJQIbAwYLCQgHAwIGFQgC CQoLBBYCAwECHgECF4AFAlSNerkCGQEACgkQ7iZktA5Y2kMiuwgAt/bVZKqD92JN WDTX6h1MUsgejwj4RXs6UYqFdWW/4nw4mFHzYS+gBjOQAWCBhzVZLOk6gKcRZ/s8 6ncVygiDUh9fbSDTcuzOp2qgu9nsc8sEsYp1hwmiIEbI6FHPtyeQQNilsfU8+VHX 2C9yQtMK/OXlf5qNkJMj9k55u+e1ELQ2sjUXkMB4MxMhmi/3P3hMz9PDcB66BtQc DFYkx5PIaz/izCST0o28AJq0dionJpPsQ+hFOIAkJi6aCAt3xQf0KnXlAczWxCD3 J3XTFK4MES/b3n3oc2GJY8I+tsfT5jpNsWhfWGBkMaQSKZ939D4oFAhAq3gnNRgZ szJeTvsMvcLAeAQTAQIAIgUCVI15FQIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgEC F4AACgkQ7iZktA5Y2kNZdgf/drEFkXWpz9pPm0/ZwNNfXzHkpGLqcfPlvQaSNFFb oHwJaeKZ6s3dCGpzDlV6bLrRM9LN/sgNRT0eNiElJHtKDW/fqvzrHl3LCsDKed4L K4Gg2mE0nvWvTno9Nyza8TatJm1+V2S7MbDgSE/F26QK2VL9Y/ur5BHgUI34mUar 4iE1Aq7nsFbN6NEvamyQPWlkN+rCjtnT0+NLGb5VnDVKAHSgiYgGQeDvlisWb9Nt sxzXf1qge3tlCufadSWXyqa4oOq4hEcD3GBUQVuGfBNa7r0mqHzVZf0qd+Kxzs6D p9LxTGp7aSjiXN6cBoapz7lSP0wXOgSzIJ1X2UtVssKv28LBYgQTAQoADAUCVZFC zwWDB4YfgAAKCRBo+Jp/4mFufTrAEACwA4G0VlNs1JOAMgIOfE96v1lVsJiI9qod 5Njc1jlXqItPKDXzvmTJACy7JfA2UbRbwkym7eCc94jkQU6XdTzv8Qf6rpbVZhzF 9tNL38mzm8emh5vV3XDy8arElEP7bE9Jfgm23Lm9OEwubbtjLYf0z7poncThsYUu aEexnxUVF/PXNMIlVBXil/27HkhuWKhpJQU7A35YiJz+lalfGS+9OSv9nJD9mdoT Nk4eSG2sfYKRKs6rmN3X+J9ZITs9Hnpncgu3coayZaL69iicZ4ge1KXACiGG0zpK 666d5ByWgWU7PRqiFIkXwHDW1esZ/QHIJFIXN9zpCD5KaSctvj+tFPNTz2+quiVS nWWQFv/92zRTS4SJgxXP6I3nTasuC6KJy+JnMNfzOVpj05Ef1lXuncc4kLCqd2As 1S6e/OC5Mdo5jQhe0Ozju5IwhRCoqKe1huSj4mbpaTvCjKyh67zVsJR/xDHFDzgt doCsRRQQxWME8+V95FqsleNd1QfEU/jM+HS4JWTDwFs+f1kHzzwhDHWs73M0/jvs 8mUGlfRwSQVDfN6ygbuCn/i2Lvvtc2RWbxWGJVekG8x2rFxUOQ7B2DqmxBrRX3GL okNJ7eWrLNLlYXGA7ptoGWLKQ1FcNNIgapKbxd0s5+s3ql7EaGViJ84ozNX5q52b RceaSihi4s0cTWFyY28gVGlsb2NhIDxtYXJjb0BzaWNzLnNlPsLAeAQTAQIAIgUC VI16cwIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ7iZktA5Y2kNxXggA hFyfi+VlqgIj5a54npaUoREoQ5Tj8gzUPmqOXddo0q9f1cQn/+ehKpbb3TDVzO35 HBXZvuFGn5DHBUYhqBFWTx+H5zHgGBRhF0imQ9Yi/gHe2StgrSIa5528iV2g47Oy DDlSCoCWEM4WwWkJqv9CP2J53Gb63UOPuq5j+BF9wtDs6M6YAs9GdHIDhvUJWGDh OZevyp/DWE5d3LCI+HJIajDjhJK02kVg47aBusW40mGXmjWmtJXP+QtZRfSaabFx CVE3APBn+P4zuyb+mk1gwkN51OiFuYQr1ig3M55kaoGbrs57fVuGtaC9DSc1vgai cJQrYpCbOrbR/yZAedz3xcLBYgQTAQoADAUCVZFCzgWDB4YfgAAKCRBo+Jp/4mFu fWd/D/9PO2eZHdU0Rxr4f0EmNqhMnA6KKIo141DQnpQNqHs0RUgDlDUN1qHjgv1U xu3gbtJoQ4PbT9rJan4Oem7/NJQxU6tsa/dFjDyn9txVGppd12pVFcnGRcDNhLDz ALgZN1ABxfpOh4hQy79qn69Stn0GsSnK6gEq/+3+KROA0ZKEDWcE2rVEzw4UEv37 BUaVnBnHYvNQRQVY8hc43qi3WWUhM3Ot0Z+peAV7D3Y5ZkaSLN6kFoZPZFhrf0fh lLx0ajFIIRDQ8R8ThXXcRopWhw+ifUFdtXoW0goWPFqOkgJw1HYNbYjT4G4DvUAY t5ueCOP6MNXEkDS4r1Hz5JDemtee+FIoaIWbma+ccL3gceoQXwvMtNu1MYFN/n13 YYlqwg9AyIkobG56OeW4o9qqkNjb3GlX+cw6f4uf7l29IF7i3jOFh4GXlYoevYiw 9EpnqLWkWgm5KbT+J9h/tkgt99GXfGkfLzpyjU563esgxpIwWX586ssWlbJWlAPz Cf3do08MiLWTRVcrY6pXVTGAF/c41uC6520+RFm4ytAfrefNac1+5eZBG5k84sTd V9aamCAWkUIEaNQkTfMB7xSXAlq2T8I+kHJCsLSKXXPFdjMJtVRWSZ/gzaBE7cbE Lu9KaHyVRAxNKSsMInAmn/FsxnW6VFaseoT5OtxTMuAnROjB0M02TWFyY28gVGls b2NhIChtYXJjby50aWxvY2FAcmkuc2UpIDxtYXJjby50aWxvY2FAcmkuc2U+wsB3 BBMBCAAhBQJaQCeQAhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEO4mZLQO WNpDAS8IAIko8kg8YfSgacsljgbUjYOA2LJUq3UfiSRz95PwHP05JsDGBmjcmTLf zZ7gNtprJatBEV6fRotIW7NtTgFfg79hFJoipQ7crBQ07WJMLrk4fPReKsaiE9Q6 xzRIQy2mb7jN9gbsbynfkwrSH2CnCAYwbSPSZlfhEOO7LALzyLVXELAxYZplGVSs 9eQLeeoMNFw+24QamdxaEBVC3Zmp7IhO/0oJSYOe2Zcs97q8Re058j1ncd6p4jw6 QbBemi1WhuAtr+ZWYWPoQAsPOPscLa61+DEQIEl12ZwMieu8aBORm1cRVvItC6Ir bSUmZieY9Y3wNdpVVpDhc/+VdSvOgTPOwE0EVI15FQEIAJaan6TouRjj97Lt4Du6 ZhVzbaLJWoARebLANjMSN7BjBFyNOsf83HUSrCMgO5b4EESgwtFk4cKCaOjodGZY i61xhUK32J6iS6W2Siv0EGhBU+Ij5OnnU6nTaJ+QZysRA1mLurd+Y62EVnBno0md RsDZvJxopnygKW8MJCPoCMTJ0E+dLvdRoSgOyqwZWNnAKF84yDk7IWb3RCOkjDyb S4NVwLMop/GrdP/Pu3JGC5whR7zgTMG64kERISMr+EXSdHYsOHVKEPb0VasVlI1V UJW7VRhksBrJ/ygoocekz7CF+MRg7hewOlXjNDXkD4PXkdGIdHoB1/g8O08zUMLC CCMAEQEAAcLAXwQYAQIACQUCVI15FQIbDAAKCRDuJmS0DljaQ8YTB/9Y2NPLfPvi 8uYfJxWwVdehDxbX7znyZHIB3RrwljNjfEHsJW2ojcfLz3hBzDgfobv30DU4v0HU R4DxiPdo7PQ1tTJ/kZb6Ki2veHz4ogI5hnfj8FBo4vN28M2ZGgYef415POEXt5J6 I8qLaN7H41Wh2GM5UZfDwSFgaR5ku/KccRuiIszhNvI9tVH0ex1WooZVMPEpITed qajeS+1jqzJEUiJTPlbMl9gC6pu3qbdPEMRvywD2nNou6GZ+clFzXYfk1VkRmYT8 SQkVOWQ/jCdnI5J/+vb9V3SIdq4HC/ntyljocUUx7uu8rizswTnNy04SXLkLo0K7 Vlo211S6oNI8 =3DAOQG -----END PGP PUBLIC KEY BLOCK----- --------------ZhMtZb2LuJ0Fn06f0DuFOI0S-- --------------XCFuUsbRslbydyEKjzFCzkH9-- --------------vLj8xu0KF0Y6YKMFqhpG1QxI Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmIVL/cFAwAAAAAACgkQ7iZktA5Y2kNd oAf/SD7AdG+xEi922OsjGdllTLN+tVM4k5jmvlMlmR83cwynhnBVO06H1iFKjCocsE368DUNOkFU PEIkQLnOHNLXz6Bi+ZAjRqU2zenplui1jthMNG5xvKnqJF3D/8xm16M4Iz6P/R8MgsAUaPONHYTJ WyASaFuDLjw/5SDV6uq9HqBoMkGfQN4hwuKT54N2ZpY02r0bkl7qbCK8IOyfjOhm74it9MZtCVBo dsyDsPtllZxjQ/FX8QzArKA2AxKZYz9NNtzXLHyiS2RR1zLuRvJF19kRs5swRPbUjOWMS30rNkNc 9iWeb5KOCaTt8k32C0OeCpDpEJ/cJBFO2A36iGBaTw== =Bcj7 -----END PGP SIGNATURE----- --------------vLj8xu0KF0Y6YKMFqhpG1QxI-- From nobody Thu Feb 24 04:35:08 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBB23A12AB; Thu, 24 Feb 2022 04:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 MS2oncCm_Sj3; Thu, 24 Feb 2022 04:34:44 -0800 (PST) Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (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 AB0FD3A1226; Thu, 24 Feb 2022 04:34:42 -0800 (PST) Received: from poseidon-mailhub.amsuess.com ([IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by smtp.akis.at (8.17.1/8.17.1) with ESMTPS id 21OCYbtj024166 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 24 Feb 2022 13:34:38 +0100 (CET) (envelope-from christian@amsuess.com) X-Authentication-Warning: smtp.akis.at: Host [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd] claimed to be poseidon-mailhub.amsuess.com Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id D0642D0; Thu, 24 Feb 2022 13:34:36 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:c452:7e07:77ef:2350]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9BD64FD; Thu, 24 Feb 2022 13:34:36 +0100 (CET) Received: (nullmailer pid 1425341 invoked by uid 1000); Thu, 24 Feb 2022 12:34:35 -0000 Date: Thu, 24 Feb 2022 13:34:35 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Marco Tiloca Cc: "core@ietf.org WG (core@ietf.org)" Message-ID: References: <3a21a3a2-720c-41d1-1258-9f1eb89be623@ri.se> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ptHJLHv8ueqySavW" Content-Disposition: inline In-Reply-To: <3a21a3a2-720c-41d1-1258-9f1eb89be623@ri.se> Archived-At: Subject: Re: [core] Review of draft-amsuess-core-transport-indication-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 12:34:53 -0000 --ptHJLHv8ueqySavW Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Marco, thanks for the review (and the nudge because it left unprocessed). On Mon, Nov 29, 2021 at 11:29:04PM +0100, Marco Tiloca wrote: > * "unify these addresses" >=20 > =A0=A0 Perhaps you mean "unify the coexisting use of their corresponding > addresses" ? I really mean unification of different addresses (as in "making several concrete instances logically into one"). This is more about what is missing on a high level than about what the document provides. > * "This document provides terminology" >=20 > =A0=A0 Yes, but it provides also enforceable means/approaches, right? :-)= (what > Section 1.2 refers to as "provisions") I consider the terminology the more important aspect, but "terminology and provisions" is what I've changed it to. > [Section 1.1] >=20 > * Please, add the usual disclaimer "Readers are expected to be familiar w= ith > ..." Good point; pulling in 7252 and {6690 or 8288}. > * I wonder if the last paragraph about the Proxy-Uri option fits better w= hen > defining the "same-host proxy" above. That's when I was wondering about > Proxy-Uri as an alternative, just to find it discussed later on. Maybe -- but I liked to have it out of the way quickly. Plus, I don't even want to send people in the way of Proxy-Uri; my hope is that people curious about it find it there anyway, but people who read this initially (and those tend to skip terminology) won't even get the idea that Proxy-Uri might be an option at the point where Proxy-Scheme comes up. > [Section 1.2] >=20 > * Considering the given explanation, perhaps "No Aliasing" should be "No > unintended aliasing" ? The goal is that the mechanism introduces no aliasing (even if the authors would intend to). I'd think of it as a bit of a buzzword: All goals (also optimization) set and label a direction for this document, and may not literally achieve that. ("Optimization" might also be read to "reach an optimum", which would need a metric and depending on that we'd fail that in some metrics when taken literally). > * "This document will not concern itself with changes in transport > availability over time ..." >=20 > =A0=A0 Sure, but are the building blocks defined here in principle usable= for > that purpose? Something along these lines is suggested at the end of the > paragraph. I was thinking "we won't publish a schedule (but you can sure use anything established method of keeping tabs on the resource)". Following this ... mh, Max-Age is orthogonal, so works. Same for Observe, both directly and through RD. Publishing information on pubsub? Why not. Just creating a dynlink from to somewhere else? Same. Thus changed to: | nor in advertising their availability in advance. Hosts whose | transport's availability changes over time can utilize any suitable | mechanism to keep client updated, such as placing a suitable Max-Age | value on their resources or having them observable. > * On the mechanics in the first paragraph: >=20 > =A0=A0 - Should the device just carry on and do the same thing if it stra= ngely > receives a CoAP-over-X request including Proxy-Scheme:X and where it > recognizes its name in Uri-Host? You mean if it did not explicitly advertise transport X as a proxy? It may, but the client can't expect it to. (Thanks to the criticality of the options, a server that doesn't support that will send a suitable error). This should never occur if the client behaves properly (because it shouldn't just try using arbitrary addresses as a proxy). > =A0=A0 - It can help to expand about returning 5.05, which is the case un= less > the device is also a forward-proxy other than a same-host proxy. I've expanded the code, noted the exception, and generally untangled these sentences. > [Section 2.3] >=20 > * "Links to proxies may be annotated with additional metadata ..." >=20 > =A0=A0 Simply by using (new) target attributes or are there possible diff= erent > means? That is the only annotation link format provides (but I don't want to needlessly reiterate limitations of one way of expressing links). > [Section 3] >=20 > * Perhaps introduce the device name device0815.example.com before the > example begins? >=20 > * In the last paragraph, at least some of the text starting from "A > simplistic client ..." seems to actually refer to the example shown in > Figure 3 of Section 4. Yes I should; held for example update (tracked at ) > * About the OSCORE interaction point: when mentioning the "Section 4.1.3.2 > requirements" of RFC 8613, does it specifically refer to the omission of > Uri-Host and Uri-Port? Would it still be possible to use OSCORE while tak= ing > advantage of a "has-proxy" relation? It is possible to use OSCORE both with has-proxy and has-unique-proxy. What 4.1.3.2 brings to the table is that OSCORE requires already that the Uri-Host, -Port and Proxy-Scheme be ignored after decryption. So it appears that it almost promotes any advertised `has-proxy` relation to `has-unique-proxy` -- but only almost: Neither can the client know that it is not seeing a reverse proxy, nor can it know whether the server may not outright reject requests without the proper scheme/host/port before even entering OSCORE processing. I'm more and more leaning toward answering the question of "whether it's actionable at all" with "no". No harm done, the server may still go for has-unique-proxy like every other one might. > [Nits] Thanks, applied > * Section 6.3, s/In figure Figure/In Figure (Thank you LaTeX...) BR Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --ptHJLHv8ueqySavW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmIXe1cACgkQOY0REtOk veHPkxAAvU5YMFThKM8LHQ1TBTKzcV0KWTNg3pkaQsXPEiffcSPJZ0alyuizyKw4 /2lPxLtBZu20PmOeenDgDHC3qjMZRcJJCxpTo+ySmV9EbfpLJxoq/NSi3qBbxN7P 1WEEkQIqGQCoz/Spn2/CD7BMQk5NGUOftkOTtLOG9XGO9XrelTCakGvhA5NnS9V1 QMi6uAw3y3WYSVMZ2H56THoXh5JoJeiiMq3ldsenrJ4Eap39NoGIv1qiLqqouvV/ 6IDtJ+kQixJuEs6tI2eNg+1HFNKtrTrPUZhJfw4BIPXFzMNR9Ke+4bFLSnLsbpDU h06qNLMaBPTOZLLeWO3MQnq6Bnrzqy9I1jN808GqT+kJ5HldVEiVmBnPwEE5Q56Z BvmpAPDyuvePJycFp8VTXU05g8QLQRJ+jmrL1kmTa0yufjmu9czXf73gs4TA7qlV Biz/wfcriS2Hray+4gIZ0jxnBnzNRQl5t7Xri3u/AajR/B4DHzAnn/+NAqH3wPDx uwr8KnR1z5GiCQSbdnMDkCu3li4InpIRM5aN8LUoWC7v6YzKhQPhL5D0dcy1xPgX RkW4jOMRY6gh3fgju/B2PDSIMTYnkT0LV1/HKtfRH+cb2aNaGwxjayyYftIZ89r4 SZHmQCv1/VpuKaPguRF9nvOIT+kqKP4s4QCXtD6bBw4MZW65aEg= =juot -----END PGP SIGNATURE----- --ptHJLHv8ueqySavW-- From nobody Thu Feb 24 06:22:17 2022 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0669B3A0317; Thu, 24 Feb 2022 06:21:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.45.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <164571247896.15824.14539062630458363052@ietfa.amsl.com> Date: Thu, 24 Feb 2022 06:21:19 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-conditional-attributes-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 14:21:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Conditional Attributes for Constrained RESTful Environments Authors : Michael Koster Alan Soloway Bilhanan Silverajan Filename : draft-ietf-core-conditional-attributes-02.txt Pages : 18 Date : 2022-02-24 Abstract: This specification defines Conditional Notification and Control Attributes that work with CoAP Observe (RFC7641). Editor note The git repository for the draft is found at https://github.com/core- wg/conditional-attributes/ The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-conditional-attributes/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-core-conditional-attributes-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-conditional-attributes-02 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Thu Feb 24 06:28:35 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4453A06E7 for ; Thu, 24 Feb 2022 06:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=tuni.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 BVcD1xW8p2B6 for ; Thu, 24 Feb 2022 06:28:30 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on071c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::71c]) (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 2C77E3A0597 for ; Thu, 24 Feb 2022 06:28:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I2lgbV/qI43GGIgpjORUZg8jxPeH0vGQxRvKNhaEEmuT2dTwY4oSe8DfusyV4JxWVqf6Xa0IAphw5PrwyNFzGArp3OQpBJVR+4k3gDu0K3MgvUuMBlpS0fGCgp2gvkybgwEaj5K9nM41Ov53m1AG9XwHlrh56En0UM8Am+mFRJpNo3jlmbs2FqynG4LFCfT1Txal+Cuc1A5DMNftQRUDqA9AjmAuuYBNeLyZ8wkfRfI1+s24Pkkz0n0miFfeG5PxqYc5/pBhx+53MQh+dV6+EhphHzV8nTxivHyF6jDjnOBqTdtGsdK/FS3DtMQcYGFKjP4UOp2AY/Qdf2+1j4x1Gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=f5/lTVPpSj8SkXWwLKmqtLpST4MstBzSXxXRf4KK1+8=; b=Ufc0ckK0Uq2QHGvRIlU2ux5dB/fAbySXwhKooANS43AALsn4P5bWmBrghK7pbMRv2wKvz2PEqCa6aeFTXZx4GEUhGfpUfhB8UXoIX7eDYHqiKCf58ne4FI/0brJyzymsGDj2Gfur78g6ZyOm+O8A3BT+O3dCvytmm85VNPo2o/8M8uLLckhbwZRDGeeUqkO8vbZ0A7Dq5k2Sl9FsIu5a+hH7I4xY4g6Iv5VgaNo5DAfSXFfAq4eq7fMYLjnkW9q53q+Q0MzQfZ4BDfHsZgfum+7pb5q7SUjWsGl/cRq6rVFacxu/7sHWf5TUQv6OEwtSNaoppc08N2t1XJAj9s8Diw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=tuni.fi; dmarc=pass action=none header.from=tuni.fi; dkim=pass header.d=tuni.fi; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuni.onmicrosoft.com; s=selector2-tuni-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f5/lTVPpSj8SkXWwLKmqtLpST4MstBzSXxXRf4KK1+8=; b=YZZgdHfAUyQdh6UPV3TI8xUFHkBXL/oHoRBkIqaQSv9Wq4tgMEn1zzjQENsuQEW9oM3EOzExjN0QCLimp+CqPcW+T4xCpumpIpj0GRjeoeJDh5LpZv59V61y22IW5Ef/Tz9JvFIqLmhF5Vw2qsnPEaAULYkc+wGYa6qWlbKRrw4= Received: from HE1PR0802MB2188.eurprd08.prod.outlook.com (2603:10a6:3:c3::7) by HE1PR0801MB1755.eurprd08.prod.outlook.com (2603:10a6:3:86::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.16; Thu, 24 Feb 2022 14:28:24 +0000 Received: from HE1PR0802MB2188.eurprd08.prod.outlook.com ([fe80::c529:6825:c9cc:ac5e]) by HE1PR0802MB2188.eurprd08.prod.outlook.com ([fe80::c529:6825:c9cc:ac5e%2]) with mapi id 15.20.4995.028; Thu, 24 Feb 2022 14:28:24 +0000 From: "Bilhanan Silverajan (TAU)" To: "core@ietf.org" Thread-Topic: New Version Notification for draft-ietf-core-conditional-attributes-02.txt Thread-Index: AQHYKYnPdiejZmPsdUivvgbyO6Vc0qyi5AGA Date: Thu, 24 Feb 2022 14:28:23 +0000 Message-ID: <19F59A7C-EE1A-437B-AFCF-69AE263A5FF5@tuni.fi> References: <164571247916.15824.4132031303046458977@ietfa.amsl.com> In-Reply-To: <164571247916.15824.4132031303046458977@ietfa.amsl.com> Accept-Language: en-IE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=tuni.fi; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 02010072-8268-4d93-2afd-08d9f7a1ea2b x-ms-traffictypediagnostic: HE1PR0801MB1755:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CPAygkzx8bpEtc0dyJRi2NSfu3xd/5AL+vjz8sKAIDb53g6f0ztBDTBOCAThZ3Ot/EdLGXudVZa+4UX6RPUswW9JWTN9qi/00yGDBTVfjL/pH5mk/8J2H2WUoWkRIlAsqYXFBeWrHgAmLcVGu1CPZUuPosl3NhX48ADFXKEoynzwr2QbdoJdsZLdlv44XS6i2XniQO2iTUN6jIBpqzQXCkXwhTbZT2AMNXDIqUmQqooLJvhvUlo4Yr7gtl4HCYqmNLVymX80XKxNUgmIL4JDx4j0gHFp0yR4bPu3Y3qCgHrIqs+GZb0VrGxgXP2IyLUESxzGvQOrzzXKUgdm9RzgO5k/7dxhG+P2kJ/X1CzVs8e0HCQHCeOu5fIY6/pVC+eKhG+QcQRuzoP4OprjMWwGZC98DHMUIQPE3FBwdFRF7ieBKfjb+38Kq4kJtQEv95Q1b4MoahMow+Qha4+ekoi5pRHJehSSo/wI+726X5AsmYBnuYhNoxpj+UVj7Zt0ZPQp+QaAMuybcVLPIL4YBhla+y5ok1bNtGOMInG94UncSoZ44t7egAiH5cgDGHDBZE4M5J8HJ1phuR5cy/mGf9/53MZKK1YZyPoDPJOnoYeWkyEr3e6qUDGXi0OXrPaL9JL6cC4Q5+YFeqoZi+I9hZrNJM0pn68oueFBhazEM3M3PTdeM3uq3OqSm8oXdBYcVdvhR/0hQXXtppw5o9bRa3bOE5DImsBodxgVLYhS3q4U+icQgS+PEcCG3CjTiDGT0eZdlTlzqbJTtxz+kUUawt3Tqylj8H0ie6wD7tBOmb0l/sIi1H0NuR8fKFMzxEHlXPCI x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0802MB2188.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(66446008)(76116006)(186003)(66556008)(8676002)(64756008)(66574015)(66476007)(5660300002)(8936002)(36756003)(38100700002)(2616005)(33656002)(66946007)(6916009)(316002)(786003)(38070700005)(83380400001)(86362001)(966005)(508600001)(15650500001)(6512007)(6486002)(6506007)(122000001)(2906002)(71200400001)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?aWI1STFITlUwdkxlTmFWRWhhL3FIbGQwbVd2NFFPRG9UQjhodVB4eEg0OUJa?= =?utf-8?B?Z3NlOVdBN3dDWXhhc1hTTkxqTFI2SzQvakRWQ2hNTS9uR3JZd1hqMk9HS1Rp?= =?utf-8?B?WWpNVHo0aGJTN1h3NWFIUW93VytoMk1IZWNVWk42NjJDaDJBV2Rkc29BcUVh?= =?utf-8?B?c0FCSGFZaHB3ZzIyOEx6OW9ickREU3dueUV4TDlGMXRpK2F2dzhldmE2dmQz?= =?utf-8?B?NGdELzZ2ZWQycjdWR3RRV2cxOGx1cUoxTkE3c2MraUp4bWhKdW14bWtXZ0VO?= =?utf-8?B?WGhmQ0FCbTRmUnh3TWFhbEVLNnVmYzlKb2xjUGJIRXh0TnhJRm50LzFTd3Jl?= =?utf-8?B?RGlPQ3FxNG5OdkRQMm1PREVPV3lNTk9QWDRHK2pNcXpRV3NJSHFXM0Q4WW45?= =?utf-8?B?REdwVUJ6TFNVY2k5ZUJrNFI4eUppSFFXOWJmUG1yWGJEMytoMWRnQ3BLZTBI?= =?utf-8?B?bTZRb2pVd0xNWHE3UGZGdkYxOE5uM05LMjJ4ZEZ0aU1rd3IzOFhrWjhDYk9T?= =?utf-8?B?dzFmN0wrRXR4QVVWNkxKZDFFUnI4RHpzRjk4aVFzUjJ0U0l6dDJ1ajZOVmtt?= =?utf-8?B?UDU3dnM5bjg0YlBzNGpjMjVUS2tQZFhRMm9MVlhXSmVKeUVBQ2ltdDVwU0xw?= =?utf-8?B?cjRUYzVseFBUQzB6MkJnaTJjNDRjTWJyVmhqNFQxRUhQVktzaTBrNVA5VThS?= =?utf-8?B?R3dVbXVpVTd1SHFtOURzT2h0VzlMRnVCVWdLYXhaSDJCMmE0bTBjUkZIN1oz?= =?utf-8?B?aUlKSEdRdlI5OVBTR3Vpb2dTZlM4dWgxLzJLSDdlK0Q4cDFOcWM3Sy91b2ZI?= =?utf-8?B?Q3lDU055bjQvOFlLQ0NHakRrNy80MGlkYXM1NGg1bnZDS3N6S1FReHArcDBH?= =?utf-8?B?NkFQbytUL2pGWm9MaE9qb0RIVGxQQWlsTjdKVzVUTHQ0aThVeGNGTWsrWmRO?= =?utf-8?B?eDBpT0l2ZnU4M0psMXRseGZ3Uk5Uc2tINUsxN1B2ZUxZdUJMVkRvK3ZtcXZp?= =?utf-8?B?ekZqOVRSQlBlKzJxd2IzSGtyTXJ1MWtHUFJDai9MWkF4bDVJR3o2dDgxQjRR?= =?utf-8?B?b01GVnNQb293U1paclRhcUlhd2JWZFZRQ091SUJYazdxMVhQQ2pKeHJLcFBY?= =?utf-8?B?TTNYY1Y2OXY2VEdtRjJOWWdxdUhDN2d4cThNNjNBZER5N201OGZrWnlpVG5Q?= =?utf-8?B?YzNKWVJNM0pPQzNjdk5iWXpueDFZSXBVY2R5bkhVZmxDNk0yeXhLaXdkaEFE?= =?utf-8?B?alhvYTN4aElwZy9ySlJGbFBkTFcyQWVrYTMvRXl3azg2RGJCN2xTcTQyYmEz?= =?utf-8?B?TGpDOUx6RzJiNUV5UHV0a1pwU2pVaUY4R0tKZ2VWdjlnWEFvdFg1dWNuNHdN?= =?utf-8?B?N3MzQmZnMWZuU1IwMDJUSHFzOW95T1BqL0hoa3ZlNzRpdHNjTysyb3haY2t3?= =?utf-8?B?NTYyOC9Fdkg0SWFFN3FEY21tSk82VUd3REYvaGZvRkdDSUFxbTBVNFFFOHkz?= =?utf-8?B?SXE1dUdKWUN4NE1xWE9kSk9adWdNbmoxSGJlUkRFcXZmZXUvUTVERDBXVXdQ?= =?utf-8?B?UkgzcG9vbVNHNm5HRUhWNzdNNk55NERpd0tzb0hvdFNPNk5maXVTMmVjTDhJ?= =?utf-8?B?MHhMQnRnWDJ3anFHRmNjOWhiRmJ1VmQybEZ3T2tybUV0Wkxxa011VGdPcmlL?= =?utf-8?B?VVhQOHp3K012c2ZJUDJXdlVWd1pzY2JvV2Z4Q2ZQN0ljNzJUT3RDcXpIV05Q?= =?utf-8?B?YzBzL2FVNVB6Sjc5VUJiNExQMnR3OFplMU92NHppT3A2T0JuR0V0SnFsdHVV?= =?utf-8?B?djMvQVN4cGlkUEtwUXNiT0JwUExuYVhkTlljTXNFTjYyWEdFUm44QWlvYzhF?= =?utf-8?B?L28zTWVwSkFpcjlDSERvRXloQS9LeUpaTW1QK1RzbHJOQUd4aWRTaExzR2Fr?= =?utf-8?B?WXVvT3l2OFdENGFIb0VROW9RWHo0NFpxazBsSVN2MWlxbU5IVFVNK2dwUmRI?= =?utf-8?B?ZjJneXloWTBHaVhuN090eDJVWS9iMFRGSUxlNWcxOVp5dkRCTUZOM0hGWmRu?= =?utf-8?B?VElpRmFtMGwvbmVEVFQzN2FKTlpIeHl3ZVRrdGppa04xUUMzbmlpQ0JKaHpU?= =?utf-8?B?K1BJSFd4R0ZoK3J3ZTdqcStDTlRULzl6OXZrSUZ6YjE4NVpjcTJUZi9PRDR3?= =?utf-8?B?T1dybEtPMVdVR0gzTE9BVnpoSEF3Smxub21mOS8ydTlGbjhCQkx3Z1dHQ2wr?= =?utf-8?B?UnJqRTZMVDl1V1dwSlFUdlNZZ3NzSjVnN2tXRkRraTl3ZUo3WmhWYnRjR0tQ?= =?utf-8?B?MitvcUJlNzFKNEYzZG8yME1ZaHFSMHZDalRwTDNqN0lDd2VHVjZiZmFJWDEw?= =?utf-8?Q?oSG35EokQIJSP8oM=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: tuni.fi X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0802MB2188.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 02010072-8268-4d93-2afd-08d9f7a1ea2b X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2022 14:28:23.9347 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa6944af-cc7c-4cd8-9154-c01132798910 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RFhuRFbT4IQvPyDPtVoIWDgxSX3R01N732JDLrUI4bWRl1KvofoFCbFoarHaRAqlWOfjErDPKMtKEkI221OWhDlOveeKicr4j6WyHwBvNeY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1755 Archived-At: Subject: [core] FW: New Version Notification for draft-ietf-core-conditional-attributes-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 14:28:34 -0000 SGVsbG8gYWxsLA0KDQpUaGUgbGF0ZXN0IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1jb3JlLWNvbmRp dGlvbmFsLWF0dHJpYnV0ZXMgd2FzIGp1c3Qgc3VibWl0dGVkLiBUaGlzIHZlcnNpb24gY29udGFp bnMgc29tZSBjb3JyZWN0aW9ucyBhbmQgY2xhcmlmaWNhdGlvbnMgYXMgZm9sbG93czoNCg0KKiBD bGFyaWZpY2F0aW9ucyBvbiB1c2FnZSBhbmQgdmFsdWUgb2YgdGhlIGJhbmQgcGFyYW1ldGVyIChw cmVzZW5jZSBvZiB0aGUgYmFuZCBwYXJhbWV0ZXIgaXMgZW5vdWdoIHRvIGluZGljYXRlIGEgYmFu ZCwgd2l0aG91dCBuZWVkaW5nIGEgdmFsdWUpDQoqIEltcGxlbWVudGF0aW9uIGNvbnNpZGVyYXRp b25zIGZvciBwcm94aWVzIGFkZGVkIChjbGFyaWZ5IHRoYXQgc2VydmVycyBTSE9VTEQgdXNlIE1h eC1BZ2UgdG8gbWl0aWdhdGUgdGhlIHByZXNlbmNlIG9mIG9uZSBvciBtb3JlIHByb3hpZXMgaW4g dGhlIGNvbW11bmljYXRpb24gcGF0aCkNCiogU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYWRkZWQN CiogSUFOQSBjb25zaWRlcmF0aW9ucyBhZGRlZA0KDQpUaGUgd29yayB3aWxsIGJlIHByZXNlbnRl ZCBpbiB0aGUgdXBjb21pbmcgSW50ZXJpbSBtZWV0aW5nIHNjaGVkdWxlZCB0b2RheSwgd2hlcmUg SSB3b3VsZCBwcm9wb3NlIHRoZSBkcmFmdCBpcyByZWFkeSBmb3IgV0dMQy4NCg0KQmVzdCByZWdh cmRzLA0KQmlsbA0KDQoNCu+7vyJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQoNCiAgICBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtaWV0Zi1jb3JlLWNvbmRpdGlvbmFsLWF0dHJpYnV0ZXMtMDIudHh0DQogICAgaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCaWxoYW5hbiBTaWx2ZXJhamFuIGFuZCBwb3N0ZWQg dG8gdGhlDQogICAgSUVURiByZXBvc2l0b3J5Lg0KDQogICAgTmFtZToJCWRyYWZ0LWlldGYtY29y ZS1jb25kaXRpb25hbC1hdHRyaWJ1dGVzDQogICAgUmV2aXNpb246CTAyDQogICAgVGl0bGU6CQlD b25kaXRpb25hbCBBdHRyaWJ1dGVzIGZvciBDb25zdHJhaW5lZCBSRVNUZnVsIEVudmlyb25tZW50 cw0KICAgIERvY3VtZW50IGRhdGU6CTIwMjItMDItMjQNCiAgICBHcm91cDoJCWNvcmUNCiAgICBQ YWdlczoJCTE4DQogICAgVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hp dmUvaWQvZHJhZnQtaWV0Zi1jb3JlLWNvbmRpdGlvbmFsLWF0dHJpYnV0ZXMtMDIudHh0DQogICAg U3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtY29yZS1jb25kaXRpb25hbC1hdHRyaWJ1dGVzLw0KICAgIEh0bWxpemVkOiAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtY29yZS1jb25kaXRp b25hbC1hdHRyaWJ1dGVzDQogICAgRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNvcmUtY29uZGl0aW9uYWwtYXR0cmlidXRlcy0wMg0K DQogICAgQWJzdHJhY3Q6DQogICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgQ29uZGl0 aW9uYWwgTm90aWZpY2F0aW9uIGFuZCBDb250cm9sDQogICAgICAgQXR0cmlidXRlcyB0aGF0IHdv cmsgd2l0aCBDb0FQIE9ic2VydmUgKFJGQzc2NDEpLg0KDQogICAgRWRpdG9yIG5vdGUNCg0KICAg ICAgIFRoZSBnaXQgcmVwb3NpdG9yeSBmb3IgdGhlIGRyYWZ0IGlzIGZvdW5kIGF0IGh0dHBzOi8v Z2l0aHViLmNvbS9jb3JlLQ0KICAgICAgIHdnL2NvbmRpdGlvbmFsLWF0dHJpYnV0ZXMvDQoNCg0K DQoNCiAgICBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0K From nobody Thu Feb 24 08:21:45 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1E53A0B32 for ; Thu, 24 Feb 2022 08:21:43 -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, RCVD_IN_DNSWL_BLOCKED=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=ri.se 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 gv0CBhNsgGM9 for ; Thu, 24 Feb 2022 08:21:38 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on061d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::61d]) (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 E09853A0B3D for ; Thu, 24 Feb 2022 08:21:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n2TCrBKUwQuxFL+bHbFycw3P7PYaYcmDVIkqynj20frZqPB/gpmOdYo2ahTAAVYtHqRtyaPv3uR9nTCI2NDkTNi8l0cIx26rSQiU2dcPkg5VUM2MzAPMEsDa+a8oTDDP0b1bzu6OUfpwZ4fasR5whnhjg1Btkv/hwKPbFVkugb3XXXgfD8qNDZWvnWU+IDSZXK+skV+AiDWV0cWfEi/9NXxlL2Dh7POtneG4FP6Kmki/+eeEyevZQvX+wWcMjt6CROVH4FmE8vJ904Z/NUROEJ1/a8/QxmCo80DPuFALnSuRk8QU1ux+0z6a5GwMr8rZKCsluGh3pIH263In46rc2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gqhpKQrYKGSHMGsCGU3T7fXb/21GazpuKf/ZpsdaBmk=; b=YOGOeRojJRKrvu1YDcy5I7dLITrnGHFxGp7srcuCTIwJPGBAtefrNCBA1pELjU7Wy3nEhHXjS4ssOz4MZTAwmIW+m3/JorwHVukoISjJCdPpL+hzv7x6QwyeqEdWi4eOOAWyJTMcgfDEEbcKeIjydodtP9KRDM7iriY5JlZ9dGnDYqg2wa+zO8tvU+g1zDaeTzd4EGo/vwdU0e6IECQtJJ6i7oZ2D3aA0oep23ALJ+sjrtjeBG0Zg6DawYQU801yhOxugqaq5pH8kXrIKVSVbWkAJVWxas2Y9IKyLqOQmN7aywOYnHVFK31skyqq5xuVbhJo8BcHaSyRQghS/8wwoQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gqhpKQrYKGSHMGsCGU3T7fXb/21GazpuKf/ZpsdaBmk=; b=IPAyAj/BArqpnPvZcNzJlfgVG3HTuASndQRHcAImljwi9eZXAy84EqzGIavtD/08rlZaSbsSsCz6MhVloPKWPlWf/AFS1EntiRnec+QqUQIjLOwPjUTYQ/kHAiNYosLh55k+ktpWj/HmMiceGoprgBUSFWvXjA5unuWTuRbGtag= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0982.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:166::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.24; Thu, 24 Feb 2022 16:21:31 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::8548:6918:4d2d:e57a]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::8548:6918:4d2d:e57a%4]) with mapi id 15.20.5017.022; Thu, 24 Feb 2022 16:21:31 +0000 Message-ID: Date: Thu, 24 Feb 2022 17:21:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------bBHnA1RfleWVg00i02lybFlT" X-ClientProxiedBy: GV3P280CA0109.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:8::12) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 08cf8327-f764-4aba-24f6-08d9f7b1b762 X-MS-TrafficTypeDiagnostic: DB8P189MB0982:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3Y43Fj2iy8ryEIca2VRdZ4BtE2EaJ/YFapOZpn5dQiqoQ/Hoz3tpx2AUZQyZtCi1oue2WdO9ugo5goEmKSmNcoHTDNyfXrO9cAQrAPnkVoOTQ3i4BV5fVlEzYFt0cQdf5IktdTTMQQNul3dLEdUXpEuQunnaNfgm2JC3L3+GruCBQ+UCm1YlB8F3qMTnf4CG9ngiCPnC5bYYSEDp7mUC5i33l92bBoneTNfvrvhft2GXoN0Eao8WpCtrrNfohO5KP2Gj+K/98pDh2NsXRVfetF7wqhZMC8S6fs73L2S8dAsV9yczuQBqNFK+TkZQfoLNV+/iv0SP+/T2iaNVbZhDxKO/iQY7eU+zPfhjpnh8UUh/khz/3PQ6uhACeYsj9olbC+7g8aILck25lMSy1YCJZYTNrDDAnsdby45md2gbQFVFE/1uFqI3XSzVQDnduD3/f3pToXf61X7s2a2apZ9v+XzFsEDY1ahDy7pAMRfzNjqNlOSXO+lpiO0Qit2UYG2yGdnO76nBGdjJktdC64EBYk3SYxwSAbZhZ8SHX2MFp49Tj2vcECNBVycF7MDg+4PwRPORi64Lr/GWpWKO/D13/G6GcSP+Zjnezb9qYSeDa9SpClnF39N1n3d3eiyOhTaWsIDNZYZvT7Xq4N7YCatGJ8P4E9zFUxQWYbiIzNf966xlAl3IRtRkMrsYace40FJNrYzjAIZ57tS7hqzVuW/JscSv8ox426fupbAg617etvrnepDu7NIDsrBLsqQEdWvZaWAdU+Tc76VluW9EgkTr9H4di7zPVaqPxjVoyfbHXNE1WARC2JvX4nf7M96rrdu6 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(66946007)(31686004)(83380400001)(36756003)(6506007)(2906002)(33964004)(21480400003)(66476007)(8676002)(66556008)(5660300002)(508600001)(44832011)(38100700002)(6916009)(235185007)(8936002)(316002)(2616005)(186003)(26005)(6512007)(6486002)(86362001)(966005)(31696002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MS85Z1lyTFdLdU5LM3h5cGpCWWhycDIzUUVDMmVBUlExbUFNTjczc1ppbzlN?= =?utf-8?B?MW1ZSmIvTmdqaVBOUHFxb1RDSkM2UjZ3bDczMVMxODNmVHQrSWg3TFEwUG45?= =?utf-8?B?UnFXbjlCSTNWbXJhMUwwbVAzdW1TVlluRTIwV0tDZ3dZNThkNWxsTGM3RVpG?= =?utf-8?B?N1dJNlk4WGFyeDgwT3h6TEMwb0JReXdLN1Q2bkh2b3V5WkRRNWZjbmVMNmNn?= =?utf-8?B?cXByTjliK2ZHaG9kcm5rTWE4WFdORUF1QWtjeVVLS2VDZHkwRUhyTGtlN2Nq?= =?utf-8?B?bm5uYXM0SkxtQ2xPZTBtR04venkvWVNGZzlMcWVTbVJpS2xPN3JNNjZmZFpJ?= =?utf-8?B?VGxydjQzS3dRSzR6UFppNlF0UU5DcEU4KzNhRFMwVk1lcGxFa1c4bSt3WHJt?= =?utf-8?B?bjBHMmZJcE8rK1VKUkVObTV5S2g3cjBtbVJVeFAzVGEzS3VwWkdxRzZqNGZY?= =?utf-8?B?a3dyUzkyYUIzYkF1QnpTUTY1TlpIRCsvTjlMdTBLZVJQYWRQUkxkcDkzUCs1?= =?utf-8?B?czN1L0FaT3pQMWpuTElhbDJSc0tkV2Y4Zjh5N2gvcmF3bUNlclQ5bWtQZGZM?= =?utf-8?B?QzZZWDI1cFlFTjBnY0NwL0Z6blFoTHk5L3BtZzFWZzJxVlpiL09oNTQrdSsv?= =?utf-8?B?SW9mMEx2ZUJWcHg3TnRuclZnVHNFRzk5T2dqQ1YvTWxESFVUdnFVcVEwV256?= =?utf-8?B?WDAya3NyRE9sbStyeXlGVWxqbFpSTUVvZ29HWTNYNmgwcno2SVZTVlI5Q29j?= =?utf-8?B?MzcxaDZUanZBdzhCLytYRG5KM3JRbmNoajFWNkNMYlhVYmFnNWhNV0xzWUE4?= =?utf-8?B?V2Z5dlVVT0lFVW9VTUJsbW1UZUIwaUNCSGM4MWhaUUlOQkRYWHhTVmRvT2Jz?= =?utf-8?B?dnJMb2U2b2phejR0bWNHeVZnQkM5eFdGL2lmS0t0VmtnaFExNUpJVmw5TjJQ?= =?utf-8?B?OFVaSzJwUnNMU2FZYTBSRnNZNnkzRzFJN2gxUHF1SXZqOGlJTklqZFVZSGs5?= =?utf-8?B?L3N3aktKb0xoZkFUNjMwTUd1aHJLMGJheDVQU1VEYk56R01MbjlVMjdXSFN1?= =?utf-8?B?NmJiNHhjRGpySkRPc0tnUThBN0VZVFphM0tHbERxS0VVNVlPSnhyRnRpQW9k?= =?utf-8?B?ZHBqaVZhRGMyMGN0dkNJLzRaaDBBZnI4ZmtCZVYzOGRnYjE1dUo0WFh5bkxM?= =?utf-8?B?UEV2THZmR3Nhb0h4cnN2VksvUGQrQm1QRzlidWdHWnk3MFZLRmJ5UExGWkpL?= =?utf-8?B?SjZINFU1dFMxUDIrbHFQR0dFRjNwWkZjNDVwUmlmeDVuUGM0N1ZsbUxYY1NG?= =?utf-8?B?QUkzbkJGSEJuRk5MbnM3Q2k1TDVaTzYwSWdVMkZ5Ylg0TGMxaHpIbnhKQ1dl?= =?utf-8?B?RTNrSUk2Mmw1Q0dlN3NBOURPeFBCRmdxM2J4cisyMDhVNVVDZndxTktBNE0r?= =?utf-8?B?RjVZZnpWN1hzMkU1L2hJNEtGUHNVRVRjRk1kMCtiSEFBSG16TnV0NFA2Mzlu?= =?utf-8?B?cHRYWGlUbGk4UTBMcVdjaUhpaTNieWNhZ21GYXloajBMVU5OdFZzdXRYUTZ5?= =?utf-8?B?bkFFMUtnOFJ5c1U5cWwxZTlTOUpoT0xReEpNUmM4ZUVoZ2MwN0htd2VKRXlW?= =?utf-8?B?RGRCTHh0MDdJbXYzczByZXBWZjBJT2R5c2srbWZEWGJLUmhFdm5nMjc0R29X?= =?utf-8?B?Q25RYmhQKzdnV05WeXRsQTJkTSsrQnBHTkVYWTBmbldmbDlidlpkNmNxS2lq?= =?utf-8?B?K3dEeGJxZVVnWE5hVmlXdzladEl2MU5CczQ4VlhiQ3BtTVB4UGNrWUtKU3BH?= =?utf-8?B?UXIyQmF2bzFyeXdqaUowSThtR0VTQ3dNZFZmL254NE5xMndJNEpVdHdSOVlS?= =?utf-8?B?TURndWpSbXdmQnNsUG4wWFZCdVlQUitJdWdmbU54OExjWi8wUm8wYkFQQmZ4?= =?utf-8?B?dWhZUTZBU0RrQVcxOUJYODJ3VlcrSWI0TVRIRmE2K2ZkUjh3QmRiRGNrUWRB?= =?utf-8?B?V09mT1ZQUk8vWVdmd0luVU9PcDRFSWxHYjMrdEVpOXh2Zm5obkFBdVBKcEtI?= =?utf-8?B?L3Q2Z1NPRmtyUFZWYUtWUnR1Rk04ZUtyWXBwbm1XdWF4M1FJcEhoYWxZNDZ2?= =?utf-8?B?Zm1RQnYxMzVmN0hpblpwY1NqSEh5VWtLWnF2M2RqV3p2SXZRY1I2RDkvbWxS?= =?utf-8?Q?eQQlPzaHXqkJd0RJTMKg0Yg=3D?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 08cf8327-f764-4aba-24f6-08d9f7b1b762 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Feb 2022 16:21:31.0226 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: +eg9mSXlTglXPXQFdzujr94HNeaTIGMH2524X0hSW0/t6CPiaD4VZ0MDi/CM69GaD+quXEv5JIWN7LdDd9QSIQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0982 Archived-At: Subject: [core] WG Adoption Call for draft-mattsson-core-coap-attacks X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 16:21:44 -0000 --------------bBHnA1RfleWVg00i02lybFlT Content-Type: multipart/mixed; boundary="------------PZKZb0wovEmiTePGjUv8D9vZ"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: [core] WG Adoption Call for draft-mattsson-core-coap-attacks --------------PZKZb0wovEmiTePGjUv8D9vZ Content-Type: multipart/mixed; boundary="------------FZqwl5gsWdegMK0VCxX0dTYa" --------------FZqwl5gsWdegMK0VCxX0dTYa Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNClRoaXMgbWFpbCBzdGFydHMgYSAyIHdlZWsgV29ya2luZyBHcm91cCBB ZG9wdGlvbiBDYWxsIGZvciANCmRyYWZ0LW1hdHRzc29uLWNvcmUtY29hcC1hdHRhY2tzIFsx XS4NCg0KUGxlYXNlLCBwcm92aWRlIHlvdXIgZmVlZGJhY2sgYnkgV2VkbmVzZGF5LCBNYXJj aCAxMC4NCg0KQmVzdCwNCk1hcmNvIGFuZCBKYWltZQ0KDQpbMV0gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWF0dHNzb24tY29yZS1jb2FwLWF0dGFja3MvDQoN Ci0tIA0KTWFyY28gVGlsb2NhDQpQaC5ELiwgU2VuaW9yIFJlc2VhcmNoZXINCg0KRGl2aXNp b246IERpZ2l0YWwgU3lzdGVtDQpEZXBhcnRtZW50OiBDb21wdXRlciBTY2llbmNlDQpVbml0 OiBDeWJlcnNlY3VyaXR5DQoNClJJU0UgUmVzZWFyY2ggSW5zdGl0dXRlcyBvZiBTd2VkZW4N Cmh0dHBzOi8vd3d3LnJpLnNlDQoNClBob25lOiArNDYgKDApNzAgNjAgNDYgNTAxDQpJc2Fm am9yZHNnYXRhbiAyMiAvIEtpc3RhZ8OlbmdlbiAxNg0KU0UtMTY0IDQwIEtpc3RhIChTd2Vk ZW4pDQoNCg== --------------FZqwl5gsWdegMK0VCxX0dTYa Content-Type: application/pgp-keys; name="OpenPGP_0xEE2664B40E58DA43.asc" Content-Disposition: attachment; filename="OpenPGP_0xEE2664B40E58DA43.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLN R8ZhDz6ZaRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD +QBdf29pQadrVZAt0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGN dsY6kPSVzMRyedX7ArLXyF+0Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZX kLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+NrSetJlljT0QOXrXMGh98GLfNnLAl6gJ ryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEBAAHNJ01hcmNvIFRpbG9jYSA8 bWFyY28udGlsb2NhODRAZ21haWwuY29tPsLAewQTAQIAJQIbAwYLCQgHAwIGFQgC CQoLBBYCAwECHgECF4AFAlSNerkCGQEACgkQ7iZktA5Y2kMiuwgAt/bVZKqD92JN WDTX6h1MUsgejwj4RXs6UYqFdWW/4nw4mFHzYS+gBjOQAWCBhzVZLOk6gKcRZ/s8 6ncVygiDUh9fbSDTcuzOp2qgu9nsc8sEsYp1hwmiIEbI6FHPtyeQQNilsfU8+VHX 2C9yQtMK/OXlf5qNkJMj9k55u+e1ELQ2sjUXkMB4MxMhmi/3P3hMz9PDcB66BtQc DFYkx5PIaz/izCST0o28AJq0dionJpPsQ+hFOIAkJi6aCAt3xQf0KnXlAczWxCD3 J3XTFK4MES/b3n3oc2GJY8I+tsfT5jpNsWhfWGBkMaQSKZ939D4oFAhAq3gnNRgZ szJeTvsMvcLAeAQTAQIAIgUCVI15FQIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgEC F4AACgkQ7iZktA5Y2kNZdgf/drEFkXWpz9pPm0/ZwNNfXzHkpGLqcfPlvQaSNFFb oHwJaeKZ6s3dCGpzDlV6bLrRM9LN/sgNRT0eNiElJHtKDW/fqvzrHl3LCsDKed4L K4Gg2mE0nvWvTno9Nyza8TatJm1+V2S7MbDgSE/F26QK2VL9Y/ur5BHgUI34mUar 4iE1Aq7nsFbN6NEvamyQPWlkN+rCjtnT0+NLGb5VnDVKAHSgiYgGQeDvlisWb9Nt sxzXf1qge3tlCufadSWXyqa4oOq4hEcD3GBUQVuGfBNa7r0mqHzVZf0qd+Kxzs6D p9LxTGp7aSjiXN6cBoapz7lSP0wXOgSzIJ1X2UtVssKv28LBYgQTAQoADAUCVZFC zwWDB4YfgAAKCRBo+Jp/4mFufTrAEACwA4G0VlNs1JOAMgIOfE96v1lVsJiI9qod 5Njc1jlXqItPKDXzvmTJACy7JfA2UbRbwkym7eCc94jkQU6XdTzv8Qf6rpbVZhzF 9tNL38mzm8emh5vV3XDy8arElEP7bE9Jfgm23Lm9OEwubbtjLYf0z7poncThsYUu aEexnxUVF/PXNMIlVBXil/27HkhuWKhpJQU7A35YiJz+lalfGS+9OSv9nJD9mdoT Nk4eSG2sfYKRKs6rmN3X+J9ZITs9Hnpncgu3coayZaL69iicZ4ge1KXACiGG0zpK 666d5ByWgWU7PRqiFIkXwHDW1esZ/QHIJFIXN9zpCD5KaSctvj+tFPNTz2+quiVS nWWQFv/92zRTS4SJgxXP6I3nTasuC6KJy+JnMNfzOVpj05Ef1lXuncc4kLCqd2As 1S6e/OC5Mdo5jQhe0Ozju5IwhRCoqKe1huSj4mbpaTvCjKyh67zVsJR/xDHFDzgt doCsRRQQxWME8+V95FqsleNd1QfEU/jM+HS4JWTDwFs+f1kHzzwhDHWs73M0/jvs 8mUGlfRwSQVDfN6ygbuCn/i2Lvvtc2RWbxWGJVekG8x2rFxUOQ7B2DqmxBrRX3GL okNJ7eWrLNLlYXGA7ptoGWLKQ1FcNNIgapKbxd0s5+s3ql7EaGViJ84ozNX5q52b RceaSihi4s0cTWFyY28gVGlsb2NhIDxtYXJjb0BzaWNzLnNlPsLAeAQTAQIAIgUC VI16cwIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ7iZktA5Y2kNxXggA hFyfi+VlqgIj5a54npaUoREoQ5Tj8gzUPmqOXddo0q9f1cQn/+ehKpbb3TDVzO35 HBXZvuFGn5DHBUYhqBFWTx+H5zHgGBRhF0imQ9Yi/gHe2StgrSIa5528iV2g47Oy DDlSCoCWEM4WwWkJqv9CP2J53Gb63UOPuq5j+BF9wtDs6M6YAs9GdHIDhvUJWGDh OZevyp/DWE5d3LCI+HJIajDjhJK02kVg47aBusW40mGXmjWmtJXP+QtZRfSaabFx CVE3APBn+P4zuyb+mk1gwkN51OiFuYQr1ig3M55kaoGbrs57fVuGtaC9DSc1vgai cJQrYpCbOrbR/yZAedz3xcLBYgQTAQoADAUCVZFCzgWDB4YfgAAKCRBo+Jp/4mFu fWd/D/9PO2eZHdU0Rxr4f0EmNqhMnA6KKIo141DQnpQNqHs0RUgDlDUN1qHjgv1U xu3gbtJoQ4PbT9rJan4Oem7/NJQxU6tsa/dFjDyn9txVGppd12pVFcnGRcDNhLDz ALgZN1ABxfpOh4hQy79qn69Stn0GsSnK6gEq/+3+KROA0ZKEDWcE2rVEzw4UEv37 BUaVnBnHYvNQRQVY8hc43qi3WWUhM3Ot0Z+peAV7D3Y5ZkaSLN6kFoZPZFhrf0fh lLx0ajFIIRDQ8R8ThXXcRopWhw+ifUFdtXoW0goWPFqOkgJw1HYNbYjT4G4DvUAY t5ueCOP6MNXEkDS4r1Hz5JDemtee+FIoaIWbma+ccL3gceoQXwvMtNu1MYFN/n13 YYlqwg9AyIkobG56OeW4o9qqkNjb3GlX+cw6f4uf7l29IF7i3jOFh4GXlYoevYiw 9EpnqLWkWgm5KbT+J9h/tkgt99GXfGkfLzpyjU563esgxpIwWX586ssWlbJWlAPz Cf3do08MiLWTRVcrY6pXVTGAF/c41uC6520+RFm4ytAfrefNac1+5eZBG5k84sTd V9aamCAWkUIEaNQkTfMB7xSXAlq2T8I+kHJCsLSKXXPFdjMJtVRWSZ/gzaBE7cbE Lu9KaHyVRAxNKSsMInAmn/FsxnW6VFaseoT5OtxTMuAnROjB0M02TWFyY28gVGls b2NhIChtYXJjby50aWxvY2FAcmkuc2UpIDxtYXJjby50aWxvY2FAcmkuc2U+wsB3 BBMBCAAhBQJaQCeQAhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEO4mZLQO WNpDAS8IAIko8kg8YfSgacsljgbUjYOA2LJUq3UfiSRz95PwHP05JsDGBmjcmTLf zZ7gNtprJatBEV6fRotIW7NtTgFfg79hFJoipQ7crBQ07WJMLrk4fPReKsaiE9Q6 xzRIQy2mb7jN9gbsbynfkwrSH2CnCAYwbSPSZlfhEOO7LALzyLVXELAxYZplGVSs 9eQLeeoMNFw+24QamdxaEBVC3Zmp7IhO/0oJSYOe2Zcs97q8Re058j1ncd6p4jw6 QbBemi1WhuAtr+ZWYWPoQAsPOPscLa61+DEQIEl12ZwMieu8aBORm1cRVvItC6Ir bSUmZieY9Y3wNdpVVpDhc/+VdSvOgTPOwE0EVI15FQEIAJaan6TouRjj97Lt4Du6 ZhVzbaLJWoARebLANjMSN7BjBFyNOsf83HUSrCMgO5b4EESgwtFk4cKCaOjodGZY i61xhUK32J6iS6W2Siv0EGhBU+Ij5OnnU6nTaJ+QZysRA1mLurd+Y62EVnBno0md RsDZvJxopnygKW8MJCPoCMTJ0E+dLvdRoSgOyqwZWNnAKF84yDk7IWb3RCOkjDyb S4NVwLMop/GrdP/Pu3JGC5whR7zgTMG64kERISMr+EXSdHYsOHVKEPb0VasVlI1V UJW7VRhksBrJ/ygoocekz7CF+MRg7hewOlXjNDXkD4PXkdGIdHoB1/g8O08zUMLC CCMAEQEAAcLAXwQYAQIACQUCVI15FQIbDAAKCRDuJmS0DljaQ8YTB/9Y2NPLfPvi 8uYfJxWwVdehDxbX7znyZHIB3RrwljNjfEHsJW2ojcfLz3hBzDgfobv30DU4v0HU R4DxiPdo7PQ1tTJ/kZb6Ki2veHz4ogI5hnfj8FBo4vN28M2ZGgYef415POEXt5J6 I8qLaN7H41Wh2GM5UZfDwSFgaR5ku/KccRuiIszhNvI9tVH0ex1WooZVMPEpITed qajeS+1jqzJEUiJTPlbMl9gC6pu3qbdPEMRvywD2nNou6GZ+clFzXYfk1VkRmYT8 SQkVOWQ/jCdnI5J/+vb9V3SIdq4HC/ntyljocUUx7uu8rizswTnNy04SXLkLo0K7 Vlo211S6oNI8 =3DAOQG -----END PGP PUBLIC KEY BLOCK----- --------------FZqwl5gsWdegMK0VCxX0dTYa-- --------------PZKZb0wovEmiTePGjUv8D9vZ-- --------------bBHnA1RfleWVg00i02lybFlT Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmIXsIkFAwAAAAAACgkQ7iZktA5Y2kNK Awf/U1uxXumphf4/GsZkFXx8uZ7YE4fB4ADLIp/v74bAU4VCNtsgtzxcOQ35xnfsNtG6cZE5i8c3 +QSzHDVsAr7PhmpQL4n9Bs0CJpKRprVFLLUyydVQ4+uf4z24LKYlvpY4qe6b3p2HR20l+Ry22aAj vEiy2KoaLwQ+oErmjdGqCvzo5NNY/T3vLCz+NFO29x3Q7df4vpenMMe62Sgy+dtEVZmO9xFjcyGT e4Q1PTYTr7H4sZ2iAMoNxAa+1sd00e3CUjw9eq3TznHQl0hVZAg/AI0g7nyMpzyPkx9ANWwZOEHS cRHwA6la0GqT9wQJ2LW0BnmKgLnygWO82DkFBRUXag== =9khY -----END PGP SIGNATURE----- --------------bBHnA1RfleWVg00i02lybFlT-- From nobody Thu Feb 24 08:29:16 2022 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 912B03A0BC8; Thu, 24 Feb 2022 08:29:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164572015352.14104.2558369378078022100@ietfa.amsl.com> Date: Thu, 24 Feb 2022 08:29:13 -0800 Archived-At: Subject: [core] The CORE WG has placed draft-mattsson-core-coap-attacks in state "Call For Adoption By WG Issued" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 16:29:14 -0000 The CORE WG has placed draft-mattsson-core-coap-attacks in state Call For Adoption By WG Issued (entered by Marco Tiloca) The document is available at https://datatracker.ietf.org/doc/draft-mattsson-core-coap-attacks/ From nobody Thu Feb 24 13:49:28 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E273A0B48 for ; Thu, 24 Feb 2022 13:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.714, 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 (1024-bit key) header.d=fraunhofer.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 lXhLrYonJipu for ; Thu, 24 Feb 2022 13:49:22 -0800 (PST) Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (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 5C8FF3A006A for ; Thu, 24 Feb 2022 13:49:20 -0800 (PST) IronPort-SDR: 09Mb9UthchCvxMTTIHwZ29BM1lwqlCDQAN/a3SYPcJOYml40G8XzqbSg7LZUoHfVvfWXCqeyLG hWMdJOBxG8FsU2kS6smBuKUzkegIjkXMbydnXX/llKXf7IPjvrEXsaUA51V50QeYJcBt5skEjB T5oNENCvjCJ+J6vxOfYRsFmiv++PPAvA+lyoUaMjRG6Xh4Lz44RNWCRRcmw34jZarMAkc5dnuC 9Dw2mXOwpFlMPbLaIpRflE+zUK6vt6rrj3EqOTIFN4ZvOjntImfhLnEb4xhLjqtb//eoGNwDlV CoM= X-IPAS-Result: =?us-ascii?q?A2FsBwA6/Bdi/xoBYJlagQmBWoF6Ln6BVYRVjhWCVC4Dm?= =?us-ascii?q?yyBQoERAxgwDAsBAQEBAQEBAQEIASoLDAQBAQMEhQAChA8mNwYOAQIEAQEBA?= =?us-ascii?q?QMCAwEBAQEFAQEGAQEBAQEBBQQCAoEYhS85DYNTTTsBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAkFHDDIBAQEDAQEbBg8BBQgBASwMD?= =?us-ascii?q?wkCGAICJgICJwslBgEMBgIBAYMAAYJlAz2SPZsSeoExgQGCCAEBBgQEgUtBg?= =?us-ascii?q?n8YXIFbAwYJAYEGLIMOizU3gVVEgTwPgQaBbj6CYwEBA4EjGAEBgziCZZUMZ?= =?us-ascii?q?lNYA3/AdTQHghGBOoE5BguJPJRLBhQug3KMJ4YnNZEhlk8gjHKZOAIEAgQFA?= =?us-ascii?q?g4IgXeCAE0kT4JpURkPjiwWg1CFFIVLdDgCBgEKAQEDCZMLAQE?= IronPort-PHdr: A9a23:+7SV1he/5631Ro5wuFG8z3/flGM/vYqcDmcuAtIPh7FPd/Gl+JLvd Aza6O52hVDEFYPc97pfiuXQvqyhPA5I4ZuIvH0YNpAZURgDhJYamgU6C5uDDkv2ZPfhcy09G pFEU1lot3G2OERYAoDwfVrX92az8XgcABziMwpyKOnvXILf3KyK X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.90,134,1643670000"; d="scan'208";a="39985049" Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Feb 2022 22:49:17 +0100 IronPort-SDR: ybTr29kBlsi19sCS3DgfQtedF+Tedkbl711R93EPeerqYx6BxJaUq7a2l2K0OVzbo06vG8gVG1 CTeYbunzF98DCMvMJs3pgXMO0oE0vu4r4= X-IPAS-Result: =?us-ascii?q?A0C9AgAj/Rdien+zYZlagQkJgVGBUiguflkmVoRUg0sBA?= =?us-ascii?q?YU5hQ9egXYuAzgBmnOBQoERA1QLAQMBAQEBAQgBKgsMBAEBhQcChAwCJjcGD?= =?us-ascii?q?gECBAEBAQEDAgMBAQEBBQEBBQEBAQIBAQUEFAEBDxQHBA4DEBA7Bl4GaIFPg?= =?us-ascii?q?WETCzQNhkMBAQEDAQEQCwYPAQUIAQEUGAwPCQIYAgImAgInCwceBgEMBgIBA?= =?us-ascii?q?R6CYgGCZQMtAQEOkkCPNgGBOgKKH3qBMYEBgggBAQYEBIFLQYJ/GFyBWwMGC?= =?us-ascii?q?QGBBiyDDos1N4FVRIE8D4EGgW4+gmMBAQOBIxgBAYM4gmWVDGZTWAN/wHU0B?= =?us-ascii?q?4IRgTqBOQYLiTyUSwYULoNyjCeGJzWRIZZPIIxymTgCBAIEBQIOAQEGgXeBf?= =?us-ascii?q?00kT4JpTgECAQINAQICAwECAQIJAQECjikWg1CFFIVLQjI4AgYBCgEBAwmTC?= =?us-ascii?q?wEB?= IronPort-PHdr: A9a23:TaIgqxdgWzsXjoRV6zk332E7lGM/vYqcDmcuAtIPh7FPd/Gl+JLvd Aza6O52hVDEFYPc97pfiuXQvqyhPA5I4ZuIvH0YNpAZURgDhJYamgU6C5uDDkv2ZPfhcy09G pFEU1lot3G2OERYAoDwfVrX92az8XgcABziMwpyKOnvXILf3KyK IronPort-Data: A9a23:51Q23qjnnzIN80RWIvEy+XQcX161ExYKZh0ujC45NGQN5FlHY01je htvWWGBOKqMN2SnedAgOo3n9h8BuJ7dm9RnHgdl/CE2F3tjpJueD7x1DKtf0wB+jiHnZBg6h ynLQoCYdKjYdleF/VHwdOSJQUBUjclkfJKlYAL/En03FFcMpBsJ00o5wbZj2NIw2rBVPivU0 T/Mi52HULOa82MsWo4kw/rrRMRH5amaVJsw5zTSVNgT1LPsvyB94KE3ecldG0DFrrx8RYZWc QpjIIaRpQs19z91Yj+sfy2SnkciGtY+NiDW4pZatjTLbhVq/kQPPqgH2PU0SnxorzSRv9tL6 e4dh5CBYAAJMLLdsbFIO/VYO3kW0axu47rbOT6yoceTiUPcembqw/JgAVtwMYBwFuRfWDwVs 61HbmlSP1ba3b3eLLGTEoGAguwjIc/oeokeoHJgyjXLJe0nXdbNWazX499f0joqwMxDdRrbT 5NDNGEzM06RC/FJEg8mN9V5sPfyukjuSDZ0q3TPi/cT0WeGmWSd15C3aYGMIYzbLSlPpW6dr 3jN+CLlAxUdP9XKlWKf8zS3i8fDmCrhU8QTGaG2sPlwjzW7zWsJBTUXWEe15/6jhSaDt8l3c hFPv3tx6PFtpQnyFIa7QRj+qziKpBcBXdpXHeAgrg2AokbJ3+qHLks/cRpAcPwtju4NFQ4m5 3aOv932FBU65dV5Vkmh3ruTqDqzPw0cImkDeTIIQGM5Dz/L/NxbYvXnE48LLUKlsjHmMWypm WHb90DSk51C0Z9Sj81X6Hid22rEm3TfcuIizin6Nl9JAysgOdXgNtPtsAeKqK8ac8CHSx+K+ nYektWY7OcAAIvLmCHlrAQx8FOBuqbt3N702wUH83wdG9KFoCXLkWd4vGkWGauRGpxYEQIFm WeK0e+r2LddPWGxcYh8aJ+rBsIhwMDITIq5C66IN4IWOsYpLGdrGR2Cg2bOgQgBd2Bzy8kC1 WuzK5n1ZZrnIfs2l2XuHbt1PUEDmnpnnjm7qW/HI+SPi+PFPSXFGN/pwXOCY/0l96iErR6d/ dFFLMCK1hNQS+vzfju/zGLgBQ9iEJTPPrin+6R/L7fbSiI/QT1JI6KBkNsJJt0594wIx7ig1 i/mACdwlgGg7UAr3C3QMBiPnpuzBMskxZ/6VARwVWuVN48LOt7+vP9CLMJsJdHKNoVLlJZJc hXMQO3Yatwnd9gN0251gUDVoNMweRK1qxiJOib5MjEzc4Q5GF7S+8OicBHm6S8OCSS6r40yr uT4hA/cRJMCQSVkDdrXMa7+kQnu4CJFwO8iDVHVJtRzeVn39NY4ISLGjsgxf5MGJyLFy2bIz A2RGxoZ+bLArtZtotnEjKyJtamzFO56EhYIFmXX9+/pZzLb4iyt24ZdVuaPcz3HEm/5of3wa eJQxvD6EfsGgFcT79siSek2l/pm6oK29bFAzwliEHHaVHiRC+ttciucwM1ClqxR3bsH6wG4b UK4/IUIM7u+Ps64QkUaIxAob7jY2PwZxmvS4PAyLBmo7SN75uDcA15XIwHKhTxWLP17Koo4x +cmtsMMrQCy00J4PtGDhyFS1mKNMn1ZD/R57M5HWtezh1p50ExGbLzdFjTyvMOFZeJKPxR4O TSTnqfD2+lRyxaQaXY1DnSRj+NRiY5V40ITkQRHdgvMw4WUw6Ztg1tP9HI8CApPxwhB0+V9N 3ItO0AsffeC+DJhhc5iWWGwGlgdVUPDpRGrkwMExD/DUk2ldm3RN2lha+yDy0YUrjBHdT9B8 bDElWvoXF4Gpi0qMvfehKK9l8HecA== IronPort-HdrOrdr: A9a23:DD5sja6NB8xC3hlxVAPXwSmBI+orL9Y04lQ7vn2ZFiY7TiXIra yTdaoguCMc6AxxZJhSo6HnBEDmewKhyXcV2/htAV7GZmfbUQSTXeRfBOfZskbd8mjFh5RgPM RbAtlD4b/LfDpHZK/BiWHSebZQo+VvsprY/ds2p00dMz2CAJsQiDuRZDzra3GeCDM2YabQQ/ Gnl7V6TnebCDwqR/X+IkNAc/nIptXNmp6jSRkaByQ/4A3LqT+z8rb1HzWRwx9bClp0sP0f2F mAtza8yrSosvm9xBOZ/2jP765OkN+k7tdYHsSDhuUcNz2poAe1Y4ZKXaGEoVkO0aqSwWdvtO OJjwYrPsx15X+UVmapoSH10w2l6zoq42+K8y7uvVLT5ejCAB4qActIgoxUNjHD7VA7gd162K VXm0qEqpt+F3r77WvAzumNcysvulu/oHIkn+JWpWdYS5EiZLhYqpFa1F9JEa0HADnx5OkcYa VT5fnnlbdrmG6hHjDkVjEF+q3uYp1zJGbKfqE6gL3a79AM90oJjXfxx6Qk7wM9HdwGOtx5Dt //Q9dVfYF1P78rhJ1GdZU8qOuMexrwqEH3QSuvyWqOLtBzB5uKke+y3IkI X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.90,134,1643670000"; d="scan'208";a="12534729" Received: from 153-97-179-127.vm.c.fraunhofer.de (HELO smtp.exch.fraunhofer.de) ([153.97.179.127]) by mail-mtaKA26.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Feb 2022 22:48:47 +0100 Received: from XCH-HYBRID-03.ads.fraunhofer.de (10.225.9.57) by XCH-HYBRID-03.ads.fraunhofer.de (10.225.9.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.15; Thu, 24 Feb 2022 22:48:47 +0100 Received: from EUR05-VI1-obe.outbound.protection.outlook.com (104.47.17.175) by XCH-HYBRID-03.ads.fraunhofer.de (10.225.9.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.15 via Frontend Transport; Thu, 24 Feb 2022 22:48:46 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V5N2x4srmOBW8YhU2wPiw0LtPEccXf0AMcWZ6cNpY4ECtlioM30b189/q3xS4jD5gW7dpYS4w9YpCLggGrm6tB8jertq8hzXQip/VfnP/omnaVi0rRlA13Ig5cKEZ1RAhyZakd81Y2LvHOnvldCs2YI5B8U8gNn2mx9lgHLs0bB32Nt+xlxov54BC5rwMiC1xqukNWFKPVNbSlSqFMeWv+0yIeCa4W/bejV9wNI9ufcYc+ArLAORKnJmE6VYQjf20V8MFplJ06/x3kZIwhqiTOY3YMOV2J1deJh7NYXv4CpfYW97CzKjnaXtH+IUVEG9yNPG8anMrWI75TJbxImYAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tX7z2d+WmRqU1hZGoj6NGbftuR2Quz+QITcSO0QmfdY=; b=kiFo8LlxpR2uOBc2Xtia6EpahBis9rBiGNlIV6wwB7PEsK87uK6R4ZIGRw65SFl4+Fh/Gzva9O1VJiOmRdwLzomWh/2P5WmpmVo1Rapj6UD94ba57asjczSLCdeSwpPLtq5lDNMTht2Vnzkw5rf8Q/stARr+R6T+/xGymZzzSlOU4uA0NkS4f/HNMX+s7iD3R1LPK12nBShc5BTE2hzD8nrMzTcO0p9Hcl6HDXCfKyiJdbit24r501c6+OR+pmQGggjkeRTN2o5qUwYP7TSlKrzSiXi+SIYgnwDG6OXeqfV/88UCZRBoaaphLp5xyRl6L52VbXgbhbeRBD0wLpcoRQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sit.fraunhofer.de; dmarc=pass action=none header.from=sit.fraunhofer.de; dkim=pass header.d=sit.fraunhofer.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fraunhofer.onmicrosoft.com; s=selector2-fraunhofer-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tX7z2d+WmRqU1hZGoj6NGbftuR2Quz+QITcSO0QmfdY=; b=B2LAfuDTqFdGy8H3JKCE3GbAI7Mh4QPxyeUL/lAve5gAeDiEaW1D+O9oIYeBv8iI+UeBV/fOpIZkGkheHGUt7dNqxXly/JqHtrWRuAFrhNzBRajZWfkSdidQjHKIOAG3+soQPGgQT2aWl1VWOE1AGag6LSWT5V0wofiqDfcY7So= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=sit.fraunhofer.de; Received: from DU2P194MB1709.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:276::9) by AM9P194MB1235.EURP194.PROD.OUTLOOK.COM (2603:10a6:20b:3a9::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.22; Thu, 24 Feb 2022 21:48:46 +0000 Received: from DU2P194MB1709.EURP194.PROD.OUTLOOK.COM ([fe80::ec87:f3dc:70f7:2421]) by DU2P194MB1709.EURP194.PROD.OUTLOOK.COM ([fe80::ec87:f3dc:70f7:2421%5]) with mapi id 15.20.5017.024; Thu, 24 Feb 2022 21:48:45 +0000 Message-ID: <65177b70-da96-46ea-c2e8-5c88dfaa3557@sit.fraunhofer.de> Date: Thu, 24 Feb 2022 22:48:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: Marco Tiloca , "core@ietf.org WG (core@ietf.org)" References: From: Henk Birkholz In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AS9PR06CA0016.eurprd06.prod.outlook.com (2603:10a6:20b:462::23) To DU2P194MB1709.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:276::9) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b543a320-4ef2-4a74-57b2-08d9f7df6ebd X-MS-TrafficTypeDiagnostic: AM9P194MB1235:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: vg5PMBcq1Hzqlwt61HA6GxbQY6t9s3Q9JPI8V1AqqEn3xgit9frxN/DVT9uQcoIKxLdf6ErYAHmOCAb73DkAz2wOhvg1oBlazxqOUTs49gZx6mujLL15wws9pBZxZa+g8EXclHsRIk297vJn9qXuOCLNWJ3E2W/958rBaj/w/mVoe1XOpy0lJmq9PE4frCqKffjxFVpF9DqOLzkp8NV863g1AtuKUC7UktZ+yTYHtViCvmUlIGPIZMffrZzy68vjssIriRXpLwRANolOwv+pZDsdG/+qVGd6aQexs/zY3mmDLUK8lhx7sguM8JV/e8JQ/8SeN7Z/aJP0T/S87RQWjn7wbaZNfPh5zrxMUsN3iGDpUcmNPdIgJ6gE+b1yoskGbQoIc2IfuCoilV4qwIPXMzjj7TjS5dpS2J/Yi0kQ/rT7+DClOmNAvLluTMhpGA76IotNxTq+S574T4ikBNpgGgGpiKe8YtXVNfYTxCN2lP2IiIdFUTWnO8PhCsvA4hJEMVuwtV057uFE/Td02VnJHFcUuXwaFrUwR7Msh5JHRcXhYySheyByyAzKc09b3c9YSBZ58wITl7yLWONMPG5y7bIyR3OW7jvAMx2Hjk9y2BfP5D6gqW41ojf8Tr+KhpXAsV7BSK4qj8IO5sdBfwet1JlekA2JP6YjiCIckJWEhg8Jer3yEbqobHbK/zVEqwKykd1xrVBPi2tG2jGzsjqaQ4Lsa6PFAcCk/g6klNc6R5yI7erFejNcHrTAaEP+Smwf4BsJHdTk+vzw51rjXOwyDcXhqIbNDoc79QbUUpr2vqBAfU1ovRrH1+jjZaOahOT/NYwm7V66urnlTDCmGQnU4Iu0smjTUTCQz7ZYXYzVXP86pTALbwL4bSqAU/7c6ZTTjRVoLI/0L5UYfL1DiJqzxQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU2P194MB1709.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(2616005)(26005)(186003)(66946007)(2906002)(66556008)(110136005)(31696002)(86362001)(66476007)(316002)(8676002)(5660300002)(44832011)(38350700002)(82960400001)(83380400001)(38100700002)(8936002)(6506007)(508600001)(6512007)(31686004)(52116002)(53546011)(6486002)(966005)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VzdKcy85b3A2YzRDNDBGTmhvRFdaNGpIYjdLeVhEU2E0TGJzSytCU1BtbjhP?= =?utf-8?B?cGh1SmNoZXhZellVR3pvZjNoK2R3UTYyUEZJaUVwNWhxVkUwaHFkU0pUNnBp?= =?utf-8?B?YzJ6MGgySFZDV0pwWkJ5YzNJTWxwK3M1dEhnakxiVWw5Vy9pK3ladW8vcTF5?= =?utf-8?B?em0yaVhSNjFRQzE3cno5VlVKZzU0bGs3ZU5RbmRpaUt0YXBQMWJvc2doWk9S?= =?utf-8?B?eUxtdnFaME45aG9UTE11eXpkM0ExWUVFZEpFS1padTlqUE9JcEFRTVlIWFpK?= =?utf-8?B?ZlF5Q3NrSHZqd2NlbTNDYTl3UldxUmZ1YmJDNTAyZHFIMjZxcjNkeTZ3S1Zo?= =?utf-8?B?RlIwQms5Sk13MjE1MHJXcFNiaXFJeGdrSDcvekEydGRtMlcrdmt3SmpBeTRD?= =?utf-8?B?TlRQbDRsMkFQcTRCMVlZQ0FDMklTenhNcXNiZGJZU09zdXc2RDF1bFN2MGZP?= =?utf-8?B?bmRkTEdUZ0xrUWM3M24zdEQwTFZUUDdYbU42K3plOUtuZEZES2gwZ3REUW01?= =?utf-8?B?S25kdVJTYzJlMTlZeEVEMFhhU1NIVjNqUk56OEs5QzVhREhLR2NOVTNiamg3?= =?utf-8?B?RHg4SGF1S3pZVVk1bmN1UGFxd1ZqNXVRTjVIMlY4R2g4NlArUVM1YUVQeDdx?= =?utf-8?B?cFBoaGs3dzlORFFLMG1HeVNUM1Z4M0ltOTVFS3hYNC9NTUl6NHVrc1ZWL1R4?= =?utf-8?B?MjNOekd0cXlXUk9sdHc2NFdQR2ZUVnFKVzVpRnhGdEhpQm9ubGdsaml6STZG?= =?utf-8?B?ekd6K2tXc01ZVVZmNFZDUXg5UnhmVkhxWkxTenprYUN4SFBRS01saWU1REVx?= =?utf-8?B?QkQ0anhKRkd3RW8zNlBpYWxTOFMzRkZORERrSlhQWmxkd3Y0VTgvTHlSUVlS?= =?utf-8?B?UGhGL0RmRURhVCt6a1VVTzJMaGVwdzFacWQrNmdGa2NxL0d1bjlRK25lUi9h?= =?utf-8?B?eDRBZTR4aGRFUVprdzBGK2QyTm9uZ0RaL01LVlpXeXhQZmNYVjgvazE4Vnl0?= =?utf-8?B?b05jcXBTVTZwNStCd2Q1aW5ndXZLME03SzJDMnFhcUNncWx2V0hNYkhTUk1G?= =?utf-8?B?YzFQVXovYkhwYWl5YjlnYUR1WHpsNlF1M2NHbVk5cXdabTlrU2dhRURadW4w?= =?utf-8?B?VzU2bmlSTnpZekhwKyt6WUpMRE9xeFdSKzBvSDJGaTB2UWxSTytGTFFjVnht?= =?utf-8?B?WHNjbXBablNsenpadjZzanRNOHBHSTFCeHVjY2J3YkhCTjdES0JtTW9IdjMv?= =?utf-8?B?eE9sdDdtS3gxOGRTT2ZSR3haUzRGUFRyakxhZjRPL3V4QlpjOGY3b0VCdGJF?= =?utf-8?B?WGdsbVJQQmVHakZJaXgveVMxNzAyZ2tjNlFsd0haSU5KMmVtQzVDdExlcFZT?= =?utf-8?B?UnlCekpEcXJkemdBK3R4TkJXV1kyZG4rcTEvWjRTM2swM0FsR3VUbFNxZW8y?= =?utf-8?B?T1gzdUV3RDVOcFpGL1BRcWVCcEQ1KzZMSURhaUc2ZmY5T2x4V2VYT3NqWG5T?= =?utf-8?B?bC9QcFNJQWhHc3BlRi9WWnFLUG1tWnlkUDRqN1JJNjNFYnlDMjhnTFRjMFFs?= =?utf-8?B?czhYNURDYXErNkxvYm0zWXg0WWZPZUdETTdCY0N1aUZSbFRDU1ZtWjIvbU10?= =?utf-8?B?K0JOcWN2ZkN5UDd6NXVXTHJKdVA4Nkd4K3M2RXpkT0ZadnZHQndBZDFqaWR3?= =?utf-8?B?dUxWOHhXaWdNa1ZLYVdVcVNBd3JqOWhQWTVXV1NBL0NFOC9ySTVud2VaU3B5?= =?utf-8?B?YjNUcm1XdmNXQmFENCt2VmpaVWZjQTNSbFh0M2trVGdBQWx4UHRvZVFFaXlJ?= =?utf-8?B?eW9LMHRwNGdGMUhvMHl2WTJtK21ZVVIwblhZOEl3aWZPTEZPblE4eDQ0U1Va?= =?utf-8?B?cTVSSXIyWVFGc1ZHSlN3ZGVYcVZzbTVrNmo4QnBIQXZIL2FwL0svUi9laUF4?= =?utf-8?B?RlBFRWI1ZmVZNXZua3VGZ05pbGxKTlNuUXVpbG1vZlc3NkoxUnU0Nyt3SzVE?= =?utf-8?B?cUhsdUY3cko3Mm1lanBRVHl6dWFlODB3VUZUTEs0UG5MZ3Y2YlFwb3Bnb1JN?= =?utf-8?B?dEgwSEJYT1hEZUhzK3hwWklqY0ZOYXczc0JFYytpV0R0T1IrSCtobjVubTlm?= =?utf-8?B?OTJ3R2c0NnB3a3QvYlVVaXRLZUozV1B0NndwRDRodHJ6VlBOMnY3VkgxYmY0?= =?utf-8?B?aU9UaG1CNDNINEJGNGc5L1AyeGhCQTk4QjB4TDBPNFB1S0RHRDhlWWUvbEtm?= =?utf-8?Q?cUY7nSuLi/Tm0hsi6XltK5YyXPDHD2GeTzIFPopSbY=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: b543a320-4ef2-4a74-57b2-08d9f7df6ebd X-MS-Exchange-CrossTenant-AuthSource: DU2P194MB1709.EURP194.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Feb 2022 21:48:45.8868 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f930300c-c97d-4019-be03-add650a171c4 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 9mwvbbYaaod9ZYDZmaiA7IDGmVc1ILtxlueu06QnRbAZvNbYB310AKJcBiDpiI2QYnqF9gb3/uTmVe/EB2+CdNpQk1cCL7NgrBz4xuMt7Bs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P194MB1235 X-OriginatorOrg: sit.fraunhofer.de Archived-At: Subject: Re: [core] WG Adoption Call for draft-mattsson-core-coap-attacks X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 21:49:26 -0000 Hi core, in general I am in favor of the topic and I like most of the content and I think it should be a working group item to improve on in the WG context. +1 Having said that, I think you are confusing freshness and recentness, fundamentally. Freshness is not connected to recentness, but they are similar - and that is the tricky part. Something can be fresh after a huge amount of time according to a time-scale (not recent). Something can be stale after a tiny amount of time according to a time-scale (recent). Freshness is a quality of an assertion that expresses that the assertion still reflects the state of its subject, at the time of checking it. Freshness can be very tricky to check. Is that what you want? Probably not. My assumption is what you would want is a response with appropriate recentness (at least that is how I read your text). Viele Grüße, Henk On 24.02.22 17:21, Marco Tiloca wrote: > Dear all, > > This mail starts a 2 week Working Group Adoption Call for > draft-mattsson-core-coap-attacks [1]. > > Please, provide your feedback by Wednesday, March 10. > > Best, > Marco and Jaime > > [1] https://datatracker.ietf.org/doc/draft-mattsson-core-coap-attacks/ > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Feb 24 13:54:06 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F5E3A0B67; Thu, 24 Feb 2022 13:54:03 -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, CTE_8BIT_MISMATCH=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 F5cQKiBU0qZD; Thu, 24 Feb 2022 13:53:59 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16BA3A0B60; Thu, 24 Feb 2022 13:53:58 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 499) id BE806E52EF; Thu, 24 Feb 2022 13:53:58 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, core@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20220224215358.BE806E52EF@rfc-editor.org> Date: Thu, 24 Feb 2022 13:53:58 -0800 (PST) Archived-At: Subject: [core] =?utf-8?q?RFC_9175_on_Constrained_Application_Protocol_?= =?utf-8?q?=28CoAP=29=3A_Echo=2C_Request-Tag=2C_and_Token_Processing?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 21:54:04 -0000 A new Request for Comments is now available in online RFC libraries. RFC 9175 Title: Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing Author: C. Amsüss, J. Preuß Mattsson, G. Selander Status: Standards Track Stream: IETF Date: February 2022 Mailbox: christian@amsuess.com, john.mattsson@ericsson.com, goran.selander@ericsson.com Pages: 27 Updates: RFC 7252 I-D Tag: draft-ietf-core-echo-request-tag-14.txt URL: https://www.rfc-editor.org/info/rfc9175 DOI: 10.17487/RFC9175 This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the following: processing requirements for client Tokens, forbidding non-secure reuse of Tokens to ensure response-to-request binding when CoAP is used with a security protocol, and amplification mitigation (where the use of the Echo option is now recommended). This document is a product of the Constrained RESTful Environments Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Feb 24 23:23:56 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E6E3A011F for ; Thu, 24 Feb 2022 23:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=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 vAaIfE1Se4x9 for ; Thu, 24 Feb 2022 23:23:42 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6F43A0064 for ; Thu, 24 Feb 2022 23:23:37 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr23.francetelecom.fr (ESMTP service) with ESMTPS id 4K4h8R27WSz5w2d; Fri, 25 Feb 2022 08:23:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1645773815; bh=QdKNBbE7uiXhqW29XDc6ZYkoDsIQBA5fGpVaUirGrwU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=lgb/Q6QbgPpYVoCQWufbnNeO6TEX7ZDqMXYrfQ15Hkd5E0ygPNT/oclYkoYlt0i8X +C47kd0ywPLNmoPuT6xnMFQGg+lYDP2364UjGcj6RRVUAvWzryoSa0FxCeuDaEMRhJ LbEZjwmiE7s1XOD4Rf1/3vOBaHbwXk1/fHXsq0D2X8IJJtYaKAVIGA5L1sQrWmd7lp +mTguUn/eaaU+OJuhimEirvPxL/A4zArmJPJFGbun6WFGMCiG2MtpgDywoHM2UJsfw hQdFJuRMS88/d/5UuhmlF10Xfj1BX4sXiyC5kjjVpwwVbfvr35smqU2QzwuTEAY2Fh 8fEyyAw+oRWeg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr01.francetelecom.fr (ESMTP service) with ESMTPS id 4K4h8R1LY6zDq7V; Fri, 25 Feb 2022 08:23:35 +0100 (CET) From: To: Marco Tiloca , "core@ietf.org WG (core@ietf.org)" Thread-Topic: [core] WG Adoption Call for draft-mattsson-core-coap-attacks Thread-Index: AQHYKZqlbNtus9aOIU+8qM7vQRlEx6yj3DnQ Content-Class: Date: Fri, 25 Feb 2022 07:23:34 +0000 Message-ID: <28040_1645773815_621883F7_28040_64_1_787AE7BB302AE849A7480A190F8B9330354999C4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-02-25T07:20:30Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=d6add262-4c10-4266-9883-f24e1ba2ce5b; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] WG Adoption Call for draft-mattsson-core-coap-attacks X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2022 07:23:47 -0000 SGkgYWxsLA0KDQpJIHN1cHBvcnQgYWRvcHRpb24uIA0KDQpJdCB3b3VsZCBoZWxwZnVsIHRvIGV4 cGxpY2l0IGluIFNlY3Rpb24gMi4xIHRoYXQgdGhpcyBpcyBhYm91dCA3OTU5LCBub3QgdGhlIG5l dyBibG9jayAodG8tYmUtUkZDOTE3NykuIEFzc2Vzc2luZyB0aGUgY2FzZSBvZiB0aGUgbmV3LWJs b2NrIHdvdWxkIGJlIHVzZWZ1bCBhcyB3ZWxsLiANCg0KVGhhbmsgeW91LiANCg0KQ2hlZXJzLA0K TWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IGNvcmUgPGNvcmUt Ym91bmNlc0BpZXRmLm9yZz4gRGUgbGEgcGFydCBkZSBNYXJjbyBUaWxvY2ENCj4gRW52b3nDqcKg OiBqZXVkaSAyNCBmw6l2cmllciAyMDIyIDE3OjIxDQo+IMOAwqA6IGNvcmVAaWV0Zi5vcmcgV0cg KGNvcmVAaWV0Zi5vcmcpIDxjb3JlQGlldGYub3JnPg0KPiBPYmpldMKgOiBbY29yZV0gV0cgQWRv cHRpb24gQ2FsbCBmb3IgZHJhZnQtbWF0dHNzb24tY29yZS1jb2FwLWF0dGFja3MNCj4gDQo+IERl YXIgYWxsLA0KPiANCj4gVGhpcyBtYWlsIHN0YXJ0cyBhIDIgd2VlayBXb3JraW5nIEdyb3VwIEFk b3B0aW9uIENhbGwgZm9yIGRyYWZ0LQ0KPiBtYXR0c3Nvbi1jb3JlLWNvYXAtYXR0YWNrcyBbMV0u DQo+IA0KPiBQbGVhc2UsIHByb3ZpZGUgeW91ciBmZWVkYmFjayBieSBXZWRuZXNkYXksIE1hcmNo IDEwLg0KPiANCj4gQmVzdCwNCj4gTWFyY28gYW5kIEphaW1lDQo+IA0KPiBbMV0gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWF0dHNzb24tY29yZS1jb2FwLWF0dGFja3Mv DQo+IA0KPiAtLQ0KPiBNYXJjbyBUaWxvY2ENCj4gUGguRC4sIFNlbmlvciBSZXNlYXJjaGVyDQo+ IA0KPiBEaXZpc2lvbjogRGlnaXRhbCBTeXN0ZW0NCj4gRGVwYXJ0bWVudDogQ29tcHV0ZXIgU2Np ZW5jZQ0KPiBVbml0OiBDeWJlcnNlY3VyaXR5DQo+IA0KPiBSSVNFIFJlc2VhcmNoIEluc3RpdHV0 ZXMgb2YgU3dlZGVuDQo+IGh0dHBzOi8vd3d3LnJpLnNlDQo+IA0KPiBQaG9uZTogKzQ2ICgwKTcw IDYwIDQ2IDUwMQ0KPiBJc2Fmam9yZHNnYXRhbiAyMiAvIEtpc3RhZ8OlbmdlbiAxNg0KPiBTRS0x NjQgNDAgS2lzdGEgKFN3ZWRlbikNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywg ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0 ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Fri Feb 25 02:25:20 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CFB3A0D56 for ; Fri, 25 Feb 2022 02:25:15 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 qTwttsowc0bq for ; Fri, 25 Feb 2022 02:25:11 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 871003A0D6D for ; Fri, 25 Feb 2022 02:25:05 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1nNXmZ-0008UB-04; Fri, 25 Feb 2022 10:25:03 +0000 From: To: , "'Marco Tiloca'" , References: <28040_1645773815_621883F7_28040_64_1_787AE7BB302AE849A7480A190F8B9330354999C4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <28040_1645773815_621883F7_28040_64_1_787AE7BB302AE849A7480A190F8B9330354999C4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Fri, 25 Feb 2022 10:24:58 -0000 Message-ID: <55ce01d82a31$f052c530$d0f84f90$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHArwUJYTgjKmdOOjJp4CS3KJofbgKK05zqrL6dK5A= Content-Language: en-gb Archived-At: Subject: Re: [core] WG Adoption Call for draft-mattsson-core-coap-attacks X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2022 10:25:16 -0000 Hi All, I likewise am in favor of this document, but would like to see a few = changes / addition. Med is actually referring to 2.4, but this made me realize there was a = trap of seeing Block and hence thinking RFC7959 for 2.1 - "The Block = Attack" which actually has no reference to CoAP blocks. A better = section title could be "The Blocking Attack" and s/Block Attack/Blocking = Attack/ elsewhere. For 2.4, "Fragment" in terms of CoAP blocks is not defined, and is not = used in RFC7959 (RFC7959 refers to fragmentation issues outside of the = CoAP layer), so is unclear that "fragment" is meant to be referring to a = CoAP RFC7959 (or draft-ietf-core-new-block to-be-RFC9177) block. =20 Thus, "2.4. The Request CoAP Block Rearrangement Attack" is a step in = the right direction for me. Then most of the usage of the word fragment = needs to be replaced with block. As a note for mitigating 2.4.1, to-be-RFC9177 requires the use of = Request-Tag = (https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block#section-= 4.3) and good use of tokens = (https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block#section-= 6).=20 The lost blocks recovery mechanisms in to-be-RFC9177 mitigate the risk = of the wrong block being processed in a request by the server. Again using Block-Wise transfers, there has not been consideration for a = delay attack causing the server to send back the wrong data in a BLOCK2 = response. See https://github.com/core-wg/echo-request-tag/issues/77 . = If the attacker delays the first request (which triggers a BLOCK2 = response), and then sends it just before/after the second request (also = triggering a BLOCK2 response), the request for the next block for, say = the second request, from the client may get back the block from either = the first or second request. This can only be mitigated using the = Request-Tag on each request, even though BLOCK1 is not being used for = the request. I think this attack also needs to be included. Regards Jon > -----Original Message----- > From: mohamed.boucadair@orange.com = [mailto:mohamed.boucadair@orange.com] > Sent: 25 February 2022 07:24 > To: Marco Tiloca; core@ietf.org WG (core@ietf.org) > Subject: Re: [core] WG Adoption Call for = draft-mattsson-core-coap-attacks >=20 > Hi all, >=20 > I support adoption. >=20 > It would helpful to explicit in Section 2.1 that this is about 7959, = not the new > block (to-be-RFC9177). Assessing the case of the new-block would be = useful as > well. >=20 > Thank you. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : core De la part de Marco Tiloca > > Envoy=C3=A9 : jeudi 24 f=C3=A9vrier 2022 17:21 > > =C3=80 : core@ietf.org WG (core@ietf.org) > > Objet : [core] WG Adoption Call for draft-mattsson-core-coap-attacks > > > > Dear all, > > > > This mail starts a 2 week Working Group Adoption Call for draft- > > mattsson-core-coap-attacks [1]. > > > > Please, provide your feedback by Wednesday, March 10. > > > > Best, > > Marco and Jaime > > > > [1] = https://datatracker.ietf.org/doc/draft-mattsson-core-coap-attacks/ > > > > -- > > Marco Tiloca > > Ph.D., Senior Researcher > > > > Division: Digital System > > Department: Computer Science > > Unit: Cybersecurity > > > > RISE Research Institutes of Sweden > > https://www.ri.se > > > > Phone: +46 (0)70 60 46 501 > > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > > SE-164 40 Kista (Sweden) >=20 >=20 > ___________________________________________________________________ > ______________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou > falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Feb 25 08:22:27 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061343A09E3; Fri, 25 Feb 2022 08:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 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, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQ12Tqbh8ffg; Fri, 25 Feb 2022 08:22:20 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 D5A853A0C69; Fri, 25 Feb 2022 08:22:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1645806132; bh=mlMSi9NMhWH/A8m807sD2lrU3h+Fz6UDX+tgdNi4ajY=; h=X-UI-Sender-Class:Date:Subject:To:References:Cc:From:In-Reply-To; b=IQtuFyOLCrkwCz4wVXmmSHLAVcOnQ/ciGCoSwtsj6yrHEbHcHZ56jkXoQFGFPsT1V fpaNz7DMRAWxP7MjwS5nI9GARgIzlj5MXTfbAyTJdzW9ci15qYU8nRoi2jtnwyWiAq QxjYIZgvHwG9hVNmzQ9r1AqvGwMVP5mBAWEa52LM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.10] ([5.146.193.130]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MatRZ-1nv3Il0TTH-00cOdz; Fri, 25 Feb 2022 17:22:12 +0100 Message-ID: <01663e0e-ccb7-84d2-08aa-3792799a783c@gmx.net> Date: Fri, 25 Feb 2022 17:22:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: de-AT-frami To: supjps-ietf@jpshallow.com References: <28040_1645773815_621883F7_28040_64_1_787AE7BB302AE849A7480A190F8B9330354999C4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <55ce01d82a31$f052c530$d0f84f90$@jpshallow.com> Cc: mohamed.boucadair@orange.com, 'Marco Tiloca' , core@ietf.org From: Achim Kraus In-Reply-To: <55ce01d82a31$f052c530$d0f84f90$@jpshallow.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:JRMs/0dW/+3sPXkU2jJKwn0tz1uxo3zTTHiCTP4m6+904ZVkH2s PHkMA8YTbGjQ0vNQ691tRD0GzqFxTX1hJd/0tp/r8qOk4iQ3Gp5IHyMPpzB3uv5r6nhHMpE sss4OBUaTwo0D4FBYb7Wnq7bmqDBAGAn3e5etH/7H8niM5ERLDniu3S0rjwXBzf6UJwK0kT LLmrHyfw29iu/Ke/YH/3w== X-UI-Out-Filterresults: notjunk:1;V03:K0:rrJEktq2A6g=:Xi21cKikyRUWAWRvs5jm8K PoLo0chEK6m9txZQN1yTHd72Lu0oyuHMwyi4+t5w+7QER/FzTdORbaOpgzNk3y3tGBCwHikn9 ggxpIHAxwH+bng6Tmdj1mtD7BzsGAgaQTkELoMS9C/h+2CXx0yULg7m4VbjVqHEn/wdapsNG2 q5sNHgJqcvxkN33+Ip+awrlxQq3NsJcastZiPZX2l769/ReTUcJTbOftMihosajd0bBYvur4P rjYUf9tJm9I7ETmBWYRf3yu1dxoPgui2OK8UKj+qobry/1N8RNOTzOuxV0JZeJUWDP/yEiLLG vyYEPVhkGS5DMgkpjuhdXXKMbOMD2mng2bCCwnKiR4KfnvDlG5mckZlnfrYxrOt5LE/M568nK emeg9d3da5JhpLa1QlB4lS/FACe6GL8TR9yr5+Z0rzogw/D724SKoeigb59LaJ6LX0hEFchsr z0lAj7paWZG1F1cNSdb+yyf0hTui77Q9X2S5l3OQK6R/hEn4WLwpY5AMQOI5TBFBYY6YeS8BO VcRjMdxxcPP5BHAl0gtfsxC4teReV9NKzU5EpF8DINLf6vsdqUxCHY0L8LzE+U+DSvurecMzY IzVl0WKlHOT9PZkDD4BpeWjnWudNewzsh9DcHWyfHYtV/T3T5yEskB1NA1K1FcZ6BaS5NQXkK ZNFB0H9k2BDAE4Z5zKjkZNiWPSNCCzherVcj+ahT7ZKQjuuSEVSDXgZcDZQXawbv9hbreBTt0 IH4S8+mLZ6J309VWO3JS89gS+ICXQFl7IikRBJSfYND7chRflkf7DArNbSLxy75mHQ7pbwBEH Zfs5rNPWYMr2H84TiVYnhPDDorSIoLXcxMPQKQaEE3CiUT+kzqnoxqfYOLuYrbC5DVj+ZvRtE ATJpvzOswwE4sED7s3awN5AMpBr7GCkgGdlvX9D1XXVwEGXKCjz4zpmsGL14sbJopU1QoSztP pPOjdfs+1DIUKBLVPQ+O0tBYURSNxvFaFH7R3w8XHAZgM7rie0eF5313svckQIJkk/Hc/RFMe gVtryZDmqDVv1YgpzfVV/WO7ZIjLyEJ3L/o8sS7nZwLuG4Xc9urgpwsrA4yyUUf6Ec9ecGx40 IaClsfk89nq3s0= Archived-At: Subject: Re: [core] WG Adoption Call for draft-mattsson-core-coap-attacks X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2022 16:22:25 -0000 Hi Jon, I'm not sure about: > Again using Block-Wise transfers, there has not been consideration for a delay attack causing the server to send back the wrong data in a BLOCK2 response. See https://github.com/core-wg/echo-request-tag/issues/77 . If the attacker delays the first request (which triggers a BLOCK2 response), and then sends it just before/after the second request (also triggering a BLOCK2 response), the request for the next block for, say the second request, from the client may get back the block from either the first or second request. This can only be mitigated using the Request-Tag on each request, even though BLOCK1 is not being used for the request. I think this attack also needs to be included. Does this refer to RFC7959? > may get back the block from either the first or second request. But the response will contain a token, which is used for request-response matching. So, do you assume, that both request are using the same token (maybe then more a unintended violation of the token uniqness)? best regards Achim Am 25.02.22 um 11:24 schrieb supjps-ietf@jpshallow.com: > Hi All, > > I likewise am in favor of this document, but would like to see a few cha= nges / addition. > > Med is actually referring to 2.4, but this made me realize there was a t= rap of seeing Block and hence thinking RFC7959 for 2.1 - "The Block Attack= " which actually has no reference to CoAP blocks. A better section title = could be "The Blocking Attack" and s/Block Attack/Blocking Attack/ elsewhe= re. > > For 2.4, "Fragment" in terms of CoAP blocks is not defined, and is not u= sed in RFC7959 (RFC7959 refers to fragmentation issues outside of the CoAP= layer), so is unclear that "fragment" is meant to be referring to a CoAP = RFC7959 (or draft-ietf-core-new-block to-be-RFC9177) block. > > Thus, "2.4. The Request CoAP Block Rearrangement Attack" is a step in th= e right direction for me. Then most of the usage of the word fragment nee= ds to be replaced with block. > > As a note for mitigating 2.4.1, to-be-RFC9177 requires the use of Reques= t-Tag (https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block#sec= tion-4.3) and good use of tokens (https://datatracker.ietf.org/doc/html/dr= aft-ietf-core-new-block#section-6). > > The lost blocks recovery mechanisms in to-be-RFC9177 mitigate the risk o= f the wrong block being processed in a request by the server. > > Again using Block-Wise transfers, there has not been consideration for a= delay attack causing the server to send back the wrong data in a BLOCK2 r= esponse. See https://github.com/core-wg/echo-request-tag/issues/77 . If = the attacker delays the first request (which triggers a BLOCK2 response), = and then sends it just before/after the second request (also triggering a = BLOCK2 response), the request for the next block for, say the second reque= st, from the client may get back the block from either the first or second= request. This can only be mitigated using the Request-Tag on each reques= t, even though BLOCK1 is not being used for the request. I think this att= ack also needs to be included. > > Regards > > Jon > >> -----Original Message----- >> From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com= ] >> Sent: 25 February 2022 07:24 >> To: Marco Tiloca; core@ietf.org WG (core@ietf.org) >> Subject: Re: [core] WG Adoption Call for draft-mattsson-core-coap-attac= ks >> >> Hi all, >> >> I support adoption. >> >> It would helpful to explicit in Section 2.1 that this is about 7959, no= t the new >> block (to-be-RFC9177). Assessing the case of the new-block would be use= ful as >> well. >> >> Thank you. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : core De la part de Marco Tiloca >>> Envoy=C3=A9 : jeudi 24 f=C3=A9vrier 2022 17:21 >>> =C3=80 : core@ietf.org WG (core@ietf.org) >>> Objet : [core] WG Adoption Call for draft-mattsson-core-coap-attacks >>> >>> Dear all, >>> >>> This mail starts a 2 week Working Group Adoption Call for draft- >>> mattsson-core-coap-attacks [1]. >>> >>> Please, provide your feedback by Wednesday, March 10. >>> >>> Best, >>> Marco and Jaime >>> >>> [1] https://datatracker.ietf.org/doc/draft-mattsson-core-coap-attacks/ >>> >>> -- >>> Marco Tiloca >>> Ph.D., Senior Researcher >>> >>> Division: Digital System >>> Department: Computer Science >>> Unit: Cybersecurity >>> >>> RISE Research Institutes of Sweden >>> https://www.ri.se >>> >>> Phone: +46 (0)70 60 46 501 >>> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 >>> SE-164 40 Kista (Sweden) >> >> >> ___________________________________________________________________ >> ______________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce >> message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme= ou >> falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and = delete this >> message and its attachments. >> As emails may be altered, Orange is not liable for messages that have b= een >> modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Feb 25 12:32:24 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE553A0872 for ; Fri, 25 Feb 2022 12:32:20 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 gW_YOui82vyA for ; Fri, 25 Feb 2022 12:32:15 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 DE6A53A0845 for ; Fri, 25 Feb 2022 12:32:13 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1nNhG7-0000P5-9g; Fri, 25 Feb 2022 20:32:11 +0000 From: To: "Achim Kraus" Cc: , "'Marco Tiloca'" , References: <28040_1645773815_621883F7_28040_64_1_787AE7BB302AE849A7480A190F8B9330354999C4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <55ce01d82a31$f052c530$d0f84f90$@jpshallow.com> <01663e0e-ccb7-84d2-08aa-3792799a783c@gmx.net> In-Reply-To: <01663e0e-ccb7-84d2-08aa-3792799a783c@gmx.net> Date: Fri, 25 Feb 2022 20:32:05 -0000 Message-ID: <5a5401d82a86$c10bf440$4323dcc0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHArwUJYTgjKmdOOjJp4CS3KJofbgKK05zqAWwAISkCrAJCDayei2zQ Content-Language: en-gb Archived-At: Subject: Re: [core] WG Adoption Call for draft-mattsson-core-coap-attacks X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2022 20:32:22 -0000 Hi Achim, draft-mattsson-core-coap-attacks has a focus on using Request-Tag to = mitigate attacks. Usage of ETag is not mandated in RFC7252 or RFC7959 = as far as I can tell (but is in to-be-RFC9177), but using ETag with = Block2 mitigates potential attack confusion. See attack below. Otherwise, please see inline. Regards Jon > -----Original Message----- > From: Achim Kraus [mailto: achimkraus@gmx.net] > Sent: 25 February 2022 16:22 > To: jon@jpshallow.com > Cc: mohamed.boucadair@orange.com; 'Marco Tiloca'; core@ietf.org > Subject: Re: [core] WG Adoption Call for = draft-mattsson-core-coap-attacks >=20 > Hi Jon, >=20 > I'm not sure about: >=20 > > Again using Block-Wise transfers, there has not been consideration > for a delay attack causing the server to send back the wrong data in a > BLOCK2 response. See > https://github.com/core-wg/echo-request-tag/issues/77 . If the = attacker > delays the first request (which triggers a BLOCK2 response), and then > sends it just before/after the second request (also triggering a = BLOCK2 > response), the request for the next block for, say the second request, > from the client may get back the block from either the first or second > request. This can only be mitigated using the Request-Tag on each > request, even though BLOCK1 is not being used for the request. I = think > this attack also needs to be included. >=20 > Does this refer to RFC7959? Jon> Yes, as Block2s are being used as well as RFC9175 >=20 > > may get back the block from either the first or second request. >=20 > But the response will contain a token, which is used for > request-response matching. So, do you assume, that both request are > using the same token (maybe then more a unintended violation of the > token uniqness)? Jon> No. I would be expecting the Token to be different in each request = that asks for the next payload of the body. Use of the same Token is = not recommended as per RFC9175, but people do not realize that an empty = token should not be used across multiple requests (another attack if = "Foe" was removing tokens as the CoAP packets passed through...). Jon> Client gets earlier value (ETag not used) against what it thought = was the second request. Client Foe Server | | | +------X | POST "request" T:1 { "offset":0, "length":2000} | | | +-------------> POST "request" T:2 { "offset":4000, = "length":2000} | | | | @------> POST "request" T:1 { "offset":0, "length":2000} | | | <-------------+ 2.04 T:2 Block2:0/1/1024 { data containing = 4000:1024 } | | | <-------------+ 2.04 T:1 Block2:0/1/1024 { data containing = 0:1024 } | | | +-------------> POST "request" T:3 Block2:0/_/1024 server - is this continuation of request using = T:1 or T:2 ? | | | <-------------+ 2.04 T:3 Block2:1/_/1024 { data containing = 1024:2000 } Was this the expected data ? | | | This is fixed if Request differentiating ETag is used in the response. = The client may not be able to get the missing secondary block from the = alternative request, unless Request-Tag is used in the initial request = (hence issue 77). ~Jon> >=20 > best regards > Achim >=20 > Am 25.02.22 um 11:24 schrieb supjps-ietf@jpshallow.com: > > Hi All, > > > > I likewise am in favor of this document, but would like to see a few = changes / > addition. > > > > Med is actually referring to 2.4, but this made me realize there was = a trap of > seeing Block and hence thinking RFC7959 for 2.1 - "The Block Attack" = which > actually has no reference to CoAP blocks. A better section title = could be "The > Blocking Attack" and s/Block Attack/Blocking Attack/ elsewhere. > > > > For 2.4, "Fragment" in terms of CoAP blocks is not defined, and is = not used in > RFC7959 (RFC7959 refers to fragmentation issues outside of the CoAP = layer), so > is unclear that "fragment" is meant to be referring to a CoAP RFC7959 = (or > draft-ietf-core-new-block to-be-RFC9177) block. > > > > Thus, "2.4. The Request CoAP Block Rearrangement Attack" is a step = in the > right direction for me. Then most of the usage of the word fragment = needs to > be replaced with block. > > > > As a note for mitigating 2.4.1, to-be-RFC9177 requires the use of = Request-Tag > = (https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block#section-= 4.3) > and good use of tokens = (https://datatracker.ietf.org/doc/html/draft-ietf-core- > new-block#section-6). > > > > The lost blocks recovery mechanisms in to-be-RFC9177 mitigate the = risk of > the wrong block being processed in a request by the server. > > > > Again using Block-Wise transfers, there has not been consideration = for a delay > attack causing the server to send back the wrong data in a BLOCK2 = response. > See https://github.com/core-wg/echo-request-tag/issues/77 . If the = attacker > delays the first request (which triggers a BLOCK2 response), and then = sends it > just before/after the second request (also triggering a BLOCK2 = response), the > request for the next block for, say the second request, from the = client may get > back the block from either the first or second request. This can only = be > mitigated using the Request-Tag on each request, even though BLOCK1 is = not > being used for the request. I think this attack also needs to be = included. > > > > Regards > > > > Jon > > > >> -----Original Message----- > >> From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > >> Sent: 25 February 2022 07:24 > >> To: Marco Tiloca; core@ietf.org WG (core@ietf.org) > >> Subject: Re: [core] WG Adoption Call for = draft-mattsson-core-coap-attacks > >> > >> Hi all, > >> > >> I support adoption. > >> > >> It would helpful to explicit in Section 2.1 that this is about = 7959, not the > new > >> block (to-be-RFC9177). Assessing the case of the new-block would be = useful > as > >> well. > >> > >> Thank you. > >> > >> Cheers, > >> Med > >> > >>> -----Message d'origine----- > >>> De : core De la part de Marco Tiloca > >>> Envoy=C3=A9 : jeudi 24 f=C3=A9vrier 2022 17:21 > >>> =C3=80 : core@ietf.org WG (core@ietf.org) > >>> Objet : [core] WG Adoption Call for = draft-mattsson-core-coap-attacks > >>> > >>> Dear all, > >>> > >>> This mail starts a 2 week Working Group Adoption Call for draft- > >>> mattsson-core-coap-attacks [1]. > >>> > >>> Please, provide your feedback by Wednesday, March 10. > >>> > >>> Best, > >>> Marco and Jaime > >>> > >>> [1] = https://datatracker.ietf.org/doc/draft-mattsson-core-coap-attacks/ > >>> > >>> -- > >>> Marco Tiloca > >>> Ph.D., Senior Researcher > >>> > >>> Division: Digital System > >>> Department: Computer Science > >>> Unit: Cybersecurity > >>> > >>> RISE Research Institutes of Sweden > >>> https://www.ri.se > >>> > >>> Phone: +46 (0)70 60 46 501 > >>> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > >>> SE-164 40 Kista (Sweden) > >> > >> > >> > ___________________________________________________________________ > >> ______________________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc > >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce > >> message par erreur, veuillez le signaler > >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > >> electroniques etant susceptibles d'alteration, > >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou > >> falsifie. Merci. > >> > >> This message and its attachments may contain confidential or = privileged > >> information that may be protected by law; > >> they should not be distributed, used or copied without = authorisation. > >> If you have received this email in error, please notify the sender = and delete > this > >> message and its attachments. > >> As emails may be altered, Orange is not liable for messages that = have been > >> modified, changed or falsified. > >> Thank you. > >> > >> _______________________________________________ > >> core mailing list > >> core@ietf.org > >> https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core From nobody Fri Feb 25 17:39:29 2022 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E43C3A0F05; Fri, 25 Feb 2022 17:29:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: core@ietf.org, francesca.palombini@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164583895810.24617.9292248781461094641@ietfa.amsl.com> Date: Fri, 25 Feb 2022 17:29:18 -0800 Archived-At: Subject: [core] core - Requested session has been scheduled for IETF 113 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2022 01:29:28 -0000 Dear Marco Tiloca, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. core Session 1 (2:00 requested) Friday, 25 March 2022, Morning Session I 1000-1200 Room Name: Grand Klimt Hall 2 size: 165 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/113/sessions/core.ics Request Information: --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Marco Tiloca Number of Sessions: 1 Length of Session(s): Number of Attendees: 60 Conflicts to Avoid: People who must be present: Francesca Palombini Jaime Jimenez Marco Tiloca Resources Requested: Special Requests: Please keep the 2 hours on a single session. Please also avoid any potentially IoT related BOFs and PRGs that might come up. --------------------------------------------------------- From nobody Fri Feb 25 22:59:12 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B460A3A0894; Fri, 25 Feb 2022 22:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.206 X-Spam-Level: X-Spam-Status: No, score=-0.206 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKuInW-idU2i; Fri, 25 Feb 2022 22:59:05 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 E7E3E3A07DD; Fri, 25 Feb 2022 22:59:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1645858740; bh=/Sidcovb0FYSfieD5Uy59acv+DurgpCt56hQRnf+ebs=; h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To; b=lV0MhMrnZO3liuu0/x4aRWb3YkNjgNqrrE8A/dBuUGoYUoTGHsRbLYQBdX1PfpE2/ SDad0UvcTypWWfBIxoCCiGeVqCgCqwfkrNutkSqr+L+t7LOUqQEa+apaaoxxzVgVyy FjVzqQxvsOTKPt4d1JPqZBltCxOz9BwPlSoAeZ7U= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.10] ([5.146.193.130]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M9nxn-1nKI8U44Xd-005q8K; Sat, 26 Feb 2022 07:59:00 +0100 Message-ID: <13e6217b-ec2c-ad40-3c8b-7a122045166e@gmx.net> Date: Sat, 26 Feb 2022 07:58:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: IETF Secretariat , core-chairs@ietf.org, core@ietf.org, draft-mattsson-core-coap-attacks@ietf.org References: <164572015352.14104.2558369378078022100@ietfa.amsl.com> From: Achim Kraus In-Reply-To: <164572015352.14104.2558369378078022100@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:7iQs1AlPPKT5/VWNRpD7T4CsnswusmMF+qOyE+O9i7yqC8P0RzU gosdlB9JovzEbjHgLB7SkUEjwSxRnVs/sDUafYVs6hccG9iXaQ9ak+NXmzEbVwCpun9JUQw JnUnR77tZm+SdKbgU/l72fK/GVzva9ob2945Tgm0V4kzgupshAcHY+Rbv87abQ/vzaSMPKK emQLK9EhjAfaTK2E48nMA== X-UI-Out-Filterresults: notjunk:1;V03:K0:buGUvrbC3bE=:eBPl37qXZ/jWYyeHAA6rlE yVESUMLVVomXUJ7rXbcdXwZgOXDHZtLgA0w4uejgbr2M7zwdIOmLrDfRjhw4puJOgCLN+cYCg KKTtYvYp0/A4uiFzp8uZ4cr/VsEcwhrHSvIlkKo/kgZnSrSCqwVf5hBmpNZQ+BW3i6/pUUGVf Kr6F2gLp31HwsabO5OJ6l8SB/zJrnOq4OxVnycRwso4luOpDrin0zAcq/e8h5dP49Hmo+pagN 33v05Y/BnjIuPVR0Dw3uR1VOpzhmLhsnj9t8VdJAj3ar0M0r/ydIdHLjpAb/JDoR01DNFJ0N1 Oho9nuCYSPxplfh5TMauy63xFbbNtXJA50hYDpXAwCP3oeUKY1vEmX9Uvzt0SVVwvnby2Huia hpcODCOIVrPahyHX13JbMIJ1XZBrxtttB0kLjvApE8WAUlju06Zn6SmkIOVou/MUwKWyVepwe mThDmb6bx3gzgbgTRbXShc95WYrvmpzvd5oo4fECHwpNx5lAjskTebWm9e1HR7FlMofQGnCA+ RefPXLtWAK3cYszq6+mb7B0y+byY9zNdZVcS8f6vXED9ULONhcD35PYeYWLKsSqAFblpSkFxI Zvj2odhQIm4+tAasvRXfbtaup5QspICt3Xq+nEMYE2WTNb/wqtMnZMIJMMhj2qNQC9+O48AKk 1LtYSgm5jbPNM0Imat/pnwnq3W5naDQQXGL11GaqfEqlsu2pV5t0Yw9YzvO+EauFfPNHA3T1S zDIkx7Bg1hpauHAuIfWaXLTrGZAbGkVa9BS61BwlJrScKcqDJ90dP+ebHMmTKmINpUzVpAzOs aZj2sDr2vdbpLHwyAXDD+ELUe59Sqaoz4iDJ1KPNuvd4XV5MpzkC2kV11uV5xuJREdq6Jy+uh 7CDJfthQcj5X23U9vGlXM9lndKZTRxytM28m8a7qE0QGuiql4H1TaUXt24+b546bQB49XzSYf uO8+Dhppu909jtd8XrNGDjJPYMHtP8IPZO1VQ9vCgv/4/x+YBmrFYYPGgB9Fzvuvta3Fq//1Y PqeA+YoPczyhKGkyi7Z8VHr+wIYKnP3/g0/P3jFQpLCfsw4PEps1A104qhJ6KtOsqoztwrvQF 7rG3Tga6xoRtSA= Archived-At: Subject: Re: [core] The CORE WG has placed draft-mattsson-core-coap-attacks in state "Call For Adoption By WG Issued" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2022 06:59:10 -0000 Dear List, I'm not sure, what the purpose of this work would/should be. Reading "2. Attacks on CoAP 2.1. The Block Attack An on-path attacker can block the delivery of any number of requests or responses. The attack can also be performed by an attacker jamming the lower layer radio protocol." is true for much more protocols, not only CoAP or DTLS. You can even cut wires. To narrow such a general issues to a statement about a single protocol may be a little smelly. "In this document we show that protecting CoAP with a security protocol on another layer is not nearly enough to securely control actuators (and in many cases sensors) and that secure operation often demands far more than the four properties traditionally provided by security protocols." The document addresses weakness, but it's hard to see, that this weakness is qualified. Many of the attacks seems to be somehow "easy for an on-path-attacker on unecrypted messages". And, yes could not be excluded also for encrypted messages. In my opinion, encryption makes such attacks much harder to apply, less attractive. And so "not nearly enough" seems to be too strong. My impression is, this document puts doubts on using DTLS 1.2. It puts threats of unencrypted messages too close to the same (but much lower) threats using encryption. I would appreciate, if the document is clearer about that. Not that it turns into a disservice. best regards Achim Am 24.02.22 um 17:29 schrieb IETF Secretariat: > > The CORE WG has placed draft-mattsson-core-coap-attacks in state > Call For Adoption By WG Issued (entered by Marco Tiloca) > > The document is available at > https://datatracker.ietf.org/doc/draft-mattsson-core-coap-attacks/ > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sat Feb 26 10:02:27 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839FB3A0AA6; Sat, 26 Feb 2022 10:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Jq1HhetsW43g; Sat, 26 Feb 2022 10:02:13 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF58A3A0AA0; Sat, 26 Feb 2022 10:02:12 -0800 (PST) Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4K5ZGm2jgQzDCc0; Sat, 26 Feb 2022 19:02:08 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 667591327.975728-155bbd535d9d688a6c2ab395ecfd4bab Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Sat, 26 Feb 2022 19:02:08 +0100 Message-Id: <11AAF35A-BC6E-4516-8F8D-C8EF8FAF9371@tzi.org> To: ace@ietf.org, "core@ietf.org WG (core@ietf.org)" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF113: FINAL AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2022 18:02:17 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF113. Remember that further agenda changes can still happen. The IoT-relevant conflicts that most meet the eye this time are LPWAN/ACE (probably little actual overlap) and DRIP/ROLL/RATS (probably a little more overlap, but not that much). CFRG and ICNRG are the only RGs not on top of IoT meetings (T2TRG, like e.g. CBOR and JSONPATH, decided to go for interims instead). In the "FINAL" agenda, DANCE is now on top of CORE; not much else has changed from a constrained node networks point of view. All times are in UTC. Note that the third and fourth weeks in March (W11 =3D pre-IETF week, W12 =3D IETF week) are Weeks of Confusion, where DST has not yet started in Europe but did already start in North America. https://datatracker.ietf.org/meeting/agenda-utc might be handy. Gr=C3=BC=C3=9Fe, Carsten (### DST in US, no DST in EU ###) SATURDAY, March 19, 2022 0830-2000 Hackathon - Grand Klimt Hall 1/2 0930-1000 Hackathon Kickoff - Grand Klimt Hall 1/2 SUNDAY, March 20, 2022 0830-1500 Hackathon - Grand Klimt Hall 1/2 (0900-1700 IETF Registration - Park Ensemble) 1300-1500 Hackathon Results Presentations - Grand Klimt Hall 1/2 (1600-1800 Welcome Reception - Grand Park Hall 1/2/3) MONDAY, March 21, 2022 0900-1100 Morning Session I G Park Hall 3 ART dispatch Dispatch WG - Joint with ARTAREA G Park Hall 1 OPS v6ops IPv6 Operations WG G Klimt Hall 2 RTG raw Reliable and Available Wireless WG Park Suite 9 SEC openpgp Open Specification for Pretty Good = Privacy WG Park Suite 8 SEC *** teep Trusted Execution Environment = Provisioning WG 1200-1300 Afternoon session I Park Suite 8 ART sedate Serialising Extended Data About Times = and Events WG G Park Hall 2 IRTF pearg Privacy Enhancements and Assessments = Research Group Park Suite 3 SEC acme Automated Certificate Management = Environment WG Park Suite 9 SEC *** cose CBOR Object Signing and Encryption WG G Park Hall 3 TSV tsvwg Transport Area Working Group WG 1330-1530 Afternoon Session II G Klimt Hall 2 SEC *** lake Lightweight Authenticated Key Exchange = WG Park Suite 8 SEC oauth Web Authorization Protocol WG G Park Hall 1 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG TUESDAY, March 22, 2022 0900-1100 Morning Session I Park Suite 9 INT 6man IPv6 Maintenance WG G Park Hall 1 RTG can Computing-Aware Networking BOF Park Suite 3 SEC *** rats Remote ATtestation ProcedureS WG G Park Hall 3 TSV quic QUIC WG 1200-1300 Afternoon session I G Park Hall 2 INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG G Park Hall 1 IRTF qirg Quantum Internet Research Group Park Suite 3 SEC *** ace Authentication and Authorization for = Constrained Environments WG Park Suite 8 SEC emu EAP Method Update WG Park Suite 9 TSV tsvarea Transport Area Open Meeting 1330-1530 Afternoon Session II G Klimt Hall 2 INT intarea Internet Area Working Group WG G Park Hall 2 IRTF irtfopen IRTF Open Meeting G Park Hall 1 RTG detnet Deterministic Networking WG G Park Hall 3 SEC secdispatch Security Dispatch WG WEDNESDAY, March 23, 2022 0900-1100 Morning Session I G Klimt Hall 2 ART moq Media Over QUIC BOF Park Suite 8 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Park Suite 9 IRTF maprg Measurement and Analysis for Protocols G Park Hall 2 RTG rtgarea Routing Area Open Meeting G Park Hall 3 SEC tls Transport Layer Security WG 1200-1300 Afternoon session I Park Suite 2 ART mediaman Media Type Maintenance WG G Park Hall 1 INT *** drip Drone Remote ID Protocol WG Park Suite 8 RTG *** roll Routing Over Low power and Lossy = networks WG Park Suite 3 SEC mls Messaging Layer Security WG G Park Hall 3 SEC *** rats Remote ATtestation ProcedureS WG G Park Hall 2 TSV taps Transport Services WG 1330-1530 Afternoon Session II Park Suite 3 RTG bier Bit Indexed Explicit Replication WG 1600-1800 IETF Plenary - Grand Park Hall 1-3 THURSDAY, March 24, 2022 0900-1100 Morning Session I G Park Hall 2 ART httpapi Building Blocks for HTTP APIs WG G Park Hall 1 INT savnet Source Address Validation in = Intra-domain and Inter-domain Networks BOF G Klimt Hall 2 IRTF coinrg Computing in the Network Research Group Park Suite 9 OPS *** iotops IOT Operations WG G Park Hall 3 SEC saag Security Area Open Meeting 1200-1300 Afternoon session I G Park Hall 3 INT madinas MAC Address Device Identification for = Network and Application Services WG G Klimt Hall 2 IRTF panrg Path Aware Networking RG Park Suite 8 RTG rift Routing In Fat Trees WG Park Suite 3 SEC privacypass Privacy Pass WG G Park Hall 2 SEC *** suit Software Updates for Internet of Things = WG 1330-1530 Afternoon Session II G Klimt Hall 2 ART webtrans WebTransport WG G Park Hall 2 INT add Adaptive DNS Discovery WG G Park Hall 3 IRTF cfrg Crypto Forum Park Suite 2 SEC oauth Web Authorization Protocol WG FRIDAY, March 25, 2022 0900-1100 Morning Session I G Klimt Hall 2 ART *** core Constrained RESTful Environments WG Park Suite 8 SEC dance DANE Authentication for Network Clients = Everywhere WG G Park Hall 2 SEC gnap Grant Negotiation and Authorization = Protocol WG G Park Hall 3 TSV tsvwg Transport Area Working Group WG 1130-1330 Afternoon Session I Park Suite 3 IRTF icnrg Information-Centric Networking G Klimt Hall 2 OPS anima Autonomic Networking Integrated Model = and Approach WG (### DST STARTS IN EUROPE ON SUNDAY ###) From nobody Mon Feb 28 09:46:21 2022 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EF93A08CB for ; Mon, 28 Feb 2022 09:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=ri.se 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 lQzYw9Qt2Iux for ; Mon, 28 Feb 2022 09:46:14 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20048.outbound.protection.outlook.com [40.107.2.48]) (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 52F303A0770 for ; Mon, 28 Feb 2022 09:46:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D3zJiXLZg7V6M8Elf8kiwQeiQ9jqfSEu29hoyRXaUxhyxLrUvtY+iwZkBi40WAYtWiBGwqLNyHc5IOEzvJSiz0RPxOvbCKMBb+Bq5vEqccuAHPHzTGV86H00Zya2jaldSVkTaccR6Mdz1YKSHU7H2MQ8f1CnDHF+Udqx404DG6noX9cROkODAKBt1qpkFToPIPedMzV1IpzKEy7DzsIz6j/8EC2653v4vdkb8hmEq0el8BZv4ucqunGuRAjipHXSp6OMpAymBdu5YES3sL8BKr9jO1cLgM+xN2S8OZWBq0xM0xmb+FkW75AUyb6dwk6FjNMhx0DSWON+bMtXHMNzew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=r3lVFtfeba9KD+/2GLK0s1RrMHYOmLvffZ8Nj5b7kKs=; b=cLJlRzdNKUWebA1BZgUY1z1K+lUs7zJi/kGKETho7zSSykk6zL7fPPOMxmVZU9QkjYEvZfIbEhNo1WVu4ZLmGzAXPwT1l6PWgmyDPAjN2jljDBPjam/l7hRRkzFSn4jlknfPTTXu/HQdIPBunOgcJBIFDsJwpWyDDtLPPorWYScHWjwwv4JZPs0nPDT21+PW3ar+3GITqmjs8V3cnW+tbdexRMAZ55RvYwK3SNhxq9/VIC/bJMk4KXZr3PhB7tvT1pgdLyaNEBrXR2VE9RdW4ONmD5HNerncKzm1653OBHnfPoHgU9SiES8Z8vLTwsDcFZ0z/bUrRwvB0FdONP/XCQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r3lVFtfeba9KD+/2GLK0s1RrMHYOmLvffZ8Nj5b7kKs=; b=k5cW23MbnUlRNyAbKg0LsatKJqpdYHBJWxeTR/CSkywwm+Re1SPckEY+XQxhPDYex06HSsJsKnOU60dsWU6Vh/LE1qNdcBeDDBN4s/KKbCzSCu50P1ImSo07OFwo1OLE5bBrHRcAtgHbXk7kshfmFbMhRzo3+3ezgw4Rtq0ifOM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by VI1P18901MB0175.EURP189.PROD.OUTLOOK.COM (2603:10a6:801:4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.26; Mon, 28 Feb 2022 17:46:10 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::8548:6918:4d2d:e57a]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::8548:6918:4d2d:e57a%4]) with mapi id 15.20.5017.027; Mon, 28 Feb 2022 17:46:09 +0000 Message-ID: Date: Mon, 28 Feb 2022 18:46:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------MAScTPHOAZ0aWsrgkqUJNYhQ" X-ClientProxiedBy: AS8PR04CA0186.eurprd04.prod.outlook.com (2603:10a6:20b:2f3::11) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fb1f2b67-307d-47b5-7c2c-08d9fae23333 X-MS-TrafficTypeDiagnostic: VI1P18901MB0175:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ELVIADXLX350ftmSmCuqZnv78p26J6rixYbsjT6l0ca0skxz1HWMH/Ufvf4/Zl3Ld3Pw4IU3LSrPi82SViE5lrZl4lbQEwuB4I+NyD5CEyMAFtMc76fpjLesuBk17KTHVySQY+xakK8z2XuyV6cX4qoEstPBamrr3U33a+GfOObhi7RwkSjRZIPQE0Gq1e+pCI7JJZXZA1/rK+mD+zQDvMMnWmMM/OxzHlJ52YrfHgNOI9kffT8xJ5D7E8/yFVeFkdFRalOVeoxjNN1Pe7TMbbdt1YTsO1Utf0balekOIKxbGHFTtYlKcN3ypq+XMDRMvbwtGtUu4Sxcg/k6gs87XydTCJKKIwqN5MZggxU94cSv9F/eV3/5MYxeIdpFlCXzVMZRW4T9/Ys3iKRnvZcnvmRZWr2ndYZXaWKLA4JDllzuotefoJPu7Q1/9QDxMurQRkyvnQ7fZXp0QpN3qvlwhke5cCOSHj0i0tDYMpK9OnmLrBvId+Lqk+hvDcRnm/0CcQShZ8Qtkn+N2WBa14PavmjhDIe2d5r+rnPnBq+K7ihVypaD64WiactasEjUwxdJT51XeGE5rRehlR7Lwq1AB+YRyTHv4+hwAD48fd6fhiKPSjdGzlCZXWgqCWskB0uvXtsB2fuBI3XNaz2Qz+a5IXmxadn/yEzi4ApoYzAPLbsYZzEhofjZXp4ADSZzzMy69dY60IuJLMZuAm3GcR63bUOJF9ocLBckGqtZgU+ihEwsi9rJAWKBtdr28sISWGsBGEa7qoizI8B+eVMgVkEShm+Nq5mN2wBXYnkTnyHkqUc5/NXbN16xDfA/wDkALuwM X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(186003)(2616005)(2906002)(26005)(66574015)(38100700002)(36756003)(6506007)(6512007)(6486002)(44832011)(8936002)(5660300002)(31686004)(6666004)(33964004)(508600001)(235185007)(966005)(83380400001)(316002)(66946007)(66556008)(66476007)(8676002)(31696002)(86362001)(21480400003)(6916009)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MXAwcHE0T2kxaDVWQmkvUklNTVNsTnd4VCtQeWNmNzhidk0yamlLcVhUSUkr?= =?utf-8?B?djlZdm9DUUx1aFJST1duRXJkT1ErY1F3QXlJSE4wdFJhRnZRYVQ1M2N1S01Z?= =?utf-8?B?V08zRk50UUZ5ck0zZjZmQkhQcXhhWUM2RDlzb2tTUmNNZWwxR1M1ZVpTdHR6?= =?utf-8?B?ZkxVVUovZy9OWE9NYy9DeDF5bEZtT3E1YURnK0NOVk4xam9vOExsWnpmaVpH?= =?utf-8?B?Qlg3WXhreWIvZkFaaldKTXVUYS80SkhIWXRwdjRlaXpieDJMSXNpbGREK2Y0?= =?utf-8?B?V1lCUTdnd28xZnlZY3JmaEdSUTE2U0RNR2NqOXFOZ1ROdDJETFBrdVFWUFBu?= =?utf-8?B?OTF0QlFhdUtid1RETlBBZTd4eVBBc2MyL2xDY1hRckZMWUx3cEQ4SlJZMEo1?= =?utf-8?B?ZW5BUHMvQTVHeUVoTTVzS251bzFXaGhGYXVtUEVwVGkrVXB0ZEtnSThrZnRl?= =?utf-8?B?UzNiYlZCdGJNOTRuZ3hITlI3SWFYc0Q1T2gxVTNVaXRBQU1vbGo4OWZTSXM0?= =?utf-8?B?dytyaUdUMndaNS9idGRDVUZTM3pkeDd1OEEyQVZJZUhsdnNSOTAvYUJtZkJE?= =?utf-8?B?cGxRb0VwZllOeHYyM2lGdnA2L2ptV29hUjdTeFdmMWRpQVN3VmxOVVBuekt2?= =?utf-8?B?cHNOdzFmTlUyY3JCTy9ucnl4WlB6SUs4Zk9vYktIWjVLakFkazRzZzZaMXMv?= =?utf-8?B?Rm9INDg5bzQxTlNWNTk0Z1h3NGJVRmc0dVk0ZnkxVlpocnFLSGs2Zy91bDJx?= =?utf-8?B?ZnlTTDR1M3k3U08xNzJhbkFqUzJPTUhGYnlwM09xZURvKzYwV0FFTEo3VXpU?= =?utf-8?B?WDU2YW1pcjZObDRuOFdocWZPRDBWYmhSeDRLWm5vcWFSVnM4ZEQ5MkdiVWZH?= =?utf-8?B?NkxhOEdrUVQweUFaRjJZZFRBYm9SaC9EQUYzbExPcU9JY0dlSVFCNG5ENzBQ?= =?utf-8?B?dW1DT0xEeTZ2V0pyYXBIVWh6WkN2MUROWVZjelgvWTNOMHkyRlZIN3V0Qmgz?= =?utf-8?B?eVZzd3U4bzFQK3NGeFZMZ0prbmlLclhZWnpYYzVvdlBzQWF1VUF3TUxZanVw?= =?utf-8?B?WkY4SXZMU2dCdFd3M1ZBQXFYanN4TkVMbHhCUW9UK085UU1xNitDb1RFWWV4?= =?utf-8?B?a0pFMGFyZ0hzbmJVNmNzRTYvcEFHb2tVUy9ZQzUwUXVDbTk3dU9qaVl5QU41?= =?utf-8?B?a2NseG1NUURQcVBVdWE0bDg5QkZOcU0yUWdsTGpKdUdBWWRvbkpWRGZoRVll?= =?utf-8?B?NjVwSXhhWlU3d2lHNVpJMW13UVN0bC9RRzNvVFlXZEU4WXVoU3JrZm1FS0Nr?= =?utf-8?B?VGdtNjAxVndZME14QVJjam5adTZURkgwY3FDR0JVNit4dXlpNlFuWTRYalQ4?= =?utf-8?B?dVVHWkh0c1E1azV0Z3Rhd1FRNjUwWG9XY2ZuSWlpekxJUDZmaEVWU3NKSmNS?= =?utf-8?B?eFhEM3N2cE1lSUpFL1Z6WDhGclh4YnorUkdWU2hMQzNjVU54RTA5Vm9uczhk?= =?utf-8?B?R25vQzVqaTlkTEtuSXZjdHpTaENZL29ZZ0tyS3BTUGRGVUtKWjkvRkUreVVw?= =?utf-8?B?YVErdEdBZDkvcnRkRTE2WGxZaFo2UFJDaXIwZWk4K1ZRVHFMVUFRb2YwSnU3?= =?utf-8?B?Uk11UXg2eGV1YW9JelcvOWVzVnBhM1ZGbE9FS1JDT21qcy9ybnllZTNkcXVU?= =?utf-8?B?emFWY0lKVjlQMENRV1B0Vjd6N240UjBjaEVqa3ZYTmdqVUhWWExMSERiS0RJ?= =?utf-8?B?WHFSNlpaTmFTd3RxK0UrUVRPWEExK1c2eVpsSFk2Q3Boak54bDg0azJ6TTYz?= =?utf-8?B?NXlFbW5CQlFlWkpyK1V3L3dMMVo4bDk2a21wdGY4UXd4ZDRHMDNrb05nOENm?= =?utf-8?B?T242UWFsTXJ4MWRpQ2NHOEVNQnJHR2dMYXlGbXJzNDZ6MWZQZWNTZnRPU3F0?= =?utf-8?B?bm5ka3hnOXBMUlZtdjJzTEtOcXptd2RDRTlxbVhCaUJzTFd1My9INGdGQUhj?= =?utf-8?B?eFJoUDFJaFRuT1dFV041VHlaRW9WT0NMblR1WFhnSHNHTml1cmJidWFTRWRn?= =?utf-8?B?Zk1vQUdwSDdYTmlremYwemFhZEtOcG9naU9VTlY5VmdVR01nNDJQZXFnSTlW?= =?utf-8?B?alJKUFl1V2Jad2JLT1htVUcrelFzSFpwU25NSXZLTGhNMzBWT09BRzBrY1dm?= =?utf-8?Q?fX0SCAcAEY1moQFY/AIfPI4=3D?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: fb1f2b67-307d-47b5-7c2c-08d9fae23333 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Feb 2022 17:46:09.2119 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: oU7B6skVXgih1gGrNd/gZVHf8YyY7hc4qDRe5m0qJzddV9S1QtZXiofHRpKtSB5W58FdOoOaC+OrksTx9+G4eQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P18901MB0175 Archived-At: Subject: [core] CoRE WG Virtual Interim 2022-03-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2022 17:46:20 -0000 --------------MAScTPHOAZ0aWsrgkqUJNYhQ Content-Type: multipart/mixed; boundary="------------AIuDU7rUiBG9EiJhqomXg1Ao"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: [core] CoRE WG Virtual Interim 2022-03-02 --------------AIuDU7rUiBG9EiJhqomXg1Ao Content-Type: multipart/mixed; boundary="------------ko6Cmu0PCtP0NZuJfi6Znwyi" --------------ko6Cmu0PCtP0NZuJfi6Znwyi Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkp1c3QgYSByZW1pbmRlciB0aGF0IHdlIHdpbGwgaGF2ZSBhIHZpcnR1 YWwgaW50ZXJpbSBtZWV0aW5nIG9uIA0KV2VkbmVzZGF5LCBNYXJjaCAybmQgYXQgMTU6MDAg VVRDLiBUaGUgYWdlbmRhIGlzIGF2YWlsYWJsZSBhdCBbMV0uDQoNClRoZSBtZWV0aW5nIHdp bGwgYmUgb24gTWVldGVjaG8gWzJdIGFuZCBtaW51dGVzIHdpbGwgYmUgdGFrZW4gYXQgWzNd Lg0KDQpCZXN0LA0KTWFyY28gYW5kIEphaW1lDQoNCg0KWzFdIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMjItY29yZS0wNC9zZXNzaW9uL2NvcmUN Cg0KWzJdIA0KaHR0cHM6Ly9tZWV0aW5ncy5jb25mLm1lZXRlY2hvLmNvbS9pbnRlcmltLz9z aG9ydD02ODU4MjA3MC00MzQyLTRkMDEtYTJkOS1mYzc5YTJlODYxNzMNCg0KWzNdIGh0dHBz Oi8vbm90ZXMuaWV0Zi5vcmcvbm90ZXMtaWV0Zi1pbnRlcmltLTIwMjItY29yZS0wNC1jb3Jl DQoNCi0tIA0KTWFyY28gVGlsb2NhDQpQaC5ELiwgU2VuaW9yIFJlc2VhcmNoZXINCg0KRGl2 aXNpb246IERpZ2l0YWwgU3lzdGVtcw0KRGVwYXJ0bWVudDogQ29tcHV0ZXIgU2NpZW5jZQ0K VW5pdDogQ3liZXJzZWN1cml0eQ0KDQpSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dl ZGVuDQpodHRwczovL3d3dy5yaS5zZQ0KDQpQaG9uZTogKzQ2ICgwKTcwIDYwIDQ2IDUwMQ0K SXNhZmpvcmRzZ2F0YW4gMjIgLyBLaXN0YWfDpW5nZW4gMTYNClNFLTE2NCA0MCBLaXN0YSAo U3dlZGVuKQ0KDQo= --------------ko6Cmu0PCtP0NZuJfi6Znwyi Content-Type: application/pgp-keys; name="OpenPGP_0xEE2664B40E58DA43.asc" Content-Disposition: attachment; filename="OpenPGP_0xEE2664B40E58DA43.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLN R8ZhDz6ZaRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD +QBdf29pQadrVZAt0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGN dsY6kPSVzMRyedX7ArLXyF+0Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZX kLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+NrSetJlljT0QOXrXMGh98GLfNnLAl6gJ ryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEBAAHNJ01hcmNvIFRpbG9jYSA8 bWFyY28udGlsb2NhODRAZ21haWwuY29tPsLAewQTAQIAJQIbAwYLCQgHAwIGFQgC CQoLBBYCAwECHgECF4AFAlSNerkCGQEACgkQ7iZktA5Y2kMiuwgAt/bVZKqD92JN WDTX6h1MUsgejwj4RXs6UYqFdWW/4nw4mFHzYS+gBjOQAWCBhzVZLOk6gKcRZ/s8 6ncVygiDUh9fbSDTcuzOp2qgu9nsc8sEsYp1hwmiIEbI6FHPtyeQQNilsfU8+VHX 2C9yQtMK/OXlf5qNkJMj9k55u+e1ELQ2sjUXkMB4MxMhmi/3P3hMz9PDcB66BtQc DFYkx5PIaz/izCST0o28AJq0dionJpPsQ+hFOIAkJi6aCAt3xQf0KnXlAczWxCD3 J3XTFK4MES/b3n3oc2GJY8I+tsfT5jpNsWhfWGBkMaQSKZ939D4oFAhAq3gnNRgZ szJeTvsMvcLAeAQTAQIAIgUCVI15FQIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgEC F4AACgkQ7iZktA5Y2kNZdgf/drEFkXWpz9pPm0/ZwNNfXzHkpGLqcfPlvQaSNFFb oHwJaeKZ6s3dCGpzDlV6bLrRM9LN/sgNRT0eNiElJHtKDW/fqvzrHl3LCsDKed4L K4Gg2mE0nvWvTno9Nyza8TatJm1+V2S7MbDgSE/F26QK2VL9Y/ur5BHgUI34mUar 4iE1Aq7nsFbN6NEvamyQPWlkN+rCjtnT0+NLGb5VnDVKAHSgiYgGQeDvlisWb9Nt sxzXf1qge3tlCufadSWXyqa4oOq4hEcD3GBUQVuGfBNa7r0mqHzVZf0qd+Kxzs6D p9LxTGp7aSjiXN6cBoapz7lSP0wXOgSzIJ1X2UtVssKv28LBYgQTAQoADAUCVZFC zwWDB4YfgAAKCRBo+Jp/4mFufTrAEACwA4G0VlNs1JOAMgIOfE96v1lVsJiI9qod 5Njc1jlXqItPKDXzvmTJACy7JfA2UbRbwkym7eCc94jkQU6XdTzv8Qf6rpbVZhzF 9tNL38mzm8emh5vV3XDy8arElEP7bE9Jfgm23Lm9OEwubbtjLYf0z7poncThsYUu aEexnxUVF/PXNMIlVBXil/27HkhuWKhpJQU7A35YiJz+lalfGS+9OSv9nJD9mdoT Nk4eSG2sfYKRKs6rmN3X+J9ZITs9Hnpncgu3coayZaL69iicZ4ge1KXACiGG0zpK 666d5ByWgWU7PRqiFIkXwHDW1esZ/QHIJFIXN9zpCD5KaSctvj+tFPNTz2+quiVS nWWQFv/92zRTS4SJgxXP6I3nTasuC6KJy+JnMNfzOVpj05Ef1lXuncc4kLCqd2As 1S6e/OC5Mdo5jQhe0Ozju5IwhRCoqKe1huSj4mbpaTvCjKyh67zVsJR/xDHFDzgt doCsRRQQxWME8+V95FqsleNd1QfEU/jM+HS4JWTDwFs+f1kHzzwhDHWs73M0/jvs 8mUGlfRwSQVDfN6ygbuCn/i2Lvvtc2RWbxWGJVekG8x2rFxUOQ7B2DqmxBrRX3GL okNJ7eWrLNLlYXGA7ptoGWLKQ1FcNNIgapKbxd0s5+s3ql7EaGViJ84ozNX5q52b RceaSihi4s0cTWFyY28gVGlsb2NhIDxtYXJjb0BzaWNzLnNlPsLAeAQTAQIAIgUC VI16cwIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ7iZktA5Y2kNxXggA hFyfi+VlqgIj5a54npaUoREoQ5Tj8gzUPmqOXddo0q9f1cQn/+ehKpbb3TDVzO35 HBXZvuFGn5DHBUYhqBFWTx+H5zHgGBRhF0imQ9Yi/gHe2StgrSIa5528iV2g47Oy DDlSCoCWEM4WwWkJqv9CP2J53Gb63UOPuq5j+BF9wtDs6M6YAs9GdHIDhvUJWGDh OZevyp/DWE5d3LCI+HJIajDjhJK02kVg47aBusW40mGXmjWmtJXP+QtZRfSaabFx CVE3APBn+P4zuyb+mk1gwkN51OiFuYQr1ig3M55kaoGbrs57fVuGtaC9DSc1vgai cJQrYpCbOrbR/yZAedz3xcLBYgQTAQoADAUCVZFCzgWDB4YfgAAKCRBo+Jp/4mFu fWd/D/9PO2eZHdU0Rxr4f0EmNqhMnA6KKIo141DQnpQNqHs0RUgDlDUN1qHjgv1U xu3gbtJoQ4PbT9rJan4Oem7/NJQxU6tsa/dFjDyn9txVGppd12pVFcnGRcDNhLDz ALgZN1ABxfpOh4hQy79qn69Stn0GsSnK6gEq/+3+KROA0ZKEDWcE2rVEzw4UEv37 BUaVnBnHYvNQRQVY8hc43qi3WWUhM3Ot0Z+peAV7D3Y5ZkaSLN6kFoZPZFhrf0fh lLx0ajFIIRDQ8R8ThXXcRopWhw+ifUFdtXoW0goWPFqOkgJw1HYNbYjT4G4DvUAY t5ueCOP6MNXEkDS4r1Hz5JDemtee+FIoaIWbma+ccL3gceoQXwvMtNu1MYFN/n13 YYlqwg9AyIkobG56OeW4o9qqkNjb3GlX+cw6f4uf7l29IF7i3jOFh4GXlYoevYiw 9EpnqLWkWgm5KbT+J9h/tkgt99GXfGkfLzpyjU563esgxpIwWX586ssWlbJWlAPz Cf3do08MiLWTRVcrY6pXVTGAF/c41uC6520+RFm4ytAfrefNac1+5eZBG5k84sTd V9aamCAWkUIEaNQkTfMB7xSXAlq2T8I+kHJCsLSKXXPFdjMJtVRWSZ/gzaBE7cbE Lu9KaHyVRAxNKSsMInAmn/FsxnW6VFaseoT5OtxTMuAnROjB0M02TWFyY28gVGls b2NhIChtYXJjby50aWxvY2FAcmkuc2UpIDxtYXJjby50aWxvY2FAcmkuc2U+wsB3 BBMBCAAhBQJaQCeQAhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEO4mZLQO WNpDAS8IAIko8kg8YfSgacsljgbUjYOA2LJUq3UfiSRz95PwHP05JsDGBmjcmTLf zZ7gNtprJatBEV6fRotIW7NtTgFfg79hFJoipQ7crBQ07WJMLrk4fPReKsaiE9Q6 xzRIQy2mb7jN9gbsbynfkwrSH2CnCAYwbSPSZlfhEOO7LALzyLVXELAxYZplGVSs 9eQLeeoMNFw+24QamdxaEBVC3Zmp7IhO/0oJSYOe2Zcs97q8Re058j1ncd6p4jw6 QbBemi1WhuAtr+ZWYWPoQAsPOPscLa61+DEQIEl12ZwMieu8aBORm1cRVvItC6Ir bSUmZieY9Y3wNdpVVpDhc/+VdSvOgTPOwE0EVI15FQEIAJaan6TouRjj97Lt4Du6 ZhVzbaLJWoARebLANjMSN7BjBFyNOsf83HUSrCMgO5b4EESgwtFk4cKCaOjodGZY i61xhUK32J6iS6W2Siv0EGhBU+Ij5OnnU6nTaJ+QZysRA1mLurd+Y62EVnBno0md RsDZvJxopnygKW8MJCPoCMTJ0E+dLvdRoSgOyqwZWNnAKF84yDk7IWb3RCOkjDyb S4NVwLMop/GrdP/Pu3JGC5whR7zgTMG64kERISMr+EXSdHYsOHVKEPb0VasVlI1V UJW7VRhksBrJ/ygoocekz7CF+MRg7hewOlXjNDXkD4PXkdGIdHoB1/g8O08zUMLC CCMAEQEAAcLAXwQYAQIACQUCVI15FQIbDAAKCRDuJmS0DljaQ8YTB/9Y2NPLfPvi 8uYfJxWwVdehDxbX7znyZHIB3RrwljNjfEHsJW2ojcfLz3hBzDgfobv30DU4v0HU R4DxiPdo7PQ1tTJ/kZb6Ki2veHz4ogI5hnfj8FBo4vN28M2ZGgYef415POEXt5J6 I8qLaN7H41Wh2GM5UZfDwSFgaR5ku/KccRuiIszhNvI9tVH0ex1WooZVMPEpITed qajeS+1jqzJEUiJTPlbMl9gC6pu3qbdPEMRvywD2nNou6GZ+clFzXYfk1VkRmYT8 SQkVOWQ/jCdnI5J/+vb9V3SIdq4HC/ntyljocUUx7uu8rizswTnNy04SXLkLo0K7 Vlo211S6oNI8 =3DAOQG -----END PGP PUBLIC KEY BLOCK----- --------------ko6Cmu0PCtP0NZuJfi6Znwyi-- --------------AIuDU7rUiBG9EiJhqomXg1Ao-- --------------MAScTPHOAZ0aWsrgkqUJNYhQ Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmIdCl4FAwAAAAAACgkQ7iZktA5Y2kO1 WQf+KXiKMU7MkiubzDxOuRWCmHDygxLMyY4YG4p4HacYJOcFh+SJPQDwOr6jIg/B2GLrdb+7g/QK y8oE0zhdbeUM4YobqE0IuklMIWu9ckygTsLKT6psITWMvjsXhplkBC4TzbiFBPQ9BEzwLW/90eSP Jnq00Q49a4Ok++eJxDzEZNchpz+4J6pM9Zu58cxRXqyhbvloB+Lu1HUxyxvxBMMX/gVZQ32ymEdT RQaVBQwPPBtuxNwBrJzCruDfxMNdeKLCIsDaAwv7RJhUqxP0jqa7DXowRzRdYWi8/93Mtax/rzlP mfpZIQJ6/pPdWmLbi3ofKw07PDrOUpUWKsbHtLvw8A== =pv8v -----END PGP SIGNATURE----- --------------MAScTPHOAZ0aWsrgkqUJNYhQ--