From nobody Fri Apr 1 11:18: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 604D13A111F; Fri, 1 Apr 2022 11:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=IYOB+4ke; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=IYOB+4ke 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 9fDR7F95fx1U; Fri, 1 Apr 2022 11:18:06 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on0615.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::615]) (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 051413A1255; Fri, 1 Apr 2022 11:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O0PkCzqgaFuvcHlaLv1lgrJK7cwu0MJtxhpjaN2AXBY=; b=IYOB+4keyFW/dFU86uYvadH48WCwmBSnifJ/+o+K9kkTomd+V2xkHEc8uL9RqXFmroApheraGC7+3CcV2Ur5awJsbyb1cZjDS1RKm5b+MhIjdPdzd7KkzMvoDVYnkGRBaWmer3Os1ByOOvKF1u+TFJ0g/k+3PYKzyIHUYiK2rF4= Received: from AS9PR06CA0347.eurprd06.prod.outlook.com (2603:10a6:20b:466::33) by AM0PR08MB4259.eurprd08.prod.outlook.com (2603:10a6:208:145::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.19; Fri, 1 Apr 2022 18:17:59 +0000 Received: from VE1EUR03FT045.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:466:cafe::47) by AS9PR06CA0347.outlook.office365.com (2603:10a6:20b:466::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.29 via Frontend Transport; Fri, 1 Apr 2022 18:17:59 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT045.mail.protection.outlook.com (10.152.19.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.19 via Frontend Transport; Fri, 1 Apr 2022 18:17:58 +0000 Received: ("Tessian outbound 9511859e950a:v118"); Fri, 01 Apr 2022 18:17:58 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 8408f5b99a3c08fa X-CR-MTA-TID: 64aa7808 Received: from dba2269c0b6f.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 7295113E-D435-46C3-AF11-CBCCC86048C2.1; Fri, 01 Apr 2022 18:17:52 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id dba2269c0b6f.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 01 Apr 2022 18:17:52 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TcljTwBh/HxCEmM9J01QCPsmiuy3ve6zYpBHh4gXWID0Ztu9kchuZbXUiF9Kd/IwYMm7wPwVJwD3vM78fI8A2KCn0MKVuwxJJR6bLl1RI2wC9pcMGFCICZP89/sMZLYYLxlFYHZWD+1q3FKHXdGURyjbvi0mmKnbxnqpOzw2NEm6TgTHsVtkpSSc3USAuf9qcqk2QIdyOMZpRWQ0oBS4pJcaGuDx2qOboD//vWGE6rW8j3L5AYNPzN5E4nIiz1FVvskIf+M/lzYNr0E2U5RFSbPagRx0DF5V5bGrlCxHOA2RkD18l1DFVK9b8sgLkRrYJLTQTBKs3yr2s0jeCWabhw== 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=O0PkCzqgaFuvcHlaLv1lgrJK7cwu0MJtxhpjaN2AXBY=; b=lwkTgUA71OIjdTgXkj2IxqcNw1wJyX4wAnWKYWaPdRIWAjoOhtU+jnIU8m0krcIoPiKV07vbaY4XnW9MoEY/cHff0U7NU08QLbJWke3uxcNl9rXMqW9XdeJb7Sft1KOk8SVPbr8mHw7mldz80mjihdqgaa0NFje+R5vwLo7zqiUuxmaNxY6g+4JlYbTTQGA4YzHFLafkVUkWeiivi8t+PnWxBOTy21SqjGzMDBt6QhnBR5Hf1zU1jjvVBkaeo2aXRLESHCVbkf+4gMCE9XQJHIOGeXeh421r4seCgxRcFpmQsMFdQQfxLZjEgM2MVedw1nyWBuxOVKCFepZFpbiymg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O0PkCzqgaFuvcHlaLv1lgrJK7cwu0MJtxhpjaN2AXBY=; b=IYOB+4keyFW/dFU86uYvadH48WCwmBSnifJ/+o+K9kkTomd+V2xkHEc8uL9RqXFmroApheraGC7+3CcV2Ur5awJsbyb1cZjDS1RKm5b+MhIjdPdzd7KkzMvoDVYnkGRBaWmer3Os1ByOOvKF1u+TFJ0g/k+3PYKzyIHUYiK2rF4= Received: from DB9PR08MB6524.eurprd08.prod.outlook.com (2603:10a6:10:251::8) by DB6PR0801MB2117.eurprd08.prod.outlook.com (2603:10a6:4:2e::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.28; Fri, 1 Apr 2022 18:17:49 +0000 Received: from DB9PR08MB6524.eurprd08.prod.outlook.com ([fe80::3855:7d6a:1c7a:3caf]) by DB9PR08MB6524.eurprd08.prod.outlook.com ([fe80::3855:7d6a:1c7a:3caf%7]) with mapi id 15.20.5123.021; Fri, 1 Apr 2022 18:17:49 +0000 From: Thomas Fossati To: Michael Richardson , "uta@ietf.org" , "core@ietf.org" , "iotops@ietf.org" Thread-Topic: [Uta] comments on draft-ietf-uta-tls13-iot-profile-04: Thread-Index: AQHYQQ8SXUD3S8GbJUG5aEyBI3Kt16zbZrUb Date: Fri, 1 Apr 2022 18:17:47 +0000 Message-ID: References: <59686.1648298525@dooku> In-Reply-To: <59686.1648298525@dooku> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-MS-Office365-Filtering-Correlation-Id: 6e92082e-adf5-4a4d-f98c-08da140bf3a2 x-ms-traffictypediagnostic: DB6PR0801MB2117:EE_|VE1EUR03FT045:EE_|AM0PR08MB4259:EE_ X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: AeJc+NkWoEmZfzAwrqBOUpgIKLxlYx5i4NWDAY3zfQdWMrDs8juuqIjBE4CHC2alr8kSJ2jDjJKGLSlf2cluvflWPWTu+dY6VxdGkYzRSpLkxAc+5xIlXXn3RhVOGH9JERzQKIUA9UQ1OgdS6/D6OJw1Imq17Zf2l4A97jsVNMn8mRM/O9yAZO0Kt0sRv6m7Xc+KPQAv3EwUnlcOfu4kgK80m+7u6tIVMp28jAw8SqciTG2G8IDg8KsVLzQKTR4LaulH9u3z1w5sraPrHj8wYk+SDx5gWfpCnG0z0y5MLhIn0q4QXEEKEY8H1tGYX7+K28mvz6NCZSh5InmMGIHL2USh/FsBtijMM3GiKiOzvfkJo4s2hJ22UwJplSmjzQwdLvRzpAFo7LgWjNhl5+sZG/eAdAAlvJwayGC5iNHm4WdNgqTe+kx8lh1Dz4TnPIyZbO7pRt/Gx5Er4xTA6/fFX2R0uqtOoNeMQKE2Spq2rhA9eXnh2FotTSpG1dVGDp99YCVKPIn40+Zo7CMUJZEhXpITVK6p4D4Vvmh2wQAUZJuaF/iwnDDPHCLjRllFGjfmXkjYhSR04gxwofK0U5crifXmxDRxiKFCFzIM7fhBlnRqbXmswf8o4qZTolFypY+gKMEnYDxubz6pu3ggf4fq/lxdayi/7fOmrn5VOzSgCDkk6NAG/O5HZw1BNI7xazgdRDn6T3CSUsRJHYrb1oJGktHr4fVMIM3rX4FZAH794V/lfXA9RoI3C4axDfSm4m9wIK85/RPA5U3MPClwxM4jw8nSBlNjRUTudzoGXxwwMEcHBOYmVh6azuyw7ULA76z+ywua8ZggfTWFbBDg70H/RQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR08MB6524.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(66574015)(52536014)(86362001)(71200400001)(4326008)(66446008)(8676002)(76116006)(64756008)(38070700005)(66476007)(66946007)(66556008)(91956017)(9326002)(186003)(26005)(2906002)(316002)(33656002)(9686003)(7696005)(6506007)(55016003)(5660300002)(8936002)(508600001)(83380400001)(966005)(122000001)(110136005)(38100700002); DIR:OUT; SFP:1101; Content-Type: multipart/alternative; boundary="_000_DB9PR08MB652404F2CC3773FA66BC89229CE09DB9PR08MB6524eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB2117 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT045.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 645b528f-bc41-4eda-acb5-08da140bedaf X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Zdt5aBZuffHHNeCj6RhEXAGKSBJdDYyWMVns/SzTCA3ZUZD2/GBJ8aAD8uUyzudTRasEQi2bOIhSrtouzNUtdLBlxnLbBxJeiAx1dGKWFPxsEJuXvrH/vJs4nlgDzxjBQGqv1EAQZRyrNIwHzCvEY9LUKdBgPVbzWsql+69Inf/9pIqupKwM4nqGvCYbHZ8UzK345nzJVeLsSQuLUlIGvKJWsYF2LnhVYoLihiBvu2xY4Cvb/OTHbn9dkKoJ1LWIuCU+n18BEa4+kzeqDZaHp8iJImBh169TERrWc0f7KCyUjEdozVO0Ymou2nbR5+cV0abgH5qqbS9xSCXAjGcLoXf0A3OqYvLTDa4q4rum0EaPLu9Ges1u9Xp9GhMTp9F4hhrMPqdHPnqyWyOHn9jQdruINl/+/k34+z/AfR/aCOd9t35rEuxsVGPvwmyRjlh7mKx45SJmVqLt/D5rDn7WpVITMTyTuMzUz4ZQO8Xlg1g0f5lcrK533PyqfKAT0DXYMOUW0ViF1xUTD9yLZ6zq2ZoYd7W02OtVdKC9rdECZTLy0y7x2WULrAT/fG3iHeWWqeRFinvyY4kr2UkY03fI0gRSCyyj/+83fMHno+BNrzmbmlYJ3zzHDYZilePxGCEubh/oMKVZ34cgD9LNNWZgGjfzMia1ORcRgn7VfcC8WvV00vMCjjngQyCCIiIuFI6/qfrAKPyo6ds/oiuO8KYnV2NVyhASGzCLaKkKjBySES43/s6/pQ+CzkqB96Vez627YnUj8FdbMlA5Wy4R3Fj8OdkwWowLIUNBrTqC48L51Ho= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230001)(4636009)(40470700004)(46966006)(36840700001)(40460700003)(82310400004)(2906002)(33656002)(966005)(36860700001)(316002)(356005)(110136005)(6506007)(9686003)(450100002)(70206006)(5660300002)(8936002)(86362001)(26005)(83380400001)(9326002)(52536014)(55016003)(508600001)(4326008)(7696005)(186003)(336012)(70586007)(47076005)(8676002)(66574015)(81166007); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Apr 2022 18:17:58.9055 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6e92082e-adf5-4a4d-f98c-08da140bf3a2 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT045.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4259 Archived-At: Subject: Re: [core] [Uta] comments on draft-ietf-uta-tls13-iot-profile-04: 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, 01 Apr 2022 18:18:11 -0000 --_000_DB9PR08MB652404F2CC3773FA66BC89229CE09DB9PR08MB6524eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Michael, Thanks a lot for the great input. > Michael Richardson wrote: > > 1) I feel that the 4.25 Too Early allocation for CoAP could use a bit > more explanation, and probably there needs to be some more clear > review at CORE. (maybe it already happened and I missed it?) I sent an email to CoRE [1] a while ago to try and get some informed reviews but no one replied. I will re-send. [1] https://mailarchive.ietf.org/arch/msg/core/Dair8lAqEZ1h8xU6jsz053aqcOg/ > Reading through the lines, it appears that a server that can't > handle early data needs to send an error code. But such a server > probably doesn't know about the error code. The option is marked critical so if the server does not understand, it will reject with 4.02. If it understands it and does not want to serve the resource (say, because there is some associated state change) it will reject with 4.25 (or whatever number IANA will assign to this response code). In either cases, the client will not repeat an "early data" request for that resource. > I would have thought it should just hang on to the data until the > (D)TLS negotiation is complete. That's an implementation choice. > I'm also concerned that this requires too much cross-layer > communication between DTLS layer and CoAP layer. It doesn't seem the case to me: the indication is carried within the CoAP request so it just flows end to end from an application endpoint to the other. But maybe I am missing something. Can you unpack your concern a bit more? > 2) A long thread at LAMPS two years suggests that the term > "Intermediate CA" applies only to cross-certification authoritiy > bridges, and the term "Subordinate CA" should be used. That this > is consistent with history going back to RFC4949. Noted [2] [2] https://github.com/thomas-fossati/draft-tls13-iot/issues/20 > 3) While section 10 on SNI does not say *how* to use DoH or DPRIVE to > provide for confidentiality of names that are looked up, a naive > use of DoH with Google/Cloudflare/etc. by IoT devices would be a > problem for almost all enterprises that wish to filter the DNS used > by IoT devices, and to use DNS canaries to identify malware. > > Given that such an involved discussion is not in scope for this > document, it might be better just to refer to the ADD WG without > mentioning specific solutions. > I am, in general, not convinced that encrypted SNI serves any purpose > for most IoT devices. Noted [3] [3] https://github.com/thomas-fossati/draft-tls13-iot/issues/21 > 4) section 15 > There is much discussion about what goes into the certificates. I > didn't really understand why that is in this document. Validation > of server certificates is well covered in RFC6125, I think. Section 15 is an attempt to clean up the cert profile we did in RFC7925. IIRC, John Mattsson asked for this because 7925 was a bit rough around the corners and there were a bunch of things that needed clarification. > Validation of client certificates (whether factory provisioned > IDevIDs, or locally enrolled LDevIDs) is a topic that I care a lot > about, and this text is inadequate. > > As the (industrial) IoT market embraces IDevID certificates, there is > some concern that different markets will put different requirements on > IDevID contents. So far it does not appear that anyone has created a > situation where a single (fat) IDevID certificate couldn't be used in > a variety of market verticals, the concern remains. > > It was my intention to introduce a document about this issue. I think > that it's something that only the IETF can do. Perhaps that would fit > into this UTA document, or perhaps parts of this section 15 goes into > another document. This looks to me like it'd be a great addition to this document. I've opened [4]; we can discuss about scope there if you want. Cheers, thanks again! [4] https://github.com/thomas-fossati/draft-tls13-iot/issues/22 IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_DB9PR08MB652404F2CC3773FA66BC89229CE09DB9PR08MB6524eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Michael,

 

Thanks a lot for the great input.

 

> Michael Richardson <mcr+ietf@sandelman.ca> wrote:

>

> 1) I feel that the 4.25 Too Early allocation for CoAP could us= e a bit

>    more explanation, and probably there needs t= o be some more clear

>    review at CORE.  (maybe it already happ= ened and I missed it?)

 

I sent an email to CoRE [1] a while ago to try and get some informe= d

reviews but no one replied.  I will re-send.=

 

[1] https://mailarchive.ietf.org/arch/msg/core/Dair8lAqEZ1h8xU6jsz0= 53aqcOg/

 

>    Reading through the lines, it appears that a= server that can't

>    handle early data needs to send an error cod= e.  But such a server

>    probably doesn't know about the error code.<= o:p>

 

The option is marked critical so if the server does not understand,= it

will reject with 4.02.  If it understands it and does not want= to serve

the resource (say, because there is some associated state change) i= t

will reject with 4.25 (or whatever number IANA will assign to this<= o:p>

response code).  In either cases, the client will not repeat a= n "early

data" request for that resource.

 

>    I would have thought it should just hang on = to the data until the

>    (D)TLS negotiation is complete.

 

That's an implementation choice.

 

>    I'm also concerned that this requires too mu= ch cross-layer

>    communication between DTLS layer and CoAP la= yer.

 

It doesn't seem the case to me: the indication is carried within th= e CoAP

request so it just flows end to end from an application endpoint to= the

other.  But maybe I am missing something.  Can you unpack= your

concern a bit more?

 

> 2) A long thread at LAMPS two years suggests that the term

>    "Intermediate CA" applies only to = cross-certification authoritiy

>    bridges, and the term "Subordinate CA&q= uot; should be used.  That this

>    is consistent with history going back to RFC= 4949.

 

Noted [2]

 

[2] https://github.com/thomas-fossati/draft-tls13-iot/issues/20

 

> 3) While section 10 on SNI does not say *how* to use DoH or DP= RIVE to

>    provide for confidentiality of names that ar= e looked up, a naive

>    use of DoH with Google/Cloudflare/etc. by Io= T devices would be a

>    problem for almost all enterprises that wish= to filter the DNS used

>    by IoT devices, and to use DNS canaries to i= dentify malware.

>

> Given that such an involved discussion is not in scope for thi= s

> document, it might be better just to refer to the ADD WG witho= ut

> mentioning specific solutions.

> I am, in general, not convinced that encrypted SNI serves any = purpose

> for most IoT devices.

 

Noted [3]

 

[3] https://github.com/thomas-fossati/draft-tls13-iot/issues/21

 

> 4) section 15

>    There is much discussion about what goes int= o the certificates.  I

>    didn't really understand why that is in this= document.  Validation

>    of server certificates is well covered in RF= C6125, I think.

 

Section 15 is an attempt to clean up the cert profile we did in RFC= 7925.

IIRC, John Mattsson asked for this because 7925 was a bit rough aro= und

the corners and there were a bunch of things that needed clarificat= ion.

 

> Validation of client certificates (whether factory provisioned=

> IDevIDs, or locally enrolled LDevIDs) is a topic that I care a= lot

> about, and this text is inadequate.

>

> As the (industrial) IoT market embraces IDevID certificates, t= here is

> some concern that different markets will put different require= ments on

> IDevID contents.  So far it does not appear that anyone h= as created a

> situation where a single (fat) IDevID certificate couldn't be = used in

> a variety of market verticals, the concern remains.=

>

> It was my intention to introduce a document about this issue. = I think

> that it's something that only the IETF can do.  Perhaps t= hat would fit

> into this UTA document, or perhaps parts of this section 15 go= es into

> another document.

 

This looks to me like it'd be a great addition to this document.

I've opened [4]; we can discuss about scope there if you want.=

 

Cheers, thanks again!

 

[4] https://github.com/thomas-fossati/draft-tls13-iot/issues/22

 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_DB9PR08MB652404F2CC3773FA66BC89229CE09DB9PR08MB6524eurp_-- From nobody Sat Apr 2 13:11:57 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 1188D3A1239 for ; Sat, 2 Apr 2022 13:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 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 lDd0pJnTaNJC for ; Sat, 2 Apr 2022 13:11:50 -0700 (PDT) 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 09D7B3A1233 for ; Sat, 2 Apr 2022 13:11:47 -0700 (PDT) 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 4KW7V8114RzDCbH; Sat, 2 Apr 2022 22:11:44 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 670623103.579659-b2ebad0c660b1768b2da3e8b4fb1b5b1 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Sat, 2 Apr 2022 22:11:43 +0200 Message-Id: <390A7518-0E4D-4D91-AC4F-46307AC43EAD@tzi.org> To: "core@ietf.org WG (core@ietf.org)" X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [core] =?utf-8?q?=F0=9F=94=94_WG_last_call_for_draft-ietf-core-g?= =?utf-8?q?roupcomm-bis-06?= 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, 02 Apr 2022 20:11:55 -0000 In our IETF113 CoRE meeting, we diagnosed = draft-ietf-core-groupcomm-bis-06 as ready for WG last call. So: This starts a WG last call for = https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/06/, = ending on 24:00 UTC on Tuesday, April 19, 2022. Please indicate your position in a message to the CoRE mailing list = (core@ietf.org) or, exceptionally, to the chairs (core-chairs@ietf.org). Preferably, start a new email thread for each major issue that will need discussion and make sure the subject line includes the draft name and some sort of name for the issue. (Minor issues such as typos can also be sent to the authors.) In addition to the email list discussion, reviewers could consider = opening new issues or PRs on the Github repo of the draft as a courtesy = to the authors: https://github.com/core-wg/groupcomm-bis If you read the draft and think it looks fine, please send a one line=20 email to the list or to the chairs letting us know that so we can get=20 a feel of how broad the review has been. (To reviewers and authors:) If you are aware of any patent claims that might apply to systems that implement these drafts, please review BCP 78 and BCP 79 and make any appropriate IPR declaration before the last-call ends. If you are not sure whether you need to make a declaration or not,=20= please talk to the chairs. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Apr 3 13:01:48 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 5AE633A1371; Sun, 3 Apr 2022 13:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 (2048-bit key) header.d=sandelman.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBlglF7Mlw-V; Sun, 3 Apr 2022 13:01:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB3E3A119A; Sun, 3 Apr 2022 13:01:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A56CE38A37; Sun, 3 Apr 2022 16:12:34 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DvYc2XoKCRz0; Sun, 3 Apr 2022 16:12:33 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D577E38A23; Sun, 3 Apr 2022 16:12:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1649016753; bh=XEgkMuizH8lbJ/xjstk1WezNBHS4EtOUOJnwi1R3SGQ=; h=From:To:Subject:In-Reply-To:References:Date:From; b=AxNpqknsOYZT1zGf5FmS0EIYqDBHPxhYy8Ip3vpnlrKY46L4alVwx6cjGgDNEUcVR 9P9ykxaG6nxwkBGdGlrJB7po2vOfSELy3yJcLphQdS28/JIBJYxutBAiiog9hVhXA/ TYx4IASB/opHC+D2VC98/wnXCJ6tH6O/T0rr3JcCY3pyBKKzMWvikO81t273Tttub3 TlCnoHYFoJD5ZBvsPUEfHT9npDKysE+Q+Z4/Nc97sYpecUBPpZP+e9GBVmvMXfXRZr taQpZD+bA1E27ZDl4uYhOLI/Ue2XQOikCfaTSBYd8FSyDeDd7pSj4cEwMLTMssk3VE D0PUAOz1aWoaQ== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 74E9D774; Sun, 3 Apr 2022 16:01:32 -0400 (EDT) From: Michael Richardson To: Thomas Fossati , "uta\@ietf.org" , "core\@ietf.org" , "iotops\@ietf.org" , Hannes Tschofenig In-Reply-To: References: <59686.1648298525@dooku> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] [Uta] comments on draft-ietf-uta-tls13-iot-profile-04: 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: Sun, 03 Apr 2022 20:01:46 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thomas Fossati wrote: >> Reading through the lines, it appears that a server that can't >> handle early data needs to send an error code. But such a server >> probably doesn't know about the error code. > The option is marked critical so if the server does not understand, it > will reject with 4.02. If it understands it and does not want to ser= ve > the resource (say, because there is some associated state change) it > will reject with 4.25 (or whatever number IANA will assign to this > response code). In either cases, the client will not repeat an "early > data" request for that resource. Okay, I understand this. I wonder if this is significant enough a feature that it justifies the complexity in the client. >> I'm also concerned that this requires too much cross-layer >> communication between DTLS layer and CoAP layer. > It doesn't seem the case to me: the indication is carried within the = CoAP > request so it just flows end to end from an application endpoint to t= he > other. But maybe I am missing something. Can you unpack your > concern a bit more? The DTLS layer has to pass the early data up to the CoAP layer so that it c= an reject with 4.02. If it can do that, then it can probably just be coded to process early data. In my server side, the DTLS layer is buried down in openssl C code, while t= he CoAP layer is in ruby. >> Validation of client certificates (whether factory provisioned >> IDevIDs, or locally enrolled LDevIDs) is a topic that I care a lot >> about, and this text is inadequate. >> >> As the (industrial) IoT market embraces IDevID certificates, there is >> some concern that different markets will put different requirements = on >> IDevID contents. So far it does not appear that anyone has created a >> situation where a single (fat) IDevID certificate couldn't be used in >> a variety of market verticals, the concern remains. >> >> It was my intention to introduce a document about this issue. I think >> that it's something that only the IETF can do. Perhaps that would f= it >> into this UTA document, or perhaps parts of this section 15 goes into >> another document. > This looks to me like it'd be a great addition to this document. > I've opened [4]; we can discuss about scope there if you want. I'm concerned about slowing your document down too much, but perhaps the timing is okay, and it might also help in getting external to the IETF revi= ew of this profile. When/if we are ready, I think that DANCE should be asked to review. but, yes, let's discuss more. I'll try to send some proposed text in the next two weeks. Even if it doesn't go into this document, then it might form the basis of another document. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmJJ/RwACgkQgItw+93Q 3WWB2gf+LFY1an5yWQqg4mn1GrJDT1esb9+jW7NmqsvVUFO7kO5Xsps64re88alE TI0mIkyNpI7eBeoNRZSBd3/OtrdoqBOLwJZgLKn/cHY5NbT+Sq320k6O8DzmGWqA osLf2ohrequSTDKDfLyGo3dnZVfFLSWDviEmovLqpptPmE8sUC23Bi4o1yd4Pst6 ZXGcnIjdskJeC4/mRro8TQlXg1yBxSccD1LIi+et7fM5PxXIXVoD8GqkUdc29XvC zruluDi7H/wwdos6AfPESvxFdm6qy1qprYayP7hoHsRLLQcNFc5ofGKLR3LUufTW iggkQhvBvM+PdS1wSBz+ueOfQhIQYg== =cQYk -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Apr 3 15:06: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 D46673A15B0; Sun, 3 Apr 2022 15:05:55 -0700 (PDT) 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=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 4cPlkU6xUZ4i; Sun, 3 Apr 2022 15:05:49 -0700 (PDT) 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 723573A15FF; Sun, 3 Apr 2022 15:05:43 -0700 (PDT) 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 4KWnz71bWBzDCbv; Mon, 4 Apr 2022 00:05:39 +0200 (CEST) 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: <390A7518-0E4D-4D91-AC4F-46307AC43EAD@tzi.org> Date: Mon, 4 Apr 2022 00:05:38 +0200 Cc: draft-ietf-core-groupcomm-bis@ietf.org X-Mao-Original-Outgoing-Id: 670716338.5040849-c8bfea57a228dabb454222cd5680bc73 Content-Transfer-Encoding: quoted-printable Message-Id: <2839842C-0FED-4624-8617-2D708B3B9FF2@tzi.org> References: <390A7518-0E4D-4D91-AC4F-46307AC43EAD@tzi.org> To: "core@ietf.org WG (core@ietf.org)" X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [core] Chair review for draft-ietf-core-groupcomm-bis-06 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: Sun, 03 Apr 2022 22:05:57 -0000 Chair review of draft-ietf-core-groupcomm-bis-06.txt Carsten Bormann 2022-04-03 ## Major The document oscillates between normative content and extensive examples, which almost take the form of a HOWTO. I think the text could benefit from a better separation between these two. To achieve some of this, some of the more extensive sequences of examples could also be turned into an appendix, e.g. in 2.2. In several places, the document relies heavily on draft-tiloca-core-groupcomm-proxy supplying solutions for what it itself needs to leave open. I believe we should at least have accepted that as a WG document before we pass on draft-ietf-core-groupcomm-bis to the IESG. More generally speaking, the document often is not much more than a pointer to other documents -- which in itself is valuable, but tends to dilute the normative content, which now needs to be searched with a loupe. The document would benefit from a crisp summary of where it updates 7252 (and 7641), and specific indications in the places where it does. E.g., are the SHOULDs in 3.6 updates to 7252? ## Minor (I send an annotated text file to the authors; maybe they can process this before we come up with non-trivial questions or changes.) The document is a bit uneven in its expression how NOT RECOMMENDED NoSec is -- it starts out by saying this outright, but then gradually takes it back in several places. The special significance of "NoSec" as a text string is not really explained -- where are these group identifiers used? In the software update section (A.3), please add appropriate references to the SUIT work. ## Nits Small fixes went right into the PR https://github.com/core-wg/groupcomm-bis/pull/33 Gr=C3=BC=C3=9Fe, Carsten > On 2022-04-02, at 22:11, Carsten Bormann wrote: >=20 > In our IETF113 CoRE meeting, we diagnosed = draft-ietf-core-groupcomm-bis-06 as ready for WG last call. So: >=20 > This starts a WG last call for = https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/06/, = ending on >=20 > 24:00 UTC on Tuesday, April 19, 2022. >=20 > Please indicate your position in a message to the CoRE mailing list = (core@ietf.org) or, exceptionally, to the chairs (core-chairs@ietf.org). >=20 > Preferably, start a new email thread for each major issue that will = need > discussion and make sure the subject line includes the draft name and > some sort of name for the issue. (Minor issues such as typos can also > be sent to the authors.) >=20 > In addition to the email list discussion, reviewers could consider = opening new issues or PRs on the Github repo of the draft as a courtesy = to the authors: >=20 > https://github.com/core-wg/groupcomm-bis >=20 > If you read the draft and think it looks fine, please send a one line=20= > email to the list or to the chairs letting us know that so we can get=20= > a feel of how broad the review has been. >=20 > (To reviewers and authors:) If you are aware of any patent claims = that > might apply to systems that implement these drafts, please review BCP = 78 > and BCP 79 and make any appropriate IPR declaration before the = last-call > ends. If you are not sure whether you need to make a declaration or = not,=20 > please talk to the chairs. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Mon Apr 4 03:03:17 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 C58523A2002; Mon, 4 Apr 2022 03:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=XW4McF22; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=XW4McF22 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 LWDEt4BC8BYJ; Mon, 4 Apr 2022 03:02:47 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2060d.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1b::60d]) (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 4CAB23A1B43; Mon, 4 Apr 2022 03:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kPt2K9+Tq5ZpPHc/65pg+R4NuKVTBn5KewAuCLN/Ewo=; b=XW4McF22t2Fz8fnvfRxwh3JeYQoyWJPRCR9fNX2xzJJhWBUE1v2aav0k0PPV4dHukQd+7S7l20RVppfEf8cXv4I38zUoPnLoYxusBSrw95X5DX83rt1gc6YZ6/jB1RdREzgy0qFQ2Mc5T17PcRQUQl3y/16CKv1g7Ikghn8MCEw= Received: from AM6PR0502CA0037.eurprd05.prod.outlook.com (2603:10a6:20b:56::14) by DB8PR08MB5193.eurprd08.prod.outlook.com (2603:10a6:10:e6::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.31; Mon, 4 Apr 2022 10:02:39 +0000 Received: from VE1EUR03FT064.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:56:cafe::9e) by AM6PR0502CA0037.outlook.office365.com (2603:10a6:20b:56::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.31 via Frontend Transport; Mon, 4 Apr 2022 10:02:39 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT064.mail.protection.outlook.com (10.152.19.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.19 via Frontend Transport; Mon, 4 Apr 2022 10:02:39 +0000 Received: ("Tessian outbound 9613c00560a5:v118"); Mon, 04 Apr 2022 10:02:38 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 03c513e11c488134 X-CR-MTA-TID: 64aa7808 Received: from 771bfa8f1e63.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8997AACE-5466-4452-88E3-22621556381E.1; Mon, 04 Apr 2022 10:02:32 +0000 Received: from EUR03-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 771bfa8f1e63.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 04 Apr 2022 10:02:32 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kzFxCZ1aoSEcr/7qtat/yHmaDW3CWcFO14rmVmNw/hzRR/zJWVUaVGTLXHgvMVFHqlqTtCZ2MMIGJt/6Ngjv16QpoLI2T79p4Iu0e2PWGN/Z8xKkNtA3AjD1wKkV8/c4j8aDzBdxA7XG947ivtmIhENv3hobENhk8vaclllLCdZVwxCJtXf6LHK8jTaODE2HKhw6xLi8/QVpZPUmPTHjHkHzeV+BbRgJt+unzI4fTybG8rUFWOvbPno5QYJpAetorvF/S8G7qqNtalaOumaUoaK+nkIhoyVga8040IMt9CKGLgewxLYuB6EXta732BWpFSEf1LbJSoGDCy4zet+OMA== 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=kPt2K9+Tq5ZpPHc/65pg+R4NuKVTBn5KewAuCLN/Ewo=; b=S1grLLojBfaBKHzcd4+dlFwM4EIWZVMuLfj8yUurCdc2T/vO9xsG+qMzik7fTBcAsuoJy4VNeXAFQ3mkt0eNEsEakrQt4JXZ4xgu1lNga/DLV63d/VMxywMj69/p4bPmN3A3C2vedNtk5lzXyIluOjFD5zj2zgpcvKP5XyhmpNoWJdLqbhLVYxvxocMjR22Bp4raWWGF1egDc6+M93ioTbmVtDWq8og9ZRBwLEjion4FMzmkKw4DekOl2yf4XR03dZe3Pj4hCfDQ7GN2mhjnoYTMBuvw2gKehzPt/OeH4ODO2rHTZ3V1IoMUToI1tGFP93pxEqvDl8LIX6fj6lP5Qg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kPt2K9+Tq5ZpPHc/65pg+R4NuKVTBn5KewAuCLN/Ewo=; b=XW4McF22t2Fz8fnvfRxwh3JeYQoyWJPRCR9fNX2xzJJhWBUE1v2aav0k0PPV4dHukQd+7S7l20RVppfEf8cXv4I38zUoPnLoYxusBSrw95X5DX83rt1gc6YZ6/jB1RdREzgy0qFQ2Mc5T17PcRQUQl3y/16CKv1g7Ikghn8MCEw= Received: from DB9PR08MB6524.eurprd08.prod.outlook.com (2603:10a6:10:251::8) by DBAPR08MB5734.eurprd08.prod.outlook.com (2603:10a6:10:1aa::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.30; Mon, 4 Apr 2022 10:02:31 +0000 Received: from DB9PR08MB6524.eurprd08.prod.outlook.com ([fe80::3855:7d6a:1c7a:3caf]) by DB9PR08MB6524.eurprd08.prod.outlook.com ([fe80::3855:7d6a:1c7a:3caf%7]) with mapi id 15.20.5123.031; Mon, 4 Apr 2022 10:02:30 +0000 From: Thomas Fossati To: Michael Richardson , "uta@ietf.org" , "core@ietf.org" , "iotops@ietf.org" , Hannes Tschofenig Thread-Topic: [Uta] comments on draft-ietf-uta-tls13-iot-profile-04: Thread-Index: AQHYQQ8SXUD3S8GbJUG5aEyBI3Kt16zbZrUbgANCZwCAAOPN+A== Date: Mon, 4 Apr 2022 10:02:30 +0000 Message-ID: References: <59686.1648298525@dooku> <23712.1649016092@localhost> In-Reply-To: <23712.1649016092@localhost> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-MS-Office365-Filtering-Correlation-Id: 286ca84e-afc0-4cbf-5857-08da16224080 x-ms-traffictypediagnostic: DBAPR08MB5734:EE_|VE1EUR03FT064:EE_|DB8PR08MB5193:EE_ X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: TV+2Zd+Em/7y9JKNkGIEgHBV9t2B9jBSMme52WhcFT2h+VIhOkeA+T8py/HYc2o6HT9fWpM+p+kDOYvNst/UeE5FvLFgfXmSS/yy64NH9Dfalxp3AHEHsgvy2/H//7nDqzxpGapUip4phsI+9PRiDSfx3NbY++5Dsd1qeRzMwTEhp1Br5CpocDUrYaeQE5JegqKzwxFefzEg4FYZBQoNxxdjJ6dMzGp+gVho+fTRzU+KxbT8l8qVN/fhbNTpry7adBQU39c28ZvzVj5zR3+eP74jkp0u5n2JTbg5arw3+yyeSS2kj4IKKL66EeaACVSNwk6QK/pQOfiPnFjqMjQjEzDJqWB5Fi+HpzUd6x2ezVr4RwTXAGTkKhhRE1YoolqVKKbGtyHLGFHFWMhyNNsb9Gbef8tjQmrjqmY3FcV0DUaAbULtL1SveMggIw000r6Mc8rwWY2C7q23Zwe6A5Q7+9oGw/2gAoQKlyh1QXrH9etixm9enSd0SgvEKDMI4HKn+MPNRhpiS9Qw9ErwJVu+tKrIfLmkOERtT/nANDPGW2fCl//s6EYsKGoBk5QpiRUiDaVSJJzJHVz7f7YOTK1EJ0hl/bUJRTgMZ7xkZsmrFnc05RD8SPUtqk91DDI/SwVDZhMkZdyFzq3gtf1WCta/CHgS1FAhuVTOpFI+deXhDzK4KeW+HIT9SuC37RxCGSuRxUmcq5zJxv61t4rFp5sGJw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR08MB6524.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(8936002)(86362001)(38070700005)(508600001)(83380400001)(33656002)(53546011)(6506007)(7696005)(9686003)(26005)(186003)(52536014)(110136005)(66556008)(66446008)(64756008)(8676002)(55016003)(38100700002)(5660300002)(2906002)(71200400001)(76116006)(91956017)(316002)(6636002)(66946007)(66476007)(122000001); DIR:OUT; SFP:1101; Content-Type: multipart/alternative; boundary="_000_DB9PR08MB65244E3D456C8B90371BA0E49CE59DB9PR08MB6524eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR08MB5734 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT064.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 4c83795e-b55e-471f-ef61-08da16223b38 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 4R0moFovhUy2YSn51au386SNf6EmkJ7PiCFfgd8qI5ZPSz2Se0oiyZ+Efh+pf7VrEcmezgjzoFL1fYhoLJrfbNwzhJs+YpSi7aJONp5lFSSlAwtrYWcrbT9jC+oLgQnSsTktdrCqzw7CPoaGTfqH6vkgMCCTuy2v+mILP/wm8wtRs2QDAlJ5uXU4cS+KYYL5lp19U/V0meMWMOaJB9xA0VHkvi1yG+RER/f6kOk0BD0igHtA0rFBbrRnqaIg5styKfxGmNzXYY1n3FX3oOiQ3J0tquFPtRI0nxzFYNFjnTYgb7HfJPwJBx7fSusZDPfuPHj+wuGijygE91cCzh2dKXRnQQTWGfffNBBIhc2zmCAFyKGZ5wUw6Vwft5SzM8w0PvpJLusbxn+z/FKyuTF3J4POX60+uPGFxegpccCkvLQQPjGnCWbXVMmrw3akhYXacq/7Gfq/2uDlE/nfKGezuobqffrA8WRYKRyHrDjn0PM0UA/UJD0EbvyDLbhY8ZEIs4kr86MpM8Dq1x8E2yuM8og/oDR88LV3yBN+/Dlos/6m6+pzG5QQDDFi8kukjSIjsGFiItDNTtSDEY2TlqMWqzECr9OQ3XyUY51d4rlfexUhM1Byc1aihBnrVvYKfPcMXhNXYzs3IKchrtTqBap18b/F/25TEY1ghn2OMvYZi+YX4sOYK8oBl5fhhlv043sI X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230001)(4636009)(40470700004)(46966006)(36840700001)(8676002)(110136005)(47076005)(83380400001)(70206006)(70586007)(81166007)(86362001)(316002)(6636002)(356005)(36860700001)(508600001)(450100002)(33656002)(40460700003)(336012)(82310400004)(5660300002)(8936002)(53546011)(52536014)(7696005)(6506007)(186003)(9686003)(26005)(55016003)(2906002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2022 10:02:39.1011 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 286ca84e-afc0-4cbf-5857-08da16224080 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT064.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5193 Archived-At: Subject: Re: [core] [Uta] comments on draft-ietf-uta-tls13-iot-profile-04: 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, 04 Apr 2022 10:02:55 -0000 --_000_DB9PR08MB65244E3D456C8B90371BA0E49CE59DB9PR08MB6524eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > On 03/04/2022, 21:01, "Michael Richardson" wrote: > Thomas Fossati wrote: > >> Reading through the lines, it appears that a server that can't > >> handle early data needs to send an error code. But such a > >> server probably doesn't know about the error code. > > > The option is marked critical so if the server does not > > understand, it will reject with 4.02. If it understands it and > > does not want to serve the resource (say, because there is some > > associated state change) it will reject with 4.25 (or whatever > > number IANA will assign to this response code). In either > > cases, the client will not repeat an "early data" request for > > that resource. > > Okay, I understand this. > I wonder if this is significant enough a feature that it justifies the > complexity in the client. This is a good question, which at the end of the day is for CoRE to decide. RFC8446 says "Application protocols MUST NOT use 0-RTT data without a profile that defines its use." so this is a gap that we are trying to bridge for CoAP here, based on existing experience with HTTP. If the CoRE community doesn't feel this feature is relevant, or they want to punt for now to gather more experience, it's totally fine. We could drop Section 14 and possibly resume it later in a separate doc. I suspect the fact that DTLS 1.3 has not been published yet may be a reason for things moving slower than anticipated in this area. > >> I'm also concerned that this requires too much cross-layer > >> communication between DTLS layer and CoAP layer. > > > It doesn't seem the case to me: the indication is carried within > > the CoAP request so it just flows end to end from an application > > endpoint to the other. But maybe I am missing something. Can > > you unpack your concern a bit more? > > The DTLS layer has to pass the early data up to the CoAP layer so that > it can reject with 4.02. > If it can do that, then it can probably just be coded to process early > data. > In my server side, the DTLS layer is buried down in openssl C code, > while the CoAP layer is in ruby. The thing is that this feature is enabled on a per-resource basis, so it needs to bubble up. It can't be handled transparently by the lower bits of the stack. > >> Validation of client certificates (whether factory provisioned > >> IDevIDs, or locally enrolled LDevIDs) is a topic that I care a > >> lot about, and this text is inadequate. > >> > >> As the (industrial) IoT market embraces IDevID certificates, > >> there is some concern that different markets will put different > >> requirements on IDevID contents. So far it does not appear > >> that anyone has created a situation where a single (fat) IDevID > >> certificate couldn't be used in a variety of market verticals, > >> the concern remains. > >> > >> It was my intention to introduce a document about this issue. I > >> think that it's something that only the IETF can do. Perhaps > >> that would fit into this UTA document, or perhaps parts of this > >> section 15 goes into another document. > > > This looks to me like it'd be a great addition to this document. > > I've opened [4]; we can discuss about scope there if you want. > > I'm concerned about slowing your document down too much, but perhaps > the timing is okay, and it might also help in getting external to the > IETF review of this profile. > > When/if we are ready, I think that DANCE should be asked to review. > > but, yes, let's discuss more. > I'll try to send some proposed text in the next two weeks. > Even if it doesn't go into this document, then it might form the basis > of another document. +1 Let's give it a try, if it explodes we still have a fall back. Cheers IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_DB9PR08MB65244E3D456C8B90371BA0E49CE59DB9PR08MB6524eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> On 03/04/2022, 21:01, "Michael Richardson&= quot; <mcr+ietf@sandelman.ca> wrote:

> Thomas Fossati <Thomas.Fossati@arm.com> w= rote:

>     >> Reading throug= h the lines, it appears that a server that can't

>     >> handle early d= ata needs to send an error code.  But such a

>     >> server probabl= y doesn't know about the error code.

>

>     > The option is mark= ed critical so if the server does not

>     > understand, it wil= l reject with 4.02.  If it understands it and

>     > does not want to s= erve the resource (say, because there is some

>     > associated state c= hange) it will reject with 4.25 (or whatever

>     > number IANA will a= ssign to this response code).  In either

>     > cases, the client = will not repeat an "early data" request for

>     > that resource.

>

> Okay, I understand this.

> I wonder if this is significant enough a featur= e that it justifies the

> complexity in the client.

 

This is a good question, which at the end of the day= is for CoRE to

decide.  RFC8446 says "Application protoco= ls MUST NOT use 0-RTT data

without a profile that defines its use." so thi= s is a gap that we are

trying to bridge for CoAP here, based on existing ex= perience with HTTP.

If the CoRE community doesn't feel this feature is r= elevant, or they

want to punt for now to gather more experience, it's= totally fine.  We

could drop Section 14 and possibly resume it later i= n a separate doc.  I

suspect the fact that DTLS 1.3 has not been publishe= d yet may be a

reason for things moving slower than anticipated in = this area.

 

>     >> I'm also conce= rned that this requires too much cross-layer

>     >> communication = between DTLS layer and CoAP layer.

>

>     > It doesn't seem th= e case to me: the indication is carried within

>     > the CoAP request s= o it just flows end to end from an application

>     > endpoint to the ot= her.  But maybe I am missing something.  Can

>     > you unpack your co= ncern a bit more?

>

> The DTLS layer has to pass the early data up to= the CoAP layer so that

> it can reject with 4.02.

> If it can do that, then it can probably just be= coded to process early

> data.

> In my server side, the DTLS layer is buried dow= n in openssl C code,

> while the CoAP layer is in ruby.

 

The thing is that this feature is enabled on a per-r= esource basis, so it

needs to bubble up.  It can't be handled transp= arently by the lower bits

of the stack.

 

>     >> Validation of = client certificates (whether factory provisioned

>     >> IDevIDs, or lo= cally enrolled LDevIDs) is a topic that I care a

>     >> lot about, and= this text is inadequate.

>     >>

>     >> As the (indust= rial) IoT market embraces IDevID certificates,

>     >> there is some = concern that different markets will put different

>     >> requirements o= n IDevID contents.  So far it does not appear

>     >> that anyone ha= s created a situation where a single (fat) IDevID

>     >> certificate co= uldn't be used in a variety of market verticals,

>     >> the concern re= mains.

>     >>

>     >> It was my inte= ntion to introduce a document about this issue. I

>     >> think that it'= s something that only the IETF can do.  Perhaps

>     >> that would fit= into this UTA document, or perhaps parts of this

>     >> section 15 goe= s into another document.

>

>     > This looks to me l= ike it'd be a great addition to this document.

>     > I've opened [4]; w= e can discuss about scope there if you want.

>

> I'm concerned about slowing your document down = too much, but perhaps

> the timing is okay, and it might also help in g= etting external to the

> IETF review of this profile.

> 

> When/if we are ready, I think that DANCE should= be asked to review.

> 

> but, yes, let's discuss more.

> I'll try to send some proposed text in the next= two weeks.

> Even if it doesn't go into this document, then = it might form the basis

> of another document.

 

+1

 

Let's give it a try, if it explodes we still have a = fall back.

 

Cheers

 

 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_DB9PR08MB65244E3D456C8B90371BA0E49CE59DB9PR08MB6524eurp_-- From nobody Mon Apr 4 04:23:04 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 ECF133A20D9 for ; Mon, 4 Apr 2022 04:23:01 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=jQ/v48M5; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=jQ/v48M5 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 oVQL_m2x1MRv for ; Mon, 4 Apr 2022 04:22:56 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on061b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::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 0C7803A11D4 for ; Mon, 4 Apr 2022 04:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PnCZ24iIUhIPEwS4T/uCq/8CbugsPYsU8SoWsMR9+Ls=; b=jQ/v48M5NzlZxiJZ1wHR/V/AZO0zjVNsZ1Ag0QUbeY0lhZmuYSx1W5DeXCqzYesjwzhjf4ZktZWn5LxUWZ+4Gmy7Z2HBsK1NAMaQ3LbjgIyYO463bOGiPw6JEw/kRi0ew/LTlIPsvV82xtPNYoohvLRG9TgRrQkBuZAtE1k3icg= Received: from AS9PR06CA0164.eurprd06.prod.outlook.com (2603:10a6:20b:45c::15) by AM9PR08MB6998.eurprd08.prod.outlook.com (2603:10a6:20b:419::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.31; Mon, 4 Apr 2022 11:22:48 +0000 Received: from AM5EUR03FT031.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:45c:cafe::1a) by AS9PR06CA0164.outlook.office365.com (2603:10a6:20b:45c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.31 via Frontend Transport; Mon, 4 Apr 2022 11:22:48 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT031.mail.protection.outlook.com (10.152.16.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.19 via Frontend Transport; Mon, 4 Apr 2022 11:22:48 +0000 Received: ("Tessian outbound 2d401af10eb3:v118"); Mon, 04 Apr 2022 11:22:47 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 550f7cf2c113d14a X-CR-MTA-TID: 64aa7808 Received: from bad7e26db8a7.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id D48EC472-AE94-4A19-8863-AD87ED071124.1; Mon, 04 Apr 2022 11:22:41 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id bad7e26db8a7.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 04 Apr 2022 11:22:41 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TXB6DMZscD7p+5iYTVf20d1wAxtN3Zu3izVb0VLt5L+OkihChTR4j70+9sCZxeRlrF0f+pmeg0xf5g2in2fCW0GbyTQucf9l4qTpDUjWC7tDx3EVQFmBe1zXNx//AYmjW4VZnlrAZRZ70nP9iIbBmtDl2gj1PsHgwftUo6FXoK3tA22JB2d4Nfs2Ayc3R0ghDeLaoK7R6NIfr8CBOVxtri4pbCHMoQxGGExFQc9ZuvFFgbn1FpJ2Ljf5+KHXwWMfUkg+wFh215EeSJLEJqjrKDdAMiQzmH5DKE9u0MGmHNESE97nWasPgofcDJXfBjFqfn6KT64iyEiLNcpS+TXttw== 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=PnCZ24iIUhIPEwS4T/uCq/8CbugsPYsU8SoWsMR9+Ls=; b=RgKBowp9U3JNtgtbfqE3FjRtjiJfJPHsWGiuK/nxjbpfTv8YiQ7xCh6hPUuLOpvYE6mm4FFO/QUgsI4VXBt5ksTmHw6+whCeaoI0XEItKDv9BpD6GvBNcG0q9XmjIH+3NjXCYO49KtHYo0HndFJM7Gll1zfBapzF7yCdKOhE/S3WABkw+WIRbI1J3X1bzQBUJj8tXM32S/vGedy1TVyx1usZDn5/Y9r1DVMwM0O4YBme+BiTGueXJaWXX1pZ5lLlFhrh0vh4aUIeyCxFL2p0v1a1zmfJf9meZjKi2dE1x8LuubDYFLVv+KzWwcSSZPr0S9tdN/4bs1UCKtKjR0AQSQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PnCZ24iIUhIPEwS4T/uCq/8CbugsPYsU8SoWsMR9+Ls=; b=jQ/v48M5NzlZxiJZ1wHR/V/AZO0zjVNsZ1Ag0QUbeY0lhZmuYSx1W5DeXCqzYesjwzhjf4ZktZWn5LxUWZ+4Gmy7Z2HBsK1NAMaQ3LbjgIyYO463bOGiPw6JEw/kRi0ew/LTlIPsvV82xtPNYoohvLRG9TgRrQkBuZAtE1k3icg= Received: from DB9PR08MB6524.eurprd08.prod.outlook.com (2603:10a6:10:251::8) by DU0PR08MB7589.eurprd08.prod.outlook.com (2603:10a6:10:31e::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.31; Mon, 4 Apr 2022 11:22:34 +0000 Received: from DB9PR08MB6524.eurprd08.prod.outlook.com ([fe80::3855:7d6a:1c7a:3caf]) by DB9PR08MB6524.eurprd08.prod.outlook.com ([fe80::3855:7d6a:1c7a:3caf%7]) with mapi id 15.20.5123.031; Mon, 4 Apr 2022 11:22:33 +0000 From: Thomas Fossati To: "core@ietf.org" Thread-Topic: 0-RTT (D)TLS in CoAP (was: Re: [Uta] comments on draft-ietf-uta-tls13-iot-profile-04) Thread-Index: AQHYSBZHynM+g36EZEW7F1+FEhsZLQ== Date: Mon, 4 Apr 2022 11:22:33 +0000 Message-ID: References: <59686.1648298525@dooku> <23712.1649016092@localhost> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-MS-Office365-Filtering-Correlation-Id: 0684abaf-f809-4501-97cb-08da162d72d7 x-ms-traffictypediagnostic: DU0PR08MB7589:EE_|AM5EUR03FT031:EE_|AM9PR08MB6998:EE_ X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: EuXJC2xIhrYbp4vlEDvs2PS1PsQdPmvwjPNRiC/NFYx1QL3/9DG6VZALVITmJCfK5iT4D7BGc3byBHXJbsqmh6QKxuOl13xNsPs/nm4ZW6Qt8MNYCkQqTwftW04zyNvyLZ1RjRsjD824qPe1RPA42hxCDrzpnDylviMZDVN1eiwRWgkti113kavNGSn/olJnDCHaZeRK6VhfX6PG+tq7tkcad2q8mhPJ6JFOSGlsMIybqLOUGtjr9sLJ/t9fn++QvET7bF+NY9aO2U6Ck7p/i2M2HhqhDfwEMZcSRFxUbr+vqD5YEKHeQXy8mJ1os9l+qgnO5XA6WqsjwpenxrjYq6DaFZVBv/S8V/zWrxjCrfJZ/jbepaPCXLG3FQhjTr5tZ1H2hExJjMkhpB95qxfHMHsTUBZ6qv1wCVhX4dFBdVy0IX6Pa/DFMczMhfJFqEoCKauDabs98PUR96sSckmothrmEe7w9rGzedP5BFM3C3nycNrvV0KSh4IV6IIRH7WoUaHuVZGU1bobofNU9oWZtbgAvhk2DgaIjLHg8cYRZM7gaZh2qmTWuibyPiV9PSo0uGnlijoBhATcBmWmF9PqKt1vXlIu7j6yU8uXGy2NN26HguT8OV2CRTylieVOaSo/xpsVVS2NHYlogLQQ+Lu4Ef7sscoWAkKE1frx9pTPauk1ZCGxdv91F04Wt+IKwTwDjFpF4A5SJvDVLs/xHVSxjw66YchWm8caTK+XDoWubUy/IsKX0JKUB0Jhw0yFSTyHBfpOrM708lSEgqjIzzJJyinFr38qmoIBposssZ47+Ok= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR08MB6524.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(966005)(5660300002)(508600001)(8936002)(6916009)(52536014)(71200400001)(83380400001)(2940100002)(91956017)(186003)(316002)(26005)(53546011)(66946007)(38100700002)(33656002)(86362001)(38070700005)(122000001)(76116006)(2906002)(7696005)(6506007)(66556008)(66476007)(66446008)(64756008)(8676002)(9686003)(55016003); DIR:OUT; SFP:1101; Content-Type: multipart/alternative; boundary="_000_DB9PR08MB6524E1144577F1D56E108AF69CE59DB9PR08MB6524eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB7589 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT031.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: cde15463-3828-4c62-30c2-08da162d6a4f X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /6dgWE2noISL+a/d4cTuJeqHaCTbzb5jNHgd9rJHofsQCml+R+QmkqrwXB8PkNYNmjdLL0qggdmKpILZ6WM0L0sESodPppq3v64n7X7eN1S5nHAW5o9w+y7VHidWHCBd6nDoh3OFg9c9V2MhRgWLO4JRMVnsBlnrENuraNJ5IIl8pEyGMk1L06H+LuaV51yPP59JQnRFW5z2V2KFk8XDHP9G13PgMZFYC19PhBCUQeLRT5IWtERuSK7YFZMZ3qmOejtZ/BjmqsAZmnVVfulMmW3ik04WNmuQ5Rg/SrsvHCQYKK+7UF/Avvi554DXMLgYjc5gPTRdg44peuAI7qZv/jN/T4SQsWNl0ra9ZYWIwMW3WKZhn7EcBwd276BCcZjznpKpZN0lCshCFNdaiEwWuFKt1MCaI+Y0bOvVM63Cmuhrh6fLxKlSlR9Wcxa+3KEbDwzecWDiadtl+LnFkvPsRVAXfqxrKFdOCmYUwKVciIGrUIq73W69Nv+NKTIMyVl5EAL6ZM0E8K1aAbsX31g5/Lrh0Td4w6vOWnkN0OGYICeYqevsWVw6DU7+JCRV+oEpjT+qmDzYffqNViH2Ilym20S1uEQ46/LjVbkOXGiH9s9z4Hg04NOcLb+EAy7ej/4x4VFfhFTxZKdA5xtvhV67Wmnsx2oy1ZrK0jMXBKzOsCNWR2pT2NHZDAi8uEInokUYBeEdmg8ipzqEqRUZ3sp3KKte++dB/iyvtamqvUoZ+jjBhgG/2pu0wJWJgvAkHE1r X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230001)(4636009)(40470700004)(36840700001)(46966006)(5660300002)(9686003)(966005)(8936002)(86362001)(55016003)(2940100002)(53546011)(2906002)(7696005)(6506007)(40460700003)(33656002)(82310400004)(356005)(81166007)(36860700001)(52536014)(508600001)(336012)(26005)(186003)(47076005)(83380400001)(316002)(8676002)(70586007)(70206006)(6916009); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2022 11:22:48.0855 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0684abaf-f809-4501-97cb-08da162d72d7 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT031.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6998 Archived-At: Subject: [core] 0-RTT (D)TLS in CoAP (was: Re: [Uta] comments on draft-ietf-uta-tls13-iot-profile-04) 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, 04 Apr 2022 11:23:02 -0000 --_000_DB9PR08MB6524E1144577F1D56E108AF69CE59DB9PR08MB6524eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear CoRE folks, I wanted to hear your thoughts about the 0-RTT extensions for CoAP described in draft-ietf-uta-tls13-iot-profile [0]. I tried this before [1], but it looks like there was no interest then, and = I wonder whether the situation has changed in the meantime? Copied below an extract of the relevant piece of the conversation with Michael to give you a bit more context about where this email comes from. Cheers & thanks in advance for your time. [0] https://www.ietf.org/archive/id/draft-ietf-uta-tls13-iot-profile-04.htm= l#name-0-rtt-data [1] https://mailarchive.ietf.org/arch/msg/core/Dair8lAqEZ1h8xU6jsz053aqcOg/ > From: Iotops on behalf of Thomas Fossati > Date: Monday, 4 April 2022 at 11:03 > To: Michael Richardson , uta@ietf.org , core@ietf.org , iotops@ietf.org , Hanne= s Tschofenig > Subject: Re: [Iotops] [Uta] comments on draft-ietf-uta-tls13-iot-profile-= 04: > > On 03/04/2022, 21:01, "Michael Richardson" wrot= e: > > Thomas Fossati wrote: > > >> Reading through the lines, it appears that a server that > > >> can't handle early data needs to send an error code. But > > >> such a server probably doesn't know about the error code. > > > > > The option is marked critical so if the server does not > > > understand, it will reject with 4.02. If it understands it > > > and does not want to serve the resource (say, because there is > > > some associated state change) it will reject with 4.25 (or > > > whatever number IANA will assign to this response code). In > > > either cases, the client will not repeat an "early data" > > > request for that resource. > > > > Okay, I understand this. > > I wonder if this is significant enough a feature that it justifies > > the complexity in the client. > > This is a good question, which at the end of the day is for CoRE to > decide. RFC8446 says "Application protocols MUST NOT use 0-RTT data > without a profile that defines its use." so this is a gap that we are > trying to bridge for CoAP here, based on existing experience with > HTTP. If the CoRE community doesn't feel this feature is relevant, or > they want to punt for now to gather more experience, it's totally > fine. We could drop Section 14 and possibly resume it later in a > separate doc. I suspect the fact that DTLS 1.3 has not been published > yet may be a reason for things moving slower than anticipated in this > area. > > > >> I'm also concerned that this requires too much cross-layer > > >> communication between DTLS layer and CoAP layer. > > > > > It doesn't seem the case to me: the indication is carried > > > within the CoAP request so it just flows end to end from an > > > application endpoint to the other. But maybe I am missing > > > something. Can you unpack your concern a bit more? > > > > The DTLS layer has to pass the early data up to the CoAP layer so > > that it can reject with 4.02. > > If it can do that, then it can probably just be coded to process > > early data. > > In my server side, the DTLS layer is buried down in openssl C code, > > while the CoAP layer is in ruby. > > The thing is that this feature is enabled on a per-resource basis, so > it needs to bubble up. It can't be handled transparently by the lower > bits of the stack. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_DB9PR08MB6524E1144577F1D56E108AF69CE59DB9PR08MB6524eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear CoRE folks,

 

I wanted to hear yo= ur thoughts about the 0-RTT extensions for CoAP

described in draft-= ietf-uta-tls13-iot-profile [0].

 

I tried this before= [1], but it looks like there was no interest then, and I=

wonder whether the = situation has changed in the meantime?

 

Copied below an ext= ract of the relevant piece of the conversation with

Michael to give you= a bit more context about where this email comes from.

 

Cheers & thanks= in advance for your time.

 

[0] https://www.iet= f.org/archive/id/draft-ietf-uta-tls13-iot-profile-04.html#name-0-rtt-data

[1] https://mailarc= hive.ietf.org/arch/msg/core/Dair8lAqEZ1h8xU6jsz053aqcOg/<= /p>

 

> From: Iotops &= lt;iotops-bounces@ietf.org> on behalf of Thomas Fossati <Thomas.Fossa= ti@arm.com>

> Date: Monday, = 4 April 2022 at 11:03

> To: Michael Ri= chardson <mcr+ietf@sandelman.ca>, uta@ietf.org <uta@ietf.org>, = core@ietf.org <core@ietf.org>, iotops@ietf.org <iotops@ietf.org>= ;, Hannes Tschofenig <Hannes.Tschofenig@arm.com>

> Subject: Re: [= Iotops] [Uta] comments on draft-ietf-uta-tls13-iot-profile-04:

> > On 03/04/= 2022, 21:01, "Michael Richardson" <mcr+ietf@sandelman.ca> w= rote:

> > Thomas Fo= ssati <Thomas.Fossati@arm.com> wrote:

> > &nbs= p;   >> Reading through the lines, it appears that a server= that

> > &nbs= p;   >> can't handle early data needs to send an error code= .  But

> > &nbs= p;   >> such a server probably doesn't know about the error= code.

> >

> > &nbs= p;   > The option is marked critical so if the server does not=

> > &nbs= p;   > understand, it will reject with 4.02.  If it under= stands it

> > &nbs= p;   > and does not want to serve the resource (say, because t= here is

> > &nbs= p;   > some associated state change) it will reject with 4.25 = (or

> > &nbs= p;   > whatever number IANA will assign to this response code)= .  In

> > &nbs= p;   > either cases, the client will not repeat an "early= data"

> > &nbs= p;   > request for that resource.

> >

> > Okay, I u= nderstand this.

> > I wonder = if this is significant enough a feature that it justifies=

> > the compl= exity in the client.

> 

> This is a good= question, which at the end of the day is for CoRE to

> decide.  = RFC8446 says "Application protocols MUST NOT use 0-RTT data=

> without a prof= ile that defines its use." so this is a gap that we are

> trying to brid= ge for CoAP here, based on existing experience with

> HTTP.  If= the CoRE community doesn't feel this feature is relevant, or

> they want to p= unt for now to gather more experience, it's totally

> fine.  We= could drop Section 14 and possibly resume it later in a<= /p>

> separate doc.&= nbsp; I suspect the fact that DTLS 1.3 has not been published

> yet may be a r= eason for things moving slower than anticipated in this

> area.

> 

> > &nbs= p;   >> I'm also concerned that this requires too much cros= s-layer

> > &nbs= p;   >> communication between DTLS layer and CoAP layer.

> >

> > &nbs= p;   > It doesn't seem the case to me: the indication is carri= ed

> > &nbs= p;   > within the CoAP request so it just flows end to end fro= m an

> > &nbs= p;   > application endpoint to the other.  But maybe I am= missing

> > &nbs= p;   > something.  Can you unpack your concern a bit more= ?

> >

> > The DTLS = layer has to pass the early data up to the CoAP layer so<= /p>

> > that it c= an reject with 4.02.

> > If it can= do that, then it can probably just be coded to process

> > early dat= a.

> > In my ser= ver side, the DTLS layer is buried down in openssl C code,

> > while the= CoAP layer is in ruby.

> 

> The thing is t= hat this feature is enabled on a per-resource basis, so

> it needs to bu= bble up.  It can't be handled transparently by the lower

> bits of the st= ack.

 

 

<= /p>

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_DB9PR08MB6524E1144577F1D56E108AF69CE59DB9PR08MB6524eurp_-- From nobody Tue Apr 5 06:15: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 429593A07CF; Tue, 5 Apr 2022 06:14:22 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=w1mcnRZu; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=w1mcnRZu 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 tVaES3i5SLwG; Tue, 5 Apr 2022 06:14:17 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0602.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::602]) (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 3D1363A230E; Tue, 5 Apr 2022 06:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4vDV6PG0JVs5Wm1U1pXz+aPZsbBekfkKtp64tUw6EFw=; b=w1mcnRZuOlzL2Qfj20/xZUmihoQdrJLgzes8FQNeR9FFB8Lr5ABpNPRw012ejPZ1aC3obiLXpo92BDTr5GEltY1VX/TjkZgzaPA4uaeLS99xOSh7wYTxL7IjFEUres7Ag95h8fC8M/c81Zz+VBCwgz463HeqAEjijQFdnZFhH6Y= Received: from DB8PR06CA0065.eurprd06.prod.outlook.com (2603:10a6:10:120::39) by DB8PR08MB5482.eurprd08.prod.outlook.com (2603:10a6:10:116::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.31; Tue, 5 Apr 2022 13:14:11 +0000 Received: from DB5EUR03FT044.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:120:cafe::68) by DB8PR06CA0065.outlook.office365.com (2603:10a6:10:120::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.31 via Frontend Transport; Tue, 5 Apr 2022 13:14:11 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT044.mail.protection.outlook.com (10.152.21.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.19 via Frontend Transport; Tue, 5 Apr 2022 13:14:11 +0000 Received: ("Tessian outbound 2d401af10eb3:v118"); Tue, 05 Apr 2022 13:14:11 +0000 X-CR-MTA-TID: 64aa7808 Received: from 863281363310.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A29AA6BB-BE7A-4546-8843-FB3A719D7DEC.1; Tue, 05 Apr 2022 13:14:05 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 863281363310.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 05 Apr 2022 13:14:05 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gsHmPNcGp+EneFB/1u7ID15i+JamZYDwLkKnZOegrI4xIzrUYF9nXm806Q9FLFXqpkqAShzazEVPChAbWP4yToGS93kC+SO/tykOmMubD5pH+bH/vpZAY8CIx08yPJWNjM5YhXcTH7Dbo0E/sSsBKWk05nBvBDrw+kaJaW2OojAaaNcWe5leK8aPyAa1qzjHxyzL+r11Z5rCG+tWtVvpFRkUSEF1i0teXYdXohZdGxm2DKbOVQ89IZOEAAS7RjpHHbnr5IO9vCAjjB8nRfCT4yrm+z9bzaZfl9iGraB4jMi47K1+NgW3jAvCkCkeXWxCiUbodOFgDh5GM14VoFJhIA== 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=4vDV6PG0JVs5Wm1U1pXz+aPZsbBekfkKtp64tUw6EFw=; b=bihjpylqisWtWeygjZUTxD2lfcjU8fyh3KXCJmdmG2KhCh/dwl2i7El8RIS0ESo0ZLrM36Mx/6rjNMJcMm+BLxwW2QO6qeyLJYEAl9hDkxJnXjlbCfJjrKQgQWCtyf3cYOk15lvXJ3trTDsiYr9Jq2a4XUNpqsbUS5PiYqile6xC6e0/jJf2ubkj0R6KZ2GAKxkM9A5HMQBGPoG8f1R8m6R9KWEfTo7y0lnp+WbLLWpShaiDFwzEjw8jBC/kvqbM/ANRYbcUUjoWK4OjUF7OTLGGJvwJMmMGbSzQjbfxMKew8oDwXRL5Ieg9Bcd4oKEfWEJmjuRhgdHSrszAf/dwwQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4vDV6PG0JVs5Wm1U1pXz+aPZsbBekfkKtp64tUw6EFw=; b=w1mcnRZuOlzL2Qfj20/xZUmihoQdrJLgzes8FQNeR9FFB8Lr5ABpNPRw012ejPZ1aC3obiLXpo92BDTr5GEltY1VX/TjkZgzaPA4uaeLS99xOSh7wYTxL7IjFEUres7Ag95h8fC8M/c81Zz+VBCwgz463HeqAEjijQFdnZFhH6Y= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by AM6PR08MB3029.eurprd08.prod.outlook.com (2603:10a6:209:48::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.31; Tue, 5 Apr 2022 13:13:56 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::5896:9eec:b108:9a3]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::5896:9eec:b108:9a3%6]) with mapi id 15.20.5123.031; Tue, 5 Apr 2022 13:13:56 +0000 From: Hannes Tschofenig To: Michael Richardson , "uta@ietf.org" , "core@ietf.org" , "iotops@ietf.org" Thread-Topic: comments on draft-ietf-uta-tls13-iot-profile-04: Thread-Index: AQHYQQ8Tl5SCPIlH50OtshMMmqm1sKzhTcWA Date: Tue, 5 Apr 2022 13:13:56 +0000 Message-ID: References: <59686.1648298525@dooku> In-Reply-To: <59686.1648298525@dooku> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: AEB3AD913158E44A9714B21F0E971E76.0 x-checkrecipientchecked: true Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-MS-Office365-Filtering-Correlation-Id: 9f2a9c71-f156-4d25-c932-08da17062cd4 x-ms-traffictypediagnostic: AM6PR08MB3029:EE_|DB5EUR03FT044:EE_|DB8PR08MB5482:EE_ X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: xcgcpUH50W+skE1BZADRRi4SF4Iwg6HtvhuLQgCX+0AMhctdHIg4sLUcZ9Cj89jDUMWa06ubo/4R5CCiKmBqtUJu8WEHMK2Hlr+qy4jD+RBe8ugv5uKaLezbTwjhLbmOBs1s4lHgnxKE2hyENQ2Z+mURR6g6E5r2B5TXEaq2De0uRtpKqnysjcjd8v4ndyULKXoNhc+09gJquLoDq3TrLgd8KT+yZmXMdcfMvHjkBx3iX97rtvT6jpbbgmtEX0mfK4UfM3IBzH9WLXcUNaual9o0y0a3PQq1IrYQueFf8EV5JvytaJiuhUzdlA45eKjS81IOCnfI7AdXFxQAtQTXvNzKjq7DI/1Cb/CLJA0aGLAc1T4fMKpd8RGrQ4uolV37kOGxknlZMraAgzh7eiZAp4o8yw+XyHsvxkr7TRpKStx1CuQdlv/E3qAyO/7H3WszN3uVuf3BCKzwvh19dJ5lpq/ZZW3sXkfd+dqhYwurlfELwxVQ4+sC2CDF1qGl7mkho0XuOKeNm1JFqM0P3MmMED2WfKVnPndgNJJKrH1lAxehZtIqkkwoqBUU6dLBzAbn5VTggdWhM0Ebz3ogGNsJnMvgSuimO5JD4TMW3DsSbGyDYE/M6Jr8oYnikQg/VRge3tRybpZGRU9665NZGJYB/LKva4fr12lJRjeDOa1QlZghlyKPfdjAi4G/BgJM1WS9FBK7OHz5253kaeoCu3VTzQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(508600001)(66476007)(66446008)(64756008)(76116006)(38100700002)(7696005)(6506007)(8676002)(53546011)(66556008)(66946007)(186003)(26005)(9686003)(55016003)(33656002)(66574015)(71200400001)(83380400001)(122000001)(110136005)(52536014)(2906002)(86362001)(38070700005)(5660300002)(316002)(8936002); DIR:OUT; SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3029 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT044.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 04bf44ab-94f3-426f-922a-08da17062405 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rv0PUXao+dtUokxBfMk5rcWvIOeIE1rWxAmumkYnalAqgsQY/eJ0tPMG+SgWXGwImqwxzUeeuJd0+G4xe1MLTfbcstXQRCga7SGjDoYmUC8DR6nhp8NbTpdVkyAQ4CluWqteQgO53TR3L35MhEDleFSIJpIpg0d8DFSddxyfWOcqGLkJvW8O9uH9Zw9dW7yJrBPtTtDvXq22OJwuRSGznRtEotPTIkXpdz/m7GBq7lYKj5ek4YordG+YhuZBrzX/2lnV1TmWJ+sIkgqO3GLGc2CbfpnH9+JMUMhaHQGEQFL9pvo8RdSR3pC1HQyL7g3043tH5lwJbginnfEU5BNxLl8lZWTROuEAKp05VqbOFVyg9S9qFlsxgLCKahav0vVOS4rsIGs51oHT6tMhR1PTgOBd559P9awsi5aFuZMlhdyHGUHspU3YCwC+YlAsV2n5rglA1aT0rs7yJuVaPYaaVXmW/GYLWtEDgUcGI+7ZX7J9tozUDxerikM0HJPwUjAA4EMVSdaIb+bel9mjxI1S8TfXUNDp4xJ/AdCjHAzs1Xw6Ccs3vDFxcoQzOIv+cdv9Qi0nTq6tbPASX0krVgVyFxoKx4YxARk+TzezvHTpvrod9LPrOBmpyOuuTVSe2RL8MSqfEsiL0/nm7mfbgdkiQlxZY8lWj3tkpbkYfy7gRrWuIx+IeJK2+JvbHQtE8mG5 X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230001)(4636009)(40470700004)(46966006)(36840700001)(336012)(26005)(186003)(53546011)(70586007)(36860700001)(83380400001)(47076005)(70206006)(40460700003)(8936002)(2906002)(66574015)(86362001)(81166007)(450100002)(52536014)(33656002)(5660300002)(8676002)(356005)(110136005)(82310400005)(508600001)(316002)(7696005)(9686003)(6506007)(55016003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2022 13:14:11.5575 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9f2a9c71-f156-4d25-c932-08da17062cd4 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT044.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5482 Archived-At: Subject: Re: [core] comments on draft-ietf-uta-tls13-iot-profile-04: 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, 05 Apr 2022 13:14:23 -0000 Hi Michael, Thanks for your review. Let me provide you my remarks below. -----Original Message----- From: Michael Richardson Sent: Saturday, March 26, 2022 1:42 PM To: uta@ietf.org; core@ietf.org; iotops@ietf.org Cc: Hannes Tschofenig Subject: comments on draft-ietf-uta-tls13-iot-profile-04: I read draft-ietf-uta-tls13-iot-profile-04 today. Thank you Hannes for presenting it at IOTOPS. To be, it is precisely this = kind of thing that IOTOPS was created for. 1) I feel that the 4.25 Too Early allocation for CoAP could use a bit more explanation, and probably there needs to be some more clear review at CO= RE. (maybe it already happened and I missed it?) Reading through the lines, it appears that a server that can't handle early data needs to send an error code. But such a server probably doesn't know about the error code. I would have thought it should just hang on to the data until the (D)TLS negotiation is complete. I'm also concerned that this requires too much cross-layer communication between DTLS layer and CoAP layer. [hannes] With the design we are following the corresponding design of HTTP.= Thomas has sent a mail already to solicit feedback. 2) A long thread at LAMPS two years suggests that the term "Intermediate CA= " applies only to cross-certification authoritiy bridges, and the term "Subordinate CA" should be used. That this is consistent with history going back to RFC4949. [hannes] We can note in the terminology section that the terms "Intermediat= e CA" and "Subordinate CA" are used interchangeably in this document becaus= e with regards to this document the distinction is not relevant. 3) While section 10 on SNI does not say *how* to use DoH or DPRIVE to provi= de for confidentiality of names that are looked up, a naive use of DoH with Google/Cloudflare/etc. by IoT devices would be a problem for almost all enterprises that wish to filter the DNS used by IoT devices, and to use DNS canaries to identify malware. Given that such an involved discussion is not in scope for this document, i= t might be better just to refer to the ADD WG without mentioning specific s= olutions. I am, in general, not convinced that encrypted SNI serves any purpose for m= ost IoT devices. [hannes] Major IoT service providers have cared about hiding client identit= y information by utilizing session resumption in TLS 1.2 to accomplish what= is now available in TLS 1.3 with earlier encryption of handshake messages.= While I personally haven't heard anyone asking for SNI encryption yet, I e= xpect the same companies who cared about hiding the client identifiers to a= lso take a look at the SNI encryption. While there are pros and cons of usi= ng these mechanisms, I am only suggesting to reference ongoing IETF work. = Companies then need to decide whether a specific solution matches their req= uirements. 4) section 15 There is much discussion about what goes into the certificates. I didn't really understand why that is in this document. Validation of server certificates is well covered in RFC6125, I think. [hannes] In my experience, validation of server certificates has been a sou= rce of confusion in IoT and RFC 6125 does not talk about the use of IoT pro= tocols like CoAP and MQTT. I have seen various companies and organizations = creating their own profiles of RFC 6125 in the past, which has resulted in = the text of this section. Validation of client certificates (whether factory provisioned IDevIDs, or = locally enrolled LDevIDs) is a topic that I care a lot about, and this text= is inadequate. As the (industrial) IoT market embraces IDevID certificates, there is some = concern that different markets will put different requirements on IDevID co= ntents. So far it does not appear that anyone has created a situation wher= e a single (fat) IDevID certificate couldn't be used in a variety of market= verticals, the concern remains. It was my intention to introduce a document about this issue. I think that = it's something that only the IETF can do. Perhaps that would fit into this= UTA document, or perhaps parts of this section 15 goes into another docume= nt. [hannes] This section was difficult to write because - there are lots of different IoT verticals, - companies often do not want to share information about what they do in th= eir deployments, and - there are many different identifier formats. It would, of course, be worthwhile to ask around again to see what current = deployments are using. I could check the public documentation of major IoT = service providers to get this process started. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Mon Apr 11 09:41: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 7C46F3A12B6; Mon, 11 Apr 2022 09:41:33 -0700 (PDT) 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.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <164969529345.10027.5814087491327379012@ietfa.amsl.com> Date: Mon, 11 Apr 2022 09:41:33 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-yang-cbor-20.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: Mon, 11 Apr 2022 16:41:34 -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 : CBOR Encoding of Data Modeled with YANG Authors : Michel Veillette Ivaylo Petrov Alexander Pelov Carsten Bormann Michael Richardson Filename : draft-ietf-core-yang-cbor-20.txt Pages : 50 Date : 2022-04-11 Abstract: Based on the Concise Binary Object Representation (CBOR, RFC 8949), this document defines encoding rules for representing configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications, defined using YANG (RFC 7950). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-yang-cbor-20.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-yang-cbor-20 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Apr 11 10:19:48 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 967E33A0E0D; Mon, 11 Apr 2022 10:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 (2048-bit key) header.d=sandelman.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDjEWTDrejOW; Mon, 11 Apr 2022 10:18:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02BB3A0E04; Mon, 11 Apr 2022 10:18:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D1C2138D05; Mon, 11 Apr 2022 13:30:01 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Dn4bQA-x6iOv; Mon, 11 Apr 2022 13:30:00 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0BC0538D03; Mon, 11 Apr 2022 13:30:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1649698200; bh=hjHu1mJ3xnNY659e1mE4eKU+ZOlGgGmdJ9fB9CgNekc=; h=From:To:Subject:In-Reply-To:References:Date:From; b=6LzzOKUpdy6OJ50dNHJPsBAJ1yjgT3RZdVeJajVoZyoM4L1MxNx+c/u0pW4taVPxh x6Ldbskem6J86y7ZZ2EoorV44MmAjvGgo4nioxpV7YnGYYtDuxMuzAGEHLu/qIRtXN 3buC/aXfUaIKFTk2dk3FILhjmEUwlEeIpMWZEroD+Wfje0RZSj14dssf2aB16784L8 l2ZZC+VESFAgN7Yj7mlzbhGMYChnOLC/zFyZRknpVlzJ3ZeMJ9qNR/MAn5ROrkgHUo wKmu/AduZ0+G1eZ0+xd3fjt1jJXNe//wiVLLCISM/u8eCMC+o9/j/UDbSvIkF6pDyW roKZaAaaUTHEw== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0D2383F; Mon, 11 Apr 2022 13:18:29 -0400 (EDT) From: Michael Richardson To: Hannes Tschofenig , "uta@ietf.org" , "core@ietf.org" , "iotops@ietf.org" In-Reply-To: References: <59686.1648298525@dooku> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] [Iotops] comments on draft-ietf-uta-tls13-iot-profile-04: 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, 11 Apr 2022 17:18:40 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hannes Tschofenig wrote: mcr> 2) A long thread at LAMPS two years suggests that the term mcr> "Intermediate CA" applies only to cross-certification authoritiy mcr> bridges, and the term "Subordinate CA" should be used. That this mcr> is consistent with history going back to RFC4949. hannes> [hannes] We can note in the terminology section that the terms hannes> "Intermediate CA" and "Subordinate CA" are used interchangeably hannes> in this document because with regards to this document the hannes> distinction is not relevant. My view is that we have confused people by using them interchangeably, and = we should stop doing that. Why not just use subordinate CA then? The relevance has to do with how path validation is managed.=20=20 mcr> Given that such an involved discussion is not in scope for this mcr> document, it might be better just to refer to the ADD WG without mcr> mentioning specific solutions. I am, in general, not convinced mcr> that encrypted SNI serves any purpose for most IoT devices. hannes> [hannes] Major IoT service providers have cared about hiding hannes> client identity information by utilizing session resumption in hannes> TLS 1.2 to accomplish what is now available in TLS 1.3 with hannes> earlier encryption of handshake messages. While I personally hannes> haven't heard anyone asking for SNI encryption yet, I expect the hannes> same companies who cared about hiding the client identifiers to hannes> also take a look at the SNI encryption. While there are pros and hannes> cons of using these mechanisms, I am only suggesting to referen= ce hannes> ongoing IETF work. Companies then need to decide whether a hannes> specific solution matches their requirements. Yes, what I'm saying is that just reference it. Trying to say much more about ongoing work is a recipe for getting something wrong and having to revise the document late in the process. mcr> 4) section 15 There is much discussion about what goes into the mcr> certificates. I didn't really understand why that is in this mcr> document. Validation of server certificates is well covered in mcr> RFC6125, I think. hannes> [hannes] In my experience, validation of server certificates has hannes> been a source of confusion in IoT and RFC 6125 does not talk hannes> about the use of IoT protocols like CoAP and MQTT. I have seen hannes> various companies and organizations creating their own profiles hannes> of RFC 6125 in the past, which has resulted in the text of this hannes> section. Okay, so either we have to do much more, or we have to do much less here. mcr> As the (industrial) IoT market embraces IDevID certificates, mcr> there is some concern that different markets will put different mcr> requirements on IDevID contents. So far it does not appear that mcr> anyone has created a situation where a single (fat) IDevID mcr> certificate couldn't be used in a variety of market verticals, mcr> the concern remains. mcr> It was my intention to introduce a document about this issue. I mcr> think that it's something that only the IETF can do. Perhaps mcr> that would fit into this UTA document, or perhaps parts of this mcr> section 15 goes into another document. hannes> [hannes] This section was difficult to write because - there are hannes> lots of different IoT verticals, - companies often do not want = to hannes> share information about what they do in their deployments, and - hannes> there are many different identifier formats. hannes> It would, of course, be worthwhile to ask around again to see hannes> what current deployments are using. I could check the public hannes> documentation of major IoT service providers to get this process hannes> started. Thomas suggested that this was welcome in this document. I will attempt to write some text to go here. The TL;DR summary is: "don't shoot yourself in the foot" :-) Or, be tolerant of things you don't understand. I agree that it needs a road show to bring this to many other verticals, but I think that ultimately, those other entities are looking to us to give them something to cite. The question is whether the TLS profile is the right place for it. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFKBAEBCgA0FiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmJUYuQWHG1jcitpZXRm QHNhbmRlbG1hbi5jYQAKCRCAi3D73dDdZSFkB/95ovpBawgqR71aA3HLVRv8BXNX 9ZqxE2hxdPb/YpD4H1d2q3V87gRIV0R/lfORgeurmDWaQ4XFRCUW37BsvT6bXx1n 8momjZ2G5rckPVDx0YHSf2VbaBw2h3wHslcDUtobETxJfWJTz0mjrrGp6Sm8cQ3B HMzhfjXkl7sSFsZ7y+n2jaOo7wqBF3FR5gildRb+hxtEizTQJOzg1RQdDNNbu+nz Sok48kZFZbxzYVEpcgQsJYU08bGVP8NgRd230qaIpntYA443LWT+FXD323W52Dqo Z93AqeTXxxfaVhEBwahnpkbNQNRRDRXn3TViTOwzXStcKSNCR4tij6/DHZMd =QabE -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 12 13:44: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 4071F3A1138; Tue, 12 Apr 2022 13:44:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Carsten Bormann , The IESG , core-chairs@ietf.org, core@ietf.org, draft-ietf-core-yang-cbor@ietf.org, francesca.palombini@ericsson.com, marco.tiloca@ri.se, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <164979624723.2661.12697848386858575536@ietfa.amsl.com> Date: Tue, 12 Apr 2022 13:44:07 -0700 Archived-At: Subject: [core] Protocol Action: 'CBOR Encoding of Data Modeled with YANG' to Proposed Standard (draft-ietf-core-yang-cbor-20.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: Tue, 12 Apr 2022 20:44:07 -0000 The IESG has approved the following document: - 'CBOR Encoding of Data Modeled with YANG' (draft-ietf-core-yang-cbor-20.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Murray Kucherawy and Francesca Palombini. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ Technical Summary: The present document and draft-ietf-core-sid together provide the foundation to extend YANG-based management down to constrained devices (RFC 7228). In particular, the present document defines encoding rules for serializing YANG using the Concise Binary Object Representation (CBOR) [RFC8949], specifically configuration data, state data, RPC input and RPC output, action input, action output, notifications and yang-data extension defined within YANG modules. The companion document draft-ietf-core-sid defines YANG Schema Item iDentifiers (YANG SID) and a file format used to persist and publish assigned YANG SIDs. The two other documents draft-ietf-core-comi and draft-ietf-core-yang-library apply the two documents above, by using the CoAP protocol (RFC 7252) for access and providing information to be used in conjunction with CoRE resource discovery (RFC 6690). Working Group Summary: The suite of documents spans specific areas of interest of several WGs, in particular NETMOD, CBOR, and CORE, as well as NETCONF. This required coordination between authors and reviewers that see different of these WGs as their central point of activity. While the documents were stable already for a while, a specific issue on representing YANG unions required somewhat unsavory resolutions, which held up the process considerably. Document Quality: Since the document became a WG document in April 2016, several reviews were provided by members of the concerned WGs. Jürgen Schönwälder as well as Andy Bierman were very helpful in resolving remaining issues about this document. The document also received Last-Call comments from Yangdoctors and Genart. Personnel: Document Shepherd: Marco Tiloca Area Director: Francesca Palombini Carsten Bormann served as Document Shepherd up until version -15 included, thus taking care of most of the shepherding process and especially providing the original version of this writeup. From nobody Thu Apr 14 02:39: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 70CBD3A0D71 for ; Thu, 14 Apr 2022 02:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_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 ActpVft7YTNM for ; Thu, 14 Apr 2022 02:39:06 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20603.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::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 48B063A0D6E for ; Thu, 14 Apr 2022 02:39:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ph2yMNNIHeZGbht5NQAlJGCbO6Vz690y9UPZ1jluhv3yGs4U4vf3dxnexzOY8RuiQIelHZAvPCE3z6z5ktSNJwgnFREjvLfvedzXthn96kCK8QIItrrJRA6aQR94cWZWGjWeEJd/k+nHWDlOE3HeQHtdcNb7X1jajLPFHECFjEeAnD4TH2uln2Yi00s7V/JGqt3Mx5Nagr6D9RlXlH057Z/+QYD8wv8QMIheZTOPAa2Vgfj9z1dxkSyB/h4h0QWTSTrIzbiltzOHezslGDg76uWM+KlpCXKskOq/HowI87IUSTjIQB1JhZoi1JErjxHe5mNFtDRHelddO8GuFp1suA== 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=q/H/Mpav+bevPn9qS1nPhrv1pu5+JU1xnCJwqIBHC08=; b=BEyekkJNXS2a5slJdn1LEJ0Mwo3C5wRLEZ2XKHzUwx4aLTPhGDfkVYycFVJ7fUZBTgqAy/Ty4OWqAU1/JG75Ryoyb2KQcoRgUNgy4HqVKVC37gVaRaNwlJL3beCQ2qTfBMoVDsFyMBEeEcfFC8Nrf3gCw8HnNIqIVBwOSETy3DBuyuUMvjlQmKS3N9amCKWkLLjQY4qf51NDEEo216yb8EUN0WS3kovDieE+KNvpKeS3ptQyi4mJPcjnWtoD2laFb2G0gpZXev4yLZ+0ljRXjEbeZDpPcgWjCqMh1KIYToAjCGPx10MdxBipi6xQIucjmgfpOehEFPt6qoZKm0FDoQ== 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=q/H/Mpav+bevPn9qS1nPhrv1pu5+JU1xnCJwqIBHC08=; b=HUct8tCY7RE+C+UBozEvEAZL2GbdqecUVmckfYuTeuLaxrELIhqvEOkBIOWL/dpzFTc/ynwreFGHdTzLrM+xHsgEh5PRoLHXNLqjy2F0eT1evERxgCIiB8j2V4NWAhNlundIsA/Z00LI7wBhIUkIC4s/A50Ojr0TkztFB4wzxSM= 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 GV2P189MB2233.EURP189.PROD.OUTLOOK.COM (2603:10a6:150:a9::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.29; Thu, 14 Apr 2022 09:38:59 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::557f:972e:f6ab:9b06]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::557f:972e:f6ab:9b06%7]) with mapi id 15.20.5164.020; Thu, 14 Apr 2022 09:38:59 +0000 Message-ID: <9977cab9-7fb2-ca1f-f7d0-8782e0ab7778@ri.se> Date: Thu, 14 Apr 2022 11:38:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------n1n0roWp9cTKsZpL9vOyMRhQ" X-ClientProxiedBy: FR3P281CA0002.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:1d::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: f684952a-0a25-4a91-d1d5-08da1dfa9a6a X-MS-TrafficTypeDiagnostic: GV2P189MB2233: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: O3/GZWbguXsAhqSKXP7dUjPKSSVxUgLQY7aUdeG7MPAIuPkfXqDWCbxeIyz+2un0nYn/6+SL4r6k3Os6yx97vnYSS5J4w7HY9fB5/h0xhC8PdIjqmrmReRmBfvssqscvR4zNSnOYyaahGv+84qCSOMOUcK6aKaXP6ZGI5Z2ywpE6BnPyB8ASZ/jRxTPl+S3kQ7lECWt7B+S2eS74Q+tweuXlylyQe5lVTnhh/WSyMY3RIg00JY3H0f7MnhTrj0F88um8DqGDwnUETiR1/C2WCP9zQTkl3FbdNhte1E/1apsIXg7vTC9bpisE8YT7XEiVJVbR1azqHufGGDNIw/i2ffAEeBjq65kgsIMOn7tZp5eJHwVU6vfwelCAL90KW689xWPvE6gCfv4RwHlZX1aJwh+cde4/xf48RtdHF5KamlsgVRp38CgQg4s59ZrgFzI3DO6xENIwgt1pJH7fERafrStV/BhJ2bppCRyO62nqnaGjXF445esrRlqJOR8iJTK1/DSHn7PcXe0Hr6ye7Ixbhs2gv2xtHd9lHQcdQxlGFtoNOKg0TwH8DsGQ02kT8XkXObPZD4owebz1uSsmrBIdfRpaB09EDZHSNAarmJdaWuwgN5Olufhs+nL5fvB7X4Xwxcd1fw9Cpokf4WAvYelIzti7uH1DVQ6fHrn/zEW7HXCFjdVx/ZS7cMh4TyBlzdk4Uf6IthvN/c0YPrHLC+37Qd14cIXgyckSbQ6cLp1w7f3lyR8L2IRVQKptWhAO5BCscwWGFZpD8kfaFfpfmkE6zeHYOMcMkupg7AdKXvzpMQkvWYgob8Ulp3j1Up5py9KU 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)(235185007)(31686004)(36756003)(66574015)(6512007)(53546011)(86362001)(316002)(38100700002)(8676002)(966005)(6486002)(508600001)(2906002)(66946007)(6916009)(5660300002)(31696002)(26005)(186003)(8936002)(66556008)(66476007)(44832011)(21480400003)(2616005)(6506007)(33964004)(83380400001)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?KzVta3lMcWJJNllZYk1iVGRYeXRXalNSQlZuTDQ3Q3B3TVVybXlOdGFOeWFy?= =?utf-8?B?VWZ0azhFTnI3a0IybUk1UlFOWG5KRUsvVHFJMVM0bmlKS1FMN3pTZG1BYVo3?= =?utf-8?B?MUhheTdqUXNPTC9tM1dJOGpyNFNZaWxHckxacDBRWUM5aFNwSDRZMlhMZTk0?= =?utf-8?B?dVAvOVhTWnFKNGFLU2FGclQ5NWFORTBEWHErNzNOY0NrdmIzdmxRV0hnK2N5?= =?utf-8?B?dXJtUUErTEFJa2h2SmRIMmNnN1ExVUhYSnF3S2dHTSsxbklMN1FDc2MyNFZr?= =?utf-8?B?V05ib0dmM3dCSVJkSGdUc0NBV3g0QWE1TXNURFlwcGV3b0xONnpiZGVlak5s?= =?utf-8?B?UllXanVKRks4YmEwNlBHSVdwWENYWUh2NVhtVm5hL012RXFBS3U1aVdJQjdz?= =?utf-8?B?NUVTUWZSRjlibFAxNHZaYXJFOWp3dmNWdG0wc0VWTWxlZE9rcnFDVGxBcFdK?= =?utf-8?B?eFJuYkN6RWMvWEdHUnhkN2wzaVBlUzhObVA2eEFxTzFKMkdYSVR4VngrY21M?= =?utf-8?B?anpzUmNSa2o3OVAvRldTdEcrcGp5RTJENW9rRjlDNHNRVjVxb0E5dE5Vd1B4?= =?utf-8?B?UXQ1VFgzQnN6WGZRQTdHZEcyVEh5WjFkcTdjVUVsRFIzRGtuQ1E4aGJCYVpD?= =?utf-8?B?OXdyUW16cjhBK3lJZFVrV3lNcytZT3RJRzZTZWJJQ2Q1QVo4RGtCQS9PY3BQ?= =?utf-8?B?dEZnSEkrd0VkdHVFSjloQzVmM1RNcmF0QUlyQnF4dmVIa291UWRpV2k4M2g3?= =?utf-8?B?bllzRUVNUCtpSmJTQ2dtbWRacDdOUEladVRIcmhxbEZ2anVDSW1HajlKUFZB?= =?utf-8?B?Q0JNNVV0cUd3NzR3UkpmRzdKYVJrUjJvT1dadXphYm9qWkV3T3RJcmZ5dUZS?= =?utf-8?B?Y0hoMzlXRnNhdTdDSklCVzZPbGNFdno4NHByL2dlQlNqbjk2aHk4Rkh2bnZB?= =?utf-8?B?YXlBMURCQ1FoQU40aUlDbm9IS1kxS0owbFVqTlg5bHlEWjRwUkZtZThVRHUz?= =?utf-8?B?MEpQQXlSRHY1Vzl5OUZXWFVoaVpoZnR5aWtUYTR3U2NRazNLaWgydmpqWEw1?= =?utf-8?B?SWJvMUdRTWRENmtWUkVtMXFwUEVSVVpHZGM2ckhvUHlVSEFxUzIrOFdvaFAz?= =?utf-8?B?NXgvMHZHRXVtdGpzZGRYMEFYczB2SWFkaWZiUHRucDNpdElXTzNVVjk5V0Z2?= =?utf-8?B?c3Z6N0JmVkcrampPVzZWQTJvUTlJZXVZdi9uN1BoYW4zZHBwTVB5SThTZmNN?= =?utf-8?B?SDYzRVVGVFBNRXMvcE5SekZtaEsyM1ZIZ2pYVXJtUHkxY0F6UVNaSkpGSkpy?= =?utf-8?B?TTJRUUtrNHRaQTdMRWttZllvZk43SWdKQXBNd05IWVF4ZSttTnBkMFcrajRR?= =?utf-8?B?U2p4N2FHK0ZFb2prY3I3NGZaWXhIc1oxU2RLbWhvMnkwQjZ6WHkxT1BURWd1?= =?utf-8?B?NnVPZTZVUXpIcS8yVVBneDdEek1hQWM2VzJTY3pvV2x1TFpzaE8xYjJqcjNU?= =?utf-8?B?cHM4Z3RXSUx6TTdha1V4cEhTQ0xCd3JnbkhRVHdoVGg4NDQzYkVJV1FuN1M3?= =?utf-8?B?NjBDMXFxcGsrNE8vRGlRblUrbFptZTZvOVR2d1UzUEVneUlpZ0VtMk1LbVRU?= =?utf-8?B?MFNwbnVjS0d4WEs1SzVlbzF2TGxpcU9hSWI0TktpM1ZPSWdPSm1UaGhJaFJY?= =?utf-8?B?ejZqWWJURnB2UmFRWVpMUll6bERucURUalYxa0hiV3dDWnU0K1BabWR0WEEw?= =?utf-8?B?T1VYM3lmSUk4SG9tN0svaExwRnhVbWRhRlZkRkVLOXhRRjdNTTdRMllWcWZh?= =?utf-8?B?bm1DeWZMUnJueXp1K0FsNDZhYWs0amJCdU1BSGluWnl4RkgyWkdDa05FY2Fx?= =?utf-8?B?TEhPcFFSK1dTOFMzRWR0SjhlQ1BqNUV2bFhYRWpnbzNDY3lWNXZnWk15WmIz?= =?utf-8?B?dGFGOUJqZjg3QVJPa3dIbzdMN1lPNHViN1RwZnFLTHhrUVBxOFZmRTBadWph?= =?utf-8?B?Q1lkamJDN2hCTUpURmJFVDFhNHhZQWxHa3hiNjArdC9leHhJU1c0RzBGd3d1?= =?utf-8?B?MXpJS1U1c2lwODNhUUJqSlEyeDhNRStMeUZxOHZMUW5IdmZxTFFIMjQ4TExn?= =?utf-8?B?UGw1SEVTSGxremE1WFdVS1pFNEpQTUprVTRYVU1tMWhWSTdlNVdidW8wUld3?= =?utf-8?B?ZTNlZXlJeWdBS2tkQitoWHhxSFlKWnd2ZzRGdmVWVThVczZCY3hMcXdOZ0ZU?= =?utf-8?B?L2hDbkJkbXdjOW5qaStZaERqdTRMZDYrd0ZjMmxQL2VlU3p5RndvVDdocGVB?= =?utf-8?B?cHJueS9QQkt3SkZFMGtWUDk4VEJPTUZtcWtLTTdtVVRBQmk5LzRVdz09?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: f684952a-0a25-4a91-d1d5-08da1dfa9a6a X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Apr 2022 09:38:59.7942 (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: XGEY52Xbhi/eINL+MMmstGtGUtv26BaSL6mXvjGOlC0oXrw1Ze29D4FzDY18hBFFwyc8wfk9ugg2JdJLqg5rWw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2P189MB2233 Archived-At: Subject: Re: [core] Confirming the adoption of draft-amsuess-core-transport-indication-03 as a CoRE WG document 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, 14 Apr 2022 09:39:12 -0000 --------------n1n0roWp9cTKsZpL9vOyMRhQ Content-Type: multipart/mixed; boundary="------------M3CfBusSsIcoPO7iwxxkeIOd"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <9977cab9-7fb2-ca1f-f7d0-8782e0ab7778@ri.se> Subject: Re: [core] Confirming the adoption of draft-amsuess-core-transport-indication-03 as a CoRE WG document References: In-Reply-To: --------------M3CfBusSsIcoPO7iwxxkeIOd Content-Type: multipart/mixed; boundary="------------Rwrs4m608ZeEYvn8EJMXltZD" --------------Rwrs4m608ZeEYvn8EJMXltZD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNClRoaXMgbWFpbCBjbG9zZXMgdGhlIEFkb3B0aW9uIENhbGwuIFRoZSBk cmFmdCBpcyBhZG9wdGVkIGFzIGEgQ29SRSANCldvcmtpbmcgR3JvdXAgZG9jdW1lbnQuDQoN CkNocmlzdGlhbiwgcGxlYXNlIHN1Ym1pdCBhIG5ldyB2ZXJzaW9uIC0wMCBhcyBhIFdvcmtp bmcgR3JvdXAgZG9jdW1lbnQuDQoNCldlIHdpbGwgYWxzbyBzZXQgdXAgYSBDb1JFIEdpdGh1 YiByZXBvIHRvIGhvc3QgdGhlIGRyYWZ0IHNvdXJjZXMuDQoNCkJlc3QsDQovTWFyY28gKGZv ciB0aGUgQ29SRSBDaGFpcnMpDQoNCk9uIDIwMjItMDMtMzAgMDk6NTcsIE1hcmNvIFRpbG9j YSB3cm90ZToNCj4gRGVhciBhbGwsDQo+DQo+IER1cmluZyB0aGUgQ29SRSBzZXNzaW9uIGF0 IElFVEYgMTEzLCB0aGVyZSB3YXMgdmVyeSBnb29kIGluLXJvb20gDQo+IGNvbnNlbnN1cyB0 byBhZG9wdCBkcmFmdC1hbXN1ZXNzLWNvcmUtdHJhbnNwb3J0LWluZGljYXRpb24gWzFdIGFz IGEgV0cgDQo+IGRvY3VtZW50ICgxMCBhZ3JlZWluZywgbm8gb3Bwb3NpdGlvbikuDQo+DQo+ IFRoaXMgbWFpbCBzdGFydHMgYSBjb25maXJtYXRpb24gb2YgV29ya2luZyBHcm91cCBhZG9w dGlvbi4gSWYgeW91IGFyZSANCj4gb3Bwb3NlZCB0byBhZG9wdGluZyB0aGlzIGRvY3VtZW50 LCBwbGVhc2UgcmVwbHkgdG8gdGhpcyBsaXN0IG5vdCBsYXRlciANCj4gdGhhbiBBcHJpbCAx M3RoLg0KPg0KPiBXaGlsZSB5b3UgY2VydGFpbmx5IGNhbiBpZiB5b3Ugd2FudCB0bywgdGhl cmUgaXMgbm8gbmVlZCB0byByZWFmZmlybSANCj4geW91ciBzdXBwb3J0IGlmIHlvdSBleHBy ZXNzZWQgaXQgZHVyaW5nIHRoZSBtZWV0aW5nLg0KPg0KPiBCZXN0LA0KPiAvTWFyY28gKGZv ciB0aGUgQ29SRSBDaGFpcnMpDQo+DQo+DQo+IFsxXSANCj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtYW1zdWVzcy1jb3JlLXRyYW5zcG9ydC1pbmRpY2F0aW9u Lw0KPg0KDQotLSANCk1hcmNvIFRpbG9jYQ0KUGguRC4sIFNlbmlvciBSZXNlYXJjaGVyDQoN CkRpdmlzaW9uOiBEaWdpdGFsIFN5c3RlbXMNCkRlcGFydG1lbnQ6IENvbXB1dGVyIFNjaWVu Y2UNClVuaXQ6IEN5YmVyc2VjdXJpdHkNCg0KUklTRSBSZXNlYXJjaCBJbnN0aXR1dGVzIG9m IFN3ZWRlbg0KaHR0cHM6Ly93d3cucmkuc2UNCg0KUGhvbmU6ICs0NiAoMCk3MCA2MCA0NiA1 MDENCklzYWZqb3Jkc2dhdGFuIDIyIC8gS2lzdGFnw6VuZ2VuIDE2DQpTRS0xNjQgNDAgS2lz dGEgKFN3ZWRlbikNCg0K --------------Rwrs4m608ZeEYvn8EJMXltZD 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----- --------------Rwrs4m608ZeEYvn8EJMXltZD-- --------------M3CfBusSsIcoPO7iwxxkeIOd-- --------------n1n0roWp9cTKsZpL9vOyMRhQ Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmJX67EFAwAAAAAACgkQ7iZktA5Y2kON QggAilinM++64y5EcsW7i/Q1TjK65QjufxLjMW/1GVHxthPZDmDx0+kxOBsHl0tacMIeJKB621Va rdOCvxDcmyK06oT3b+J5EfRsDhZ4aHik1AUFRR0FyxA07yAhrxUxmZcGC2x3oA0zwCbHvoFxefMe e6ItwZCSC0W7JiahTxbkm+oG7b3lBiHZfQL38dpDMMRuPrNv6HfIKIEv7SxSTlxi4xZEgA74XWaf XT8C+a6s2IbvFCnlXhv0zf4uoknuKLO8yNuwmq7wNqG0t/LjNhpUGw6ijgjuDRIhKeYNzYn5a66l T+ucuKyVZx0AhtyAGdTu0I1LQOKBssfBL6BuvplTPA== =mpz2 -----END PGP SIGNATURE----- --------------n1n0roWp9cTKsZpL9vOyMRhQ--