From nobody Fri Apr 1 11:18:13 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@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" CC: Hannes Tschofenig 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: [Iotops] [Uta] comments on draft-ietf-uta-tls13-iot-profile-04: X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations 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 Sun Apr 3 13:02:21 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@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: [Iotops] [Uta] comments on draft-ietf-uta-tls13-iot-profile-04: X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations 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 Mon Apr 4 03:02:59 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@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: [Iotops] [Uta] comments on draft-ietf-uta-tls13-iot-profile-04: X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations 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 08:53:19 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BE93A087B for ; Mon, 4 Apr 2022 08:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8haNcIk10KGd for ; Mon, 4 Apr 2022 08:53:14 -0700 (PDT) Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com [IPv6:2607:f8b0:4864:20::112e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72CA3A07DE for ; Mon, 4 Apr 2022 08:53:13 -0700 (PDT) Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-2e5e9025c20so104457987b3.7 for ; Mon, 04 Apr 2022 08:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lMRVum5XW79PKz7M7izWEy3QJLSyM3f3HPCP/MzF4nk=; b=NgkebZzcRD1MWQ1GneYdFHuzy0BKdVoEJbwD+3/NHUH86HKjamS+GBQio2gIU8Jrhv 5d2ifHAkkJmHeEXArGiAQ0jC5CED2rzKDEog5DBwcIQWWL3JT1jkvQMtZ3T8oEw7TKWc 1uobm3ZSRw4FeEZsn6T1R/eYhTGDX1ekkVDVo8duQX3VW4f8qXc0gnx4HSFFEdVRBaWQ gG7AYMOcx0TG4hquibBYEhcYjCbmy+o4y6n0U7RvnwBttuA8jANXVV+itygFsufhtbrC yL5aa/1fWbc9Vv8bK5rjAhVMDGeSuSm9ADzS/4cJX5l6bVqnqu+ghQ+Le9Ywuhqz5zm0 8+ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lMRVum5XW79PKz7M7izWEy3QJLSyM3f3HPCP/MzF4nk=; b=y0vg3tP1uiIJ2AHWNlqwOI5ph8Uowh8zeF2lNi03M/2uNBtpGRO+sx0LySvqNfUNE1 l7HExLFOtsU11h6eqpyFuRuHNweB7iea2t2/KWaU0+O4ewlbs2Fgb53DwTRT0PwF8XOj 0nRuN8eUE5lkEtCXTl2vAWuJv03rWa28UouNBnG0XQjBNIagBBhv4JVQOUYDn4aCWApC wGmJcPoft6YHnd/ITgkFajeZGF/jsMe3yXbV7jE95MgBLjOtocSKwL19tOFuDmwFpHeV NlXU6qfOUDDwf98FYhc1ljpf6VFvV1kgem5RL2Huld1cY664v8ePKc1E+nxDLzbrFKSp w64g== X-Gm-Message-State: AOAM531zz1q5HctxfpLkU07va62U0gSK4Snj5lq138sLz6uIn7IXcU+R Zi2EJwfUumzJ23L/94S4I37zlBMhTzAH47o0QPo= X-Google-Smtp-Source: ABdhPJyghp8jdRsAFfdNKlQrEFt8i+tnfw8LG1hBkHFwxqQOFzR2yhF8x37AJmk38l1i/hSjtHkkQw+/MbTAfhC3Fi4= X-Received: by 2002:a0d:da45:0:b0:2d0:bd53:b39 with SMTP id c66-20020a0dda45000000b002d0bd530b39mr549819ywe.463.1649087592494; Mon, 04 Apr 2022 08:53:12 -0700 (PDT) MIME-Version: 1.0 References: <15753.1648744993@localhost> In-Reply-To: <15753.1648744993@localhost> From: =?UTF-8?Q?S=C3=A1vyo_Morais?= Date: Mon, 4 Apr 2022 12:53:01 -0300 Message-ID: To: Michael Richardson Cc: Michael Sweet , iotops@ietf.org Content-Type: multipart/alternative; boundary="00000000000027793205dbd62035" Archived-At: Subject: Re: [Iotops] INXU documents --- Re: Question about updating drafts X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2022 15:53:18 -0000 --00000000000027793205dbd62035 Content-Type: text/plain; charset="UTF-8" > > My feeling is that we need some solution in this space, but I'm not (yet) convinced that your solution is the right one. > Either evolving (and improving) INXU or finding out a better approach, I agree we need more discussion on that. Anyways, there are some things I feel could be improved in INXU, but before doing so it could be better to listen to the community's suggestions and opinions. In general, you should probably repost/edit your draft until such time as it > gets adopted or there is rough consensus that it's a bad idea. > Many thanks, so I will make some edits to the current draft and send the updated document to OPSAWG and DOTS WG for further discussion, as you suggested. Michael Sweet wrote: > > I skimmed the referenced draft along with RFC 8250, since I wasn't > > familiar with that work... My $0.02 CAD is that if MUDs are being > > implemented by vendors then MTDs would be a useful addition. But in > > the printer world we've only been talking about TNC and EAP for > > securing enterprise networks... > The current model in INXU uses MUD as a data source, but I understand that it is plausible to use another tool to build the network communication graph. Here I can mention the MUD Generator from UNSW [1] that can be used to profile the common behavior of the connected devices. the problem is that todate, MUDs are not being implemented en mass by > vendors. There is a chicken and egg problem, and there still needs to be > some strategic decisions to make it work out. > From my side, I am trying to use the IGF IS3C [2] to make policymakers know about MUD, as well as talk about MUD to the LACNIC community (ISPs). This way, I hope that if more people outside IETF know about MUD, we can solve the chicken and egg by making the vendors know that other stakeholders are interested in MUD. [1] https://github.com/ayyoob/mudgee [2] https://www.intgovforum.org/en/content/internet-standards-security-and-safety-coalition-is3c --00000000000027793205dbd62035 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0My feeling is that we need some solution in this s= pace, but I'm not (yet)
convinced that your solution is the right one.

Either evolving (and improving) INXU or finding out a better approa= ch,=C2=A0
I agree we need more discussion on that.
=
Anyways, there are some things I feel could be improved in I= NXU, but=C2=A0
before doing=C2=A0so it could be better to listen = to=C2=A0the community's suggestions and opinions.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> In general, you should probably repost/edit your draft until such time as i= t
gets adopted or there is rough consensus that it's a bad idea.

Many thanks, so I will make some edits to the c= urrent=C2=A0draft and send the updated=C2=A0
document to OPSAWG a= nd DOTS WG for further discussion, as you suggested.

Michael Sweet <msweet=3D40msweet.org@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 > I skimmed the referenced draft along with RFC 8250, sinc= e I wasn't
=C2=A0 =C2=A0 > familiar with that work...=C2=A0 My $0.02 CAD is that if= MUDs are being
=C2=A0 =C2=A0 > implemented by vendors then MTDs would be a useful addit= ion.=C2=A0 But in
=C2=A0 =C2=A0 > the printer world we've only been talking about TNC = and EAP for
=C2=A0 =C2=A0 > securing enterprise networks...
=C2= =A0
The current model in INXU uses MUD as a data source, but I un= derstand that
it is plausible to use another tool=C2=A0to build t= he network communication graph.
Here I can mention the MUD Genera= tor from UNSW [1] that can be used to=C2=A0
profile the common be= havior of the connected devices.

the problem is that todate, MUDs are not being implemented en mass by
vendors.=C2=A0 There is a chicken and egg problem, and there still needs to= be
some strategic decisions to make it work out.

=C2=A0From my side, I am trying to use the IGF IS3C [2] to make poli= cymakers know about MUD,
as well as talk about MUD to the LACNIC = community (ISPs).

This way, I hope that if more pe= ople outside IETF know about MUD, we can solve the
chicken and eg= g by making the vendors know that other stakeholders are interested in MUD.=

--00000000000027793205dbd62035-- From nobody Tue Apr 5 06:14:24 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@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: [Iotops] comments on draft-ietf-uta-tls13-iot-profile-04: X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations 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 Wed Apr 6 09:25:35 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD493A1A58 for ; Wed, 6 Apr 2022 09:25:33 -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, HTML_MESSAGE=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=msweet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgKKUOecw9IA for ; Wed, 6 Apr 2022 09:25:29 -0700 (PDT) Received: from mail.msweet.org (mail.msweet.org [173.255.209.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBD23A0BC6 for ; Wed, 6 Apr 2022 09:25:29 -0700 (PDT) Received: from smtpclient.apple (cbl-66-186-76-47.vianet.ca [66.186.76.47]) by mail.msweet.org (Postfix) with ESMTPSA id 567778209E; Wed, 6 Apr 2022 16:25:28 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.msweet.org 567778209E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=msweet.org; s=default; t=1649262328; bh=72yoEEI2yR5BiyxfPu7Igs3JFTTqwmBHtbF0wdACxqE=; h=From:Date:Subject:References:To:From; b=cGgvH8GqRwGrma+QXai/x0PSDjwfrs/mYogop3J92ddrL4VN8RV/H2bX5TTRUC8XU 9Xn14KHLKNCkKsG+aQOV2TNiGguRntTNZri7SQd5NT8wMBKw8Ty5d1nj48z6rACf5i fmlW7Q6XrwPoEcsSK30LoORUVlEPMnvBoLSC9hio= From: Michael Sweet Content-Type: multipart/signed; boundary="Apple-Mail=_1391E75A-699D-4781-B430-A2C1DA7E629A"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.1\)) Date: Wed, 6 Apr 2022 12:25:26 -0400 References: <164926156380.8707.8732915494613186098@ietfa.amsl.com> To: iotops@ietf.org Message-Id: X-Mailer: Apple Mail (2.3696.100.1) Archived-At: Subject: [Iotops] Fwd: New Version Notification for draft-sweet-iot-acme-00.txt X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2022 16:25:34 -0000 --Apple-Mail=_1391E75A-699D-4781-B430-A2C1DA7E629A Content-Type: multipart/alternative; boundary="Apple-Mail=_8E1E7E7A-5C35-42C1-8046-471686DB2D18" --Apple-Mail=_8E1E7E7A-5C35-42C1-8046-471686DB2D18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, A proposed solution for locally-managed (and trusted) X.509 = certificates, to solve the "this web site will eat your child" errors. = I'm working on coding up a sample implementation... Comments/feedback is appreciated! > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-sweet-iot-acme-00.txt > Date: April 6, 2022 at 12:12:43 PM EDT > To: "Michael Sweet" >=20 >=20 > A new version of I-D, draft-sweet-iot-acme-00.txt > has been successfully submitted by Michael Sweet and posted to the > IETF repository. >=20 > Name: draft-sweet-iot-acme > Revision: 00 > Title: ACME-Based Provisioning of IoT Devices > Document date: 2022-04-06 > Group: Individual Submission > Pages: 10 > URL: = https://www.ietf.org/archive/id/draft-sweet-iot-acme-00.txt > Status: https://datatracker.ietf.org/doc/draft-sweet-iot-acme/ > Html: = https://www.ietf.org/archive/id/draft-sweet-iot-acme-00.html > Htmlized: = https://datatracker.ietf.org/doc/html/draft-sweet-iot-acme >=20 >=20 > Abstract: > This document extends the Automatic Certificate Management > Environment (ACME) [RFC8555] to provision X.509 certificates for > local Internet of Things (IoT) devices that are accepted by existing > web browsers and other software running on End User client devices. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 ________________________ Michael Sweet --Apple-Mail=_8E1E7E7A-5C35-42C1-8046-471686DB2D18 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii All,

A = proposed solution for locally-managed (and trusted) X.509 certificates, = to solve the "this web site will eat your child" errors.  I'm = working on coding up a sample implementation...

Comments/feedback is = appreciated!


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-sweet-iot-acme-00.txt
Date: = April 6, 2022 at 12:12:43 PM = EDT
To: = "Michael Sweet" <msweet@msweet.org>

A new version of I-D, draft-sweet-iot-acme-00.txt
has been successfully submitted by Michael Sweet and posted = to the
IETF repository.

Name: = = draft-sweet-iot-acme
Revision: 00
Title:= = ACME-Based Provisioning of IoT Devices
Document = date: = 2022-04-06
Group: Individual Submission
Pages:= = 10
URL: =            https://www.ietf.org/archive/id/draft-sweet-iot-acme-00.txt=
Status: =         https://datatracker.ietf.org/doc/draft-sweet-iot-acme/
Html: =           https://www.ietf.org/archive/id/draft-sweet-iot-acme-00.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-sweet-iot-acme<= br class=3D"">

Abstract:
=   This document extends the Automatic Certificate = Management
  Environment (ACME) [RFC8555] to = provision X.509 certificates for
  local = Internet of Things (IoT) devices that are accepted by existing
  web browsers and other software running on End = User client devices.




The IETF Secretariat



________________________
Michael Sweet



= --Apple-Mail=_8E1E7E7A-5C35-42C1-8046-471686DB2D18-- --Apple-Mail=_1391E75A-699D-4781-B430-A2C1DA7E629A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkIbDzcZsP1Y8+PQFvmfHXsgfMkQFAmJNvvYACgkQvmfHXsgf MkQU5Q//XvFe6RoG5JxELHQm1Ze7pbP8sGgXHaycL6tVxiHrDRaepphYilmC2O8I lmlusqMSFBUQtIzCS6rUj6KeehC05NcfZLiNg5nzCE5AuPMPqjfs+RCokaYxqVT+ d3Y+G7tQggNbbVwI6b5YmRMvGivNdQ9B9tJ2oR9VAl3wgpSDJIfgHkHnf1xxqDWS XmoziBzgjwKhJs1GXuaeADTaqKgqW88ON5IaqIJfcoEOqfKjPKqYn3Ru/xBAW+xN c8zm3XTeVFHyUUUhGNi7EoYRi3oZCYtjIdHO8XNiSqq/O6433OPYLgajxyNGM+EQ Rkdc1uN11q4M+WPPBHW6YydlAaEgZu0/rcQcogd0Zt3XVAXVcqgHHyaC3r0HIvWO UGUT8Y/uhad21eMyB7aW6oWQe6w/tTYx/Vk8POSRVDI5zCtT953Zc61fL99aINw+ a4/qps7c2dwcUE/0dqYFmLLUJsE8DhndtPNckIW/6X+RwPRo9gSSaUFtguxYvtut L2AuqhLQcxmFuapA/T+7PHbyvr5zOU1G12c5Z0S4R6o9rIDObd7fO9fWRBQL4hqI OSF/Tr/MLhNXb/T7Xw99uhJHPq5+eQpEPInt3+kB38RaNGDO4y2gQFQlhk+gug1Z hKgGFUbNv8sRe1IAhdS67wld3Bp0csuxZWznKo1MkCrhU/DJIVM= =qZq0 -----END PGP SIGNATURE----- --Apple-Mail=_1391E75A-699D-4781-B430-A2C1DA7E629A-- From nobody Thu Apr 7 02:38:38 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E9D3A1607; Thu, 7 Apr 2022 02:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B49xDo9B1Toh; Thu, 7 Apr 2022 02:38:13 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791CC3A160D; Thu, 7 Apr 2022 02:38:11 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 754B658C4AF; Thu, 7 Apr 2022 11:38:04 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5A4404EAB39; Thu, 7 Apr 2022 11:38:04 +0200 (CEST) Date: Thu, 7 Apr 2022 11:38:04 +0200 From: Toerless Eckert To: last-call@ietf.org, int-area@ietf.org, iotops@ietf.org, liaison-coordination@iab.org Message-ID: References: <164867508759.15594.2523981628049164116@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <164867508759.15594.2523981628049164116@ietfa.amsl.com> Archived-At: Subject: Re: [Iotops] Last Call: Moving TPC.INT and NSAP.INT infrastructure domains to historic X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 09:38:18 -0000 [ Disclaimer: Cc some more mailing list in the hope that it would help to reach more technical and administrative contributors to the specific aspects asked for IETF than those who can afford to track an IETF wide list such as last-call.] 0. Confused I am really confused about the email, because the subject refers to making domain infrastructures historic, whereas the text asks for making RFCs historic. I am commenting on the ask to make RFCs historic. 1. RFC1706 from Informational to Historic (DNS NSAP Resource Records) Back in the 80th/90th when i was working on CLNP (and IAB until after Kobe too ? ;-)), i already found it quite difficult back then to figure out how much CLNP was actually used, and seemingly most use was in closed industrial environments, although those deployments sometimes even just used TP4 over Ethernet, but (AFAIR) still with NSAPs. My ability to vet if or how much CLNP or in a broader sense NSAP are in active use in any closed networks has not become better. Even less so any possible use of RFC1706. So, what to do in the absence of knowledge but often reconfirmed fear of unknown usage... ? 1.a) Given how CLNP/X.233 is to the best of my understanding an active/enforced standard at ISO/OSI and ITU-T, it would certainly be useful to consider bringing the suggested change to the attention of those SDO through our liaison mechanism. Any positive feedback from their side would be extremely helpful. Short of getting real insight into how relevant/irrelevant NSAP really are today in badly visible environment, i think we do not win anything by changing status from informational to historic. Instead, we are assuming that we know something. Which i think we don't. In which case we should just keep it as is. 1.b) Personally i am saying that i wish for RFC1706 not be moved to historic, because to me historic not only means not--used, but also technically-obsolete, and given how NSAP are variable length, IPv6 is not, and many proposals in the IETF have argued for variable length addressing at the network layer to better solve problems, my opinion is that we should move something like this only to historic when we have something equal or better. E.g.: after we have updated IPv6 to also support variable length addresses. 2.) RFC1528 from Experimental to Historic I am not aware of a better, interoperable standard solution for remote printing (or should i say Internet FAX ?). Instead it feels to me as if every printer vendor has started its own proprietary remote-printing cloud-service. I hope i am wrong (pointers please), but if not, then i fear this decade old experiment is still the best we have ? See 1.b) about arguing to changing status for something where there is no new evidence of there being something better and/or the mechanism being technically flawed (as opposed to just not being enough in the interest of vendors attempting to create monopolistic silos...) Cheers Toerless On Wed, Mar 30, 2022 at 02:18:07PM -0700, The IESG wrote: > ----- > Please note: This is a second IETF LC. > > This isn't really a document (or at least a document that does anything). > The "IESG Statement on Designating RFCs as Historic" (https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/ ) says that: > "The current process, then, of moving an RFC to Historic status is to follow one of these, depending upon the level of documentation and discussion of the documentation required: > 1: [...] > 2: "An individual or a working group posts an Internet Draft containing an explanation of the reason for the status change. The I-D is discussed and iterated as usual for I-Ds. At some point, it is sent to an appropriate AD to request publication. The AD creates a status-change document, with an explanation that points to the I-D. The I-D and the status-change are then last-called together, after which the IESG evaluates and ballots on both." [...] > 3: "As #2 above, except that the I-D might also contain other information. In this case, after IESG approval the I-D is sent to the RFC Editor. When the RFC is published, the status-change document is changed to point to the RFC instead of the I-D." [...] > > This last call is *just* for the status change document (https://datatracker.ietf.org/doc/status-change-int-tlds-to-historic), which is just a supporting document for https://datatracker.ietf.org/doc/draft-davies-int-historic/ (which does the actual work and explains stuff). > Basically, this is process-wonkey - please read https://datatracker.ietf.org/doc/draft-davies-int-historic/ instead, it's much more useful an interesting... > > > ---- > > The IESG has received a request from an individual participant to make the > following status changes: > > - RFC1706 from Informational to Historic > (DNS NSAP Resource Records) > > - RFC1528 from Experimental to Historic > (Principles of Operation for the TPC.INT Subdomain: Remote Printing -- > Technical Procedures) > > The supporting document for this request can be found here: > > https://datatracker.ietf.org/doc/status-change-int-tlds-to-historic/ > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2022-04-27. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > The affected documents can be obtained via > https://datatracker.ietf.org/doc/rfc1706/ > https://datatracker.ietf.org/doc/rfc1528/ > > IESG discussion of this request can be tracked via > https://datatracker.ietf.org/doc/status-change-int-tlds-to-historic/ballot/ > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From nobody Thu Apr 7 07:11:56 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745933A0CFC; Thu, 7 Apr 2022 07:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=msweet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFQODj62ibim; Thu, 7 Apr 2022 07:11:50 -0700 (PDT) Received: from mail.msweet.org (mail.msweet.org [173.255.209.91]) by ietfa.amsl.com (Postfix) with ESMTP id E827D3A0D01; Thu, 7 Apr 2022 07:11:49 -0700 (PDT) Received: from smtpclient.apple (cbl-66-186-76-47.vianet.ca [66.186.76.47]) by mail.msweet.org (Postfix) with ESMTPSA id 3A4F980438; Thu, 7 Apr 2022 14:11:47 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.msweet.org 3A4F980438 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=msweet.org; s=default; t=1649340707; bh=85OGObW0pHTROpbGf0QOgxTNstPez6oG2sYzls8aw5M=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=JMW3uZhXP+Y5mUpmAZg96QKWGGZeeWTx3RmieYPUDHpApsS67sBgwCHR4LQzRj6i8 LBfC69gGNX45X9PEVPIWA1vfAfas7RguZSTPpBPiwLuEQZBul5smJmE0S+q4Sgg04k KzKvAizGTBFMDiCKxPgqqi4TCak1rRP+InGscyoM= Content-Type: multipart/signed; boundary="Apple-Mail=_3AACD6C9-EF9E-404C-B6F6-554FC40B2AE5"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.1\)) From: Michael Sweet In-Reply-To: Date: Thu, 7 Apr 2022 10:11:45 -0400 Cc: last-call@ietf.org, int-area@ietf.org, iotops@ietf.org, liaison-coordination@iab.org Message-Id: <18339826-74F7-411E-BCE9-67C665A1A230@msweet.org> References: <164867508759.15594.2523981628049164116@ietfa.amsl.com> To: Toerless Eckert X-Mailer: Apple Mail (2.3696.100.1) Archived-At: Subject: Re: [Iotops] Last Call: Moving TPC.INT and NSAP.INT infrastructure domains to historic X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 14:11:55 -0000 --Apple-Mail=_3AACD6C9-EF9E-404C-B6F6-554FC40B2AE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Toerless, > On Apr 7, 2022, at 5:38 AM, Toerless Eckert wrote: > ... > 2.) RFC1528 from Experimental to Historic >=20 > I am not aware of a better, interoperable standard solution for remote = printing (or should > i say Internet FAX ?). Instead it feels to me as if every printer = vendor has started > its own proprietary remote-printing cloud-service. I hope i am wrong = (pointers please), > but if not, then i fear this decade old experiment is still the best = we have ? I don't know if this was meant as serious? But FWIW the IETF published = the Internet Printing Protocol (STD 92) more than 2 decades ago, and it = is used by nearly every network printer ("billions of printers") and = most "cloud" printing services (including Microsoft's Azure-based = Universal Print Service). Any printer with "AirPrint", "IPP = Everywhere", "Mopria", or "Wi-Fi Direct" on the box supports IPP. The Printer Working Group (who is the current steward of IPP and the = variable SNMP printing MIBs) has also defined numerous IPP extensions, = including standards for cloud printing and Internet fax using a = streamable subset of PDF. So, assuming somebody doesn't just email you a file you can print it = quite easily using a single, standard protocol. [But of course telephone-based fax still hasn't died - boggles the = mind...] ________________________ Michael Sweet --Apple-Mail=_3AACD6C9-EF9E-404C-B6F6-554FC40B2AE5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkIbDzcZsP1Y8+PQFvmfHXsgfMkQFAmJO8SEACgkQvmfHXsgf MkT/Uw//Zt5491ydbFwz4jQi865mWfRIzPdUYMvKR+RZOWLupBNjWdwhtYQlMhxv 9wIQQPga2Z/FZkAXFR45q3NcUiPc4SzFr6MozpuybaRpGeetrnxj4K4ykFYo8u4l rgcGpwu33xPc5kJ81nUhQbDcqe4XWCOfejOJdYOz5Ft0RSBlweNVIqXGq2IDmt1c EX1BYD4gMVUEm9Cyf+wndepx7+rpbKs6LS3FjG3twWOOAuKI+Cs5qrbbzJytXgWG 9Yf+/zsUPuE8fFwZqgyCgBFSxJm2R9u8dgY+k4YvPz0t3NHhw2l8ESU4s8vs1ZVx R/BY3b4zhkaLUH5bIG04T7NhsHhZFaBd2H/WUbXGOyelW/kun+dzL6rieC8VFGw/ jqs1By3MUTK9a9/2AnDV784AG1aI0wNE7yCRX+1G1WOO0Gus4gsz2ARY7vOxgAd0 VUZLecBB7OUhRG21RAR0hVECpLPjmjLSq6WkdIVtWYww4EbD6QXqCgU6+d6UbJtm rLr9sNgtl7eo033J8lPtnqrdC66HvRP2Ptg4uPrL8811HJtjWsbJdP0wvHuoXfMZ 21MPekVdxtDKkL5I2+QJuETJa5H0Lvm4XQF+e/rylHG2NU1edDA6nxeUhiaX47Ui 252t/D73EUHeo98xctHFCNYUcngfVym+dWUqRgQG5AS03Lv++iQ= =70Al -----END PGP SIGNATURE----- --Apple-Mail=_3AACD6C9-EF9E-404C-B6F6-554FC40B2AE5-- From nobody Thu Apr 7 14:33:48 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA4B3A17B0; Thu, 7 Apr 2022 14:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.109 X-Spam-Level: X-Spam-Status: No, score=-7.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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAFQoulpT9NY; Thu, 7 Apr 2022 14:32:36 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9695C3A17BC; Thu, 7 Apr 2022 14:32:35 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id k13so980132plk.12; Thu, 07 Apr 2022 14:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=zvfdyMUCw+xUgAojKQzy1EHTwrCiXqNd8Yb8UrvlE20=; b=JLb4gCIaXuEoQkBzJpznt6AD/P+gYlVcnnkSC7U6X8fETyp1Ts6xe0Vjc889P6+YHx 7toP7BDWOXPNkoaPm5GD6h4oSMyB61hQZ/H8HfAAPFsn/pYLGz3Z49KTDY7t/EoXvt29 4VRhFM2wIWFM/48WWv6cb7AIOQYunytPFZPx/1mToP8QCCcQQZZg5FKCI9+nUlfj9naG Kx2vzl/6CAZsA2Vj3rvk7KdYfMLKor2Wo+bnwABWrQqaepKyjlN0wpHBxZcQQea8SlVC GYzuz/s6akE677SKQonvKiAZ97Rpye8Pfhz9tFXVAFStYTj76wPeA81t1dzAIwYvQNZc NTAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zvfdyMUCw+xUgAojKQzy1EHTwrCiXqNd8Yb8UrvlE20=; b=ZQL//V7kiboB92UidU2zrmDrfeqK9kZMf+hVjGYYiWyumW63dUZLGq6FXyr8CZvqg4 VqzzKGB/Vt0y56USCOf/7BfO5unj5ahMFMHFBxR2MVI348x1RkFG2y0y8Z0pZ9MO5cam ZumTkQSm0uhNjzOT6aUzw4SmCSLDc5DR+ciS8njsmuyzjKvznsV0ms5Vka5P6yKRRJhm ovVlewwmz3UFI7q1NmZAMxUtBlr4NAt9h5pN4zywjVIdUxPO7SCvCwBQub8/OdBgJTKM ZjxxvFTsQyCf1V8f+TLYZGMUjmXsN+K8OKZ83uHKKFcieyYhQLsiQEbuGcQRR5U57+fR UP9A== X-Gm-Message-State: AOAM531EZm1ARx5QIF/2ZCHW5C8Ko45PpkQXSIgIZYxkLRhqh4GFkgiT QiU2ryGiNmSAGlbeXRw/UgxWQlpl+Al06g== X-Google-Smtp-Source: ABdhPJwjalqzG5r218Uh7UG/vPz9R2y1HZBh2NPSkF9UmXMxBIwQ+tFcC+emY5Gpaf7ygbIfjS6v3w== X-Received: by 2002:a17:903:283:b0:153:ad21:21d3 with SMTP id j3-20020a170903028300b00153ad2121d3mr15830912plr.163.1649367154167; Thu, 07 Apr 2022 14:32:34 -0700 (PDT) Received: from ?IPv6:2406:e003:1005:b501:80b2:5c79:2266:e431? ([2406:e003:1005:b501:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id d21-20020a634f15000000b0039ce7158664sm1043999pgb.68.2022.04.07.14.32.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Apr 2022 14:32:33 -0700 (PDT) To: Toerless Eckert , last-call@ietf.org, int-area@ietf.org, iotops@ietf.org, liaison-coordination@iab.org References: <164867508759.15594.2523981628049164116@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <1953ebcb-a8b1-2693-b955-2a89074f3413@gmail.com> Date: Fri, 8 Apr 2022 09:32:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Iotops] Last Call: Moving TPC.INT and NSAP.INT infrastructure domains to historic X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 21:32:41 -0000 Toerless, I've seen no evidence that nsap.int is used by anyone anywhere for anything. If there was any use for it, I'm sure it would have been migrated to nsap.arpa a long time ago. Regards Brian On 07-Apr-22 21:38, Toerless Eckert wrote: > [ Disclaimer: Cc some more mailing list in the hope that it would help to reach > more technical and administrative contributors to the specific aspects asked for > IETF than those who can afford to track an IETF wide list such as last-call.] > > 0. Confused > > I am really confused about the email, because the subject refers to making domain > infrastructures historic, whereas the text asks for making RFCs historic. I am > commenting on the ask to make RFCs historic. > > 1. RFC1706 from Informational to Historic (DNS NSAP Resource Records) > > Back in the 80th/90th when i was working on CLNP (and IAB until after Kobe too ? ;-)), > i already found it quite difficult back then to figure out how much CLNP was actually used, > and seemingly most use was in closed industrial environments, although those > deployments sometimes even just used TP4 over Ethernet, but (AFAIR) still with > NSAPs. My ability to vet if or how much CLNP or in a broader sense NSAP are > in active use in any closed networks has not become better. Even less so any > possible use of RFC1706. So, what to do in the absence of knowledge but often > reconfirmed fear of unknown usage... ? > > 1.a) > Given how CLNP/X.233 is to the best of my understanding an active/enforced > standard at ISO/OSI and ITU-T, it would certainly be useful to consider bringing > the suggested change to the attention of those SDO through our liaison mechanism. > Any positive feedback from their side would be extremely helpful. > > Short of getting real insight into how relevant/irrelevant NSAP really are today > in badly visible environment, i think we do not win anything by changing status > from informational to historic. Instead, we are assuming that we know something. > Which i think we don't. In which case we should just keep it as is. > > 1.b) > > Personally i am saying that i wish for RFC1706 not be moved to historic, > because to me historic not only means not--used, but also technically-obsolete, > and given how NSAP are variable length, IPv6 is not, and many proposals in the IETF > have argued for variable length addressing at the network layer to better solve > problems, my opinion is that we should move something like this only to historic > when we have something equal or better. E.g.: after we have updated IPv6 to > also support variable length addresses. > > 2.) RFC1528 from Experimental to Historic > > I am not aware of a better, interoperable standard solution for remote printing (or should > i say Internet FAX ?). Instead it feels to me as if every printer vendor has started > its own proprietary remote-printing cloud-service. I hope i am wrong (pointers please), > but if not, then i fear this decade old experiment is still the best we have ? > > See 1.b) about arguing to changing status for something where there is no new > evidence of there being something better and/or the mechanism being technically > flawed (as opposed to just not being enough in the interest of vendors attempting > to create monopolistic silos...) > > Cheers > Toerless > > On Wed, Mar 30, 2022 at 02:18:07PM -0700, The IESG wrote: >> ----- >> Please note: This is a second IETF LC. >> >> This isn't really a document (or at least a document that does anything). >> The "IESG Statement on Designating RFCs as Historic" (https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/ ) says that: >> "The current process, then, of moving an RFC to Historic status is to follow one of these, depending upon the level of documentation and discussion of the documentation required: >> 1: [...] >> 2: "An individual or a working group posts an Internet Draft containing an explanation of the reason for the status change. The I-D is discussed and iterated as usual for I-Ds. At some point, it is sent to an appropriate AD to request publication. The AD creates a status-change document, with an explanation that points to the I-D. The I-D and the status-change are then last-called together, after which the IESG evaluates and ballots on both." [...] >> 3: "As #2 above, except that the I-D might also contain other information. In this case, after IESG approval the I-D is sent to the RFC Editor. When the RFC is published, the status-change document is changed to point to the RFC instead of the I-D." [...] >> >> This last call is *just* for the status change document (https://datatracker.ietf.org/doc/status-change-int-tlds-to-historic), which is just a supporting document for https://datatracker.ietf.org/doc/draft-davies-int-historic/ (which does the actual work and explains stuff). >> Basically, this is process-wonkey - please read https://datatracker.ietf.org/doc/draft-davies-int-historic/ instead, it's much more useful an interesting... >> >> >> ---- >> >> The IESG has received a request from an individual participant to make the >> following status changes: >> >> - RFC1706 from Informational to Historic >> (DNS NSAP Resource Records) >> >> - RFC1528 from Experimental to Historic >> (Principles of Operation for the TPC.INT Subdomain: Remote Printing -- >> Technical Procedures) >> >> The supporting document for this request can be found here: >> >> https://datatracker.ietf.org/doc/status-change-int-tlds-to-historic/ >> >> The IESG plans to make a decision in the next few weeks, and solicits final >> comments on this action. Please send substantive comments to the >> last-call@ietf.org mailing lists by 2022-04-27. Exceptionally, comments may >> be sent to iesg@ietf.org instead. In either case, please retain the beginning >> of the Subject line to allow automated sorting. >> >> The affected documents can be obtained via >> https://datatracker.ietf.org/doc/rfc1706/ >> https://datatracker.ietf.org/doc/rfc1528/ >> >> IESG discussion of this request can be tracked via >> https://datatracker.ietf.org/doc/status-change-int-tlds-to-historic/ballot/ >> >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > From nobody Fri Apr 8 02:02:30 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777E43A18C1; Fri, 8 Apr 2022 02:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXSTlNya1MSr; Fri, 8 Apr 2022 02:02:24 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on072a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::72a]) (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 766F63A18BF; Fri, 8 Apr 2022 02:02:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WMBKFpXRGKG+9zxWcL0Tfnx60jRl4/N9g2escnpVa69HdBHiLCrHdu51zeJdV8xPA9Zl9TChGz5fjkKTZ10wXjQZesE4mpCAV02SS1dtYWztXXPA6L/rUlen9bL+Z40nbYf9NaUDNPxFh0xUNoO5B8N1b3xEk8f3PMfNnN4wRu6Dnbe3RamF9IWopBudpBw+slMK8Vyg92tOgYT67nDp9qMS7fRUMbNXZgxhTKIU4mjw5+6FYziTYgOAwKFT+CFRgsC0mpYyFIC/Iy/vq2oh6lrP59oc4cZQ61IGKZQ8wz4WZD/r6Zhh8D9NXWOf8o7J5mXxltCh+IdXKqVAM4XUDQ== 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=vj71sdwCshxFj2T3whPX9LXDiUA27Uok3Q6zKXHXd6Q=; b=fvh17DJ0hwW7DiaFFVUBEEfH9UQMJnLVXJGJVXCd9E29TaTA0QLnGgUJujBBiI2EOy5uyOh0NiJzzozNfZODzhU7dZGK+KfA5SUlJjI89f/79o4BMt1uyuCdmDC+RDrFMg/hX04en7t5X/RhiDorhxXY31FSqxRS6qHVCx93/jlVIOhHHRNQIVgo11BZwp8AztRye2OumMS9pkiWk3Imd0x06SSlghZyG0rTr0/psOffX1HKPKDq+R1BTNwyYW3Hu97+s/cR5wynB9NFv2G4six2POEWCiYZyrMxaa35hI4wezfB4/kuvJ7OF1+ZpdTJihzCY/LwgUaJZrsBiTlUMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vj71sdwCshxFj2T3whPX9LXDiUA27Uok3Q6zKXHXd6Q=; b=DR/vI+fgs6YfpHTKb6ETS7ujrAAqu0TMTMwCuBXY9GwX+FKXZqu5tprPt25JkkyBFSA31PsKUseYERYBdqFcHx1k66ILZ6IWqLKAA3DRp8QFcaXQ3d72HeiNmLY3Ct9V/hzP9OTnCVvPs1Sidyp8vb5pOIi7o/dsajyewotLDt4= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by DB7PR07MB4840.eurprd07.prod.outlook.com (2603:10a6:10:5a::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.11; Fri, 8 Apr 2022 09:02:18 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::b1c5:beb7:ddbf:b358]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::b1c5:beb7:ddbf:b358%9]) with mapi id 15.20.5164.008; Fri, 8 Apr 2022 09:02:18 +0000 From: tom petch To: Michael Sweet CC: "int-area@ietf.org" , "iotops@ietf.org" Thread-Topic: [Int-area] YANG was Last Call: Moving TPC.INT and NSAP.INT infrastructure domains to historic Thread-Index: AQHYSydZjJXk69n390Gsnq7NM9bB5g== Date: Fri, 8 Apr 2022 09:02:18 +0000 Message-ID: References: <164867508759.15594.2523981628049164116@ietfa.amsl.com> <18339826-74F7-411E-BCE9-67C665A1A230@msweet.org> In-Reply-To: <18339826-74F7-411E-BCE9-67C665A1A230@msweet.org> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: da1642f8-c80a-4f9f-e004-08da193e7bf3 x-ms-traffictypediagnostic: DB7PR07MB4840: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: HS26rvz6KJYVmDyd+i0icQspxoVHjt5W8xcdDE7tB4b0hHT1zJxW5Sgec94MOEUwOYlU7dNxIvfQIP07em90lMSwqcpMkDPmh9jhmfty3yxUqhYtJDNWPODOfh3tS2rUkIyvBU+MP6vYwsuPvBkX1N1g1IHz/rm5affdgFQXJQIgbD1Sf0za5vkXFvgxXqi7dXV/F0Gnrp2/9AlTAjymitE27BM/riJ71ACvP5JRuiD7DgJrzuHiePOhaHuF2gTIBUnsTOv7DH4Qslv3Xhsu5SWjfczzxN6QbuosKG5JjBDTPRf82Rurw4w9VbnVoSmah3s1GtYCAKxIMDFhjFroBVBrozHRTXzLMmfRcaZW28eSG0rYAVvhEn+u4I/+k1CaiuRcpi1D2SNT4acozAcqRuXEgNJkMX860B6AqUEl1UJO+G3paXBhDZYdpPrM63ksGu1WE1Hg2toS9NaM8eoQoMNnrIsl98q7wWirZvQuqd3mXKno2KNLmZwctRMbiEply4bTURfuL9tybIDusX3iuk0yYgbPzGgWGoNHJq6MGGO1FwTk7KNdelT0u5tv51/FqgWzcBFSxnqKu7JTv/XngrlalCgHIjLgBVt/pGo4pGuFIfe/PVhg+J6lvJLWG7eye1xAdKmLQNjALLHvvQhWFwImlxUvrkKlSWN3ugfipeUNeECSUV2sLiMIT4L9s30MTOCicWyPD3u6oScgvP67ng== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(54906003)(38070700005)(55016003)(122000001)(76116006)(5660300002)(508600001)(86362001)(38100700002)(45080400002)(82960400001)(91956017)(66946007)(66556008)(8676002)(64756008)(66446008)(66574015)(4326008)(66476007)(33656002)(52536014)(8936002)(53546011)(9686003)(7696005)(6506007)(26005)(186003)(316002)(71200400001)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?d+hHXc8iCB1Hn9eX2fVOMDGFo3c+HuP0Rqv3BXoZexaxULkIMm9zq6dySj?= =?iso-8859-1?Q?NKAxZpjgQoWnweZn9gMbalZSLNiXMfGcq7PdkXYKKxtZe47gDHo9OxwWvL?= =?iso-8859-1?Q?sGaemN1DIs/3/t+m1GmY+GfG/MMC6TojS5v7hcJkV/aIMDxJ88xWdSQqrH?= =?iso-8859-1?Q?U9nxr52iDvS1a4X3JNtpIWewMqkz+J2bE/v1zAJ/bd83K+fx92bIAFMCJt?= =?iso-8859-1?Q?c496EDRuOikvLTTkFxUKcnsODNWl9PxFXZCnTIe9v3FcdZUdqiLZzwma2a?= =?iso-8859-1?Q?3Eha5c/l/DPvn/wIYvcnYVWm1WUdLxOJ8AaWm8D/HvQeg7Wr5jlRmzuX1f?= =?iso-8859-1?Q?JLVQlbyenXV2q26p+/+smOJ2gd9tBoQYFzm6dThM2HcOZC9+ttfeot/mxW?= =?iso-8859-1?Q?sih7tv+V34La/JTXknu07dlDdMvxn9+yx14fXXEnvMZb5Z6noxpqtBlY7R?= =?iso-8859-1?Q?EuRQXp1t+R2Rz/Dz//0fkY6oeXeBraio3uZouvN0LPXpUD5LMxegKcn6kJ?= =?iso-8859-1?Q?QC7+vQDMrhe7AvhhnET4uPpoZNjZ5dYrfZggCUgLbCs4dWeM/lkYD8uNUc?= =?iso-8859-1?Q?/IZB7YIS/8s2LrkX0TYPt6VC6r8liC877D7s4HkhgY+p0QOo4MXIDtebHR?= =?iso-8859-1?Q?k1pZ18/dfTR13QgSnEqwPbboa8rjSmfOOZgSI6rsoOr32Ttx/o8i+tMUNF?= =?iso-8859-1?Q?MEVq6rnSzRgwSBgHdBLOMWZ5JmNYbsTXaLOHPd+tWL/wPlIqnPFQ5/dNYk?= =?iso-8859-1?Q?fLMLLRuOBkD7Sam/0dKCo9eQmVS3bLIEDHyW6J634OlftsUels9wXK1k12?= =?iso-8859-1?Q?wZQGqvm3JAQZR/2aRF5ZAtam5esou/07L9/99X8l8S2IG7N1U0SkJwvcqH?= =?iso-8859-1?Q?KZFY97NaLNpFAbRK0ZZ64owCdGKYQrZt4MFS04u5Muq5DHvXQ8Z5mr1oR3?= =?iso-8859-1?Q?KyzkePjJS7yrzwsrrwLFYK6/PR1f2iP29ZXlpmAro6wFWptEEUXPmZEaEu?= =?iso-8859-1?Q?CVhmGTk7sB40Tx8NmmGjAc/HaJvuNrprx4ltRIwWL7XKC08XsmDqNJD/DG?= =?iso-8859-1?Q?xeFRmxJTAoGCsfOXap0geB/OX0FR9Zy6VZmlZFynHRwpOe+QjZLFZbgFnb?= =?iso-8859-1?Q?/oscGOY2hpsWlsOMsk7rErV7+0Eg5iAnCm6xwj08mjlskW7E8JSQaAaeAw?= =?iso-8859-1?Q?CYWO9fJXw1fKvLbh4XCH6RySEYnrdeOYWbHWjRDAA3kNoYaeGp+Vtmwd7I?= =?iso-8859-1?Q?rNZhspk2Rw9l96OlD490XLOuWyUxrAHZz1yeIHrzAqvYSSNlwWGSi+I4Ht?= =?iso-8859-1?Q?vihAq2PhYXEJMQdDhRN08EYqqVsF/jFLUXn86PYZhyMFXrY9xQYkva5uFd?= =?iso-8859-1?Q?kGHPPQ3r+RKSklG74xOKqb0SpXW9VnG7e8Lu/BD02IgrxOf5nU07Kswibf?= =?iso-8859-1?Q?TvyoZ4Ft1LvbYNym/14duQDLLxLPr12KcQ3LtcEcureS/FpFWt/w9VYxcn?= =?iso-8859-1?Q?d3RzKD3OHqtn71DOMo6jjw02SwShj3QUrvkf13ZsRwC6GECH14g0sxnkJs?= =?iso-8859-1?Q?q/soycg7Jq62yWDR/tqwxiuYF0YsB0i6ez6QqgOIe8f8v9fnYbc6FO+xD6?= =?iso-8859-1?Q?HyMUVxfXmbLFeDoXJ5xFjzVIOxmGIsvy9P4ZJEJcNga6o60hmyvximliI+?= =?iso-8859-1?Q?K+5vPLIZVvFiOqipSFT6XlkuULlALWDrfP8llGOeKbKppqsvZwdOMfwA5M?= =?iso-8859-1?Q?UoFOMs1R0icH59c+O44VKKaVAeGPIvxlSHul1v+eb3pBMQDJUrmob80rwf?= =?iso-8859-1?Q?tbsG4RVSUg=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: da1642f8-c80a-4f9f-e004-08da193e7bf3 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2022 09:02:18.3656 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WeisOKkV0Vu7ewESTv8AzboObC3YqqGIuAfJw1RKfTzSnCkxbzlM8fbFQWuu/B9ylLrm9jgGqgIuj1IjUSw6QA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4840 Archived-At: Subject: Re: [Iotops] [Int-area] YANG was Last Call: Moving TPC.INT and NSAP.INT infrastructure domains to historic X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 09:02:29 -0000 From: Int-area on behalf of Michael Sweet =0A= Sent: 07 April 2022 15:11=0A= Re: [Int-area] [Iotops] Last Call: Moving TPC.INT and NSAP.INT infrastructu= re domains to historic=0A= =0A= Michael=0A= =0A= I am well familiar with the work of IPP in the IETF. You mention MIBs whic= h I know of. Is there anything similar in YANG?=0A= =0A= Tom Petch=0A= =0A= =0A= Toerless,=0A= =0A= > On Apr 7, 2022, at 5:38 AM, Toerless Eckert wrote:=0A= > ...=0A= > 2.) RFC1528 from Experimental to Historic=0A= >=0A= > I am not aware of a better, interoperable standard solution for remote pr= inting (or should=0A= > i say Internet FAX ?). Instead it feels to me as if every printer vendor = has started=0A= > its own proprietary remote-printing cloud-service. I hope i am wrong (poi= nters please),=0A= > but if not, then i fear this decade old experiment is still the best we h= ave ?=0A= =0A= I don't know if this was meant as serious? But FWIW the IETF published the= Internet Printing Protocol (STD 92) more than 2 decades ago, and it is use= d by nearly every network printer ("billions of printers") and most "cloud"= printing services (including Microsoft's Azure-based Universal Print Servi= ce). Any printer with "AirPrint", "IPP Everywhere", "Mopria", or "Wi-Fi Di= rect" on the box supports IPP.=0A= =0A= The Printer Working Group (who is the current steward of IPP and the variab= le SNMP printing MIBs) has also defined numerous IPP extensions, including = standards for cloud printing and Internet fax using a streamable subset of = PDF.=0A= =0A= So, assuming somebody doesn't just email you a file you can print it quite = easily using a single, standard protocol.=0A= =0A= [But of course telephone-based fax still hasn't died - boggles the mind...]= =0A= =0A= ________________________=0A= Michael Sweet=0A= =0A= =0A= =0A= From nobody Fri Apr 8 06:23:26 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EB83A1A0C; Fri, 8 Apr 2022 06:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=msweet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pwgQP9jtE9O; Fri, 8 Apr 2022 06:23:18 -0700 (PDT) Received: from mail.msweet.org (mail.msweet.org [173.255.209.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA233A1A08; Fri, 8 Apr 2022 06:23:18 -0700 (PDT) Received: from smtpclient.apple (cbl-66-186-76-47.vianet.ca [66.186.76.47]) by mail.msweet.org (Postfix) with ESMTPSA id 73F3B81DA5; Fri, 8 Apr 2022 13:23:17 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.msweet.org 73F3B81DA5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=msweet.org; s=default; t=1649424197; bh=orEbQDMpwOSrtReb1n5SkgXAoMYBbuGN7WjJOOSDnmc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=MeY2tSF7VYVhHC02qs/UaZPE1C3qEh4dWN7neyca4ZYIyxG+f0Ox5bSHMqCwIEKtx ZO61+N6DpXw46FuS2FgFroH1In24mRuDwzuSqTTr3osmoBqsPz4CS7Bomqe1EFt4d9 o4PVhTT5ONWN9Z9fD6vJ8H1KUsj0UGxysoeYNe28= Content-Type: multipart/signed; boundary="Apple-Mail=_69F0B873-B93C-464D-B158-C2339C413B82"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.1\)) From: Michael Sweet In-Reply-To: Date: Fri, 8 Apr 2022 09:23:15 -0400 Cc: Michael Sweet , "int-area@ietf.org" , "iotops@ietf.org" Message-Id: <87B698E6-CE3A-4334-B77B-EA45BBC06E45@msweet.org> References: <164867508759.15594.2523981628049164116@ietfa.amsl.com> <18339826-74F7-411E-BCE9-67C665A1A230@msweet.org> To: tom petch X-Mailer: Apple Mail (2.3696.100.1) Archived-At: Subject: Re: [Iotops] [Int-area] YANG was Last Call: Moving TPC.INT and NSAP.INT infrastructure domains to historic X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 13:23:24 -0000 --Apple-Mail=_69F0B873-B93C-464D-B158-C2339C413B82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tom, > On Apr 8, 2022, at 5:02 AM, tom petch wrote: >=20 > From: Int-area on behalf of Michael Sweet = > Sent: 07 April 2022 15:11 > Re: [Int-area] [Iotops] Last Call: Moving TPC.INT and NSAP.INT = infrastructure domains to historic >=20 > Michael >=20 > I am well familiar with the work of IPP in the IETF. You mention MIBs = which I know of. Is there anything similar in YANG? Not that I am aware of, but doing a YANG model for IPP to allow = configuration via NETCONF is certainly feasible - the IPP model and = semantics are well insulated from the transport and = implementation/encoding details. In fact, the Printer Working Group spent quite a few years developing an = XML schema for the IPP model and semantics (RFC 8011) and various = printing MIBs, what is known collectively as the PWG Semantic Model. = However, its usage has been limited to bridging mechanisms with other = vendor/standard printing models since IPP is generally able to work = everywhere... ________________________ Michael Sweet --Apple-Mail=_69F0B873-B93C-464D-B158-C2339C413B82 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkIbDzcZsP1Y8+PQFvmfHXsgfMkQFAmJQN0MACgkQvmfHXsgf MkRB9g//XRK9Lboki4BytG4bG4zQzQ9mhEY/w26DPGF/xYCWbBpveAZsd8H8NA/6 X1+OeY+xo48niqnqoGK+4qCP+QMtE4skgO6b4BeS2FL41lUaqPf70vw0w1MmM5W5 INISM8ysDVm8XsbOILju+9/pxzaHPApwaNYqGypjFI0ZpuJCMbvdJI+9f1nkxn8I Lbh6GZcReOAc8vGzvHvqwoTR7wN11RLi+LrM6UugIPeLCD3KAQ5bSobC9HdTZCzl 2La1mQ/oGiSNQrNWOXbu87gifpNhJG7X1DhQXgaggFJS5TenykVq+irlPll/30md g5QO92WkJCWrlKw20tPFP4jz25IMCq6onXqGlEtyshzdnOiwGmymtNVA+d7mIuEN EY0vV1eEEQfuC3LiPGK94o3rLjUy2QkzYCZzZrjDY2y9d2CoiFXbWvHfSZvVtBfu 4py4I/+GP0mLzpD3Nuar71oPRPeusFcwg5RfNn1EKedZFtV6bu0qdVatQH0PEa8i dYqqbZliF14jPokEeT2hcWXh6qPTXeDgYjUTEW0OSclgZotytUUSva/FOOaqGY5N btaLaaeL/EhR1DIqkDblfuQocxZ1YJKJHxdSrGQdo+3Den06uyOcnX24ZRynnXVS hI4gop5+8k0mY7+JC+ILNzbs/rcbNLxW4lrHhrHzG5MxXdmN+xU= =ZXJn -----END PGP SIGNATURE----- --Apple-Mail=_69F0B873-B93C-464D-B158-C2339C413B82-- From nobody Mon Apr 11 10:19:38 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@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: [Iotops] comments on draft-ietf-uta-tls13-iot-profile-04: X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations 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 Wed Apr 13 10:41:25 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA613A1C06 for ; Wed, 13 Apr 2022 10:41:14 -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 gefb95vbvSQg for ; Wed, 13 Apr 2022 10:41:09 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BBFC3A1C07 for ; Wed, 13 Apr 2022 10:41:08 -0700 (PDT) Received: from dooku.sandelman.ca (desktop4.sandelman.ca [209.87.249.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 579C21F4A7; Wed, 13 Apr 2022 17:41:04 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 1335D1A0480; Wed, 13 Apr 2022 13:03:09 -0400 (EDT) From: Michael Richardson To: Michael Sweet , iotops@ietf.org In-reply-to: References: <164926156380.8707.8732915494613186098@ietfa.amsl.com> Comments: In-reply-to Michael Sweet message dated "Wed, 06 Apr 2022 12:25:26 -0400." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Wed, 13 Apr 2022 13:03:09 -0400 Message-ID: <387994.1649869389@dooku> Archived-At: Subject: [Iotops] comments on draft-sweet-iot-acme-00.txt X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2022 17:41:14 -0000 --=-=-= Content-Type: text/plain Michael Sweet wrote: > A proposed solution for locally-managed (and trusted) X.509 > certificates, to solve the "this web site will eat your child" errors. > I'm working on coding up a sample implementation... > Comments/feedback is appreciated! As I understand it, 1) I need to teach all the browsers which I will use at my home include this new trust anchor, and ideally, to trust it only for .local. If I don't do a path restriction for .local, then the new anchor could impersonate any web property. That comes with significant liability, since they could intercept my bank cookies, steal the end users' money, etc. And, even when I do that path restriction, if there are multiple places that do this, then I might need to trust multiple anchors to speak for .local. (The one at my home, my parents' home, the small nursury school, the church office, ....) I'm unaware of protocols to discover local trust anchors on a per-provisioning domain basis. But actually, it's something we probably need. Perhaps that's something you'd be interested in working on? 2) The innovation here is using RFC8555 to enroll rather than, say, RFC7030, or CSA/MATTER, or OPC UA, or... * We still need to setup a local certification authority someplace. * We need to teach IoT devices to do RFC8555. So for this proposal to fly, three things need to happen: a) updates to browser. b) updates to IoT devices c) updates to local network to have ACME server Please see our SUIB talks at IETF112 and IETF113. I can't see how this is different than the requirements to deploy RFC8995 in he home. It also seems to include no authorized transfer of ownership, nor does it seem to deal with how to get (unique, per-device, because RCM) WiFI credentials to the device. >> Begin forwarded message: >> >> From: internet-drafts@ietf.org Subject: New Version Notification for >> draft-sweet-iot-acme-00.txt Date: April 6, 2022 at 12:12:43 PM EDT To: >> "Michael Sweet" >> >> >> A new version of I-D, draft-sweet-iot-acme-00.txt has been >> successfully submitted by Michael Sweet and posted to the IETF >> repository. >> >> Name: draft-sweet-iot-acme Revision: 00 Title: ACME-Based Provisioning >> of IoT Devices Document date: 2022-04-06 Group: Individual Submission >> Pages: 10 URL: >> https://www.ietf.org/archive/id/draft-sweet-iot-acme-00.txt Status: >> https://datatracker.ietf.org/doc/draft-sweet-iot-acme/ Html: >> https://www.ietf.org/archive/id/draft-sweet-iot-acme-00.html Htmlized: >> https://datatracker.ietf.org/doc/html/draft-sweet-iot-acme >> >> >> Abstract: This document extends the Automatic Certificate Management >> Environment (ACME) [RFC8555] to provision X.509 certificates for local >> Internet of Things (IoT) devices that are accepted by existing web >> browsers and other software running on End User client devices. >> >> >> >> >> The IETF Secretariat >> >> > ________________________ Michael Sweet > ---------------------------------------------------- > Alternatives: > ---------------------------------------------------- > -- > Iotops mailing list Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCgAdFiEEow/1qDVgAbWL2zxYcAKuwszYgEMFAmJXAkwACgkQcAKuwszY gEPYjwwApZYxBLQAcPuyCjlRd66gI0utolwrOBTgPbNhqWZilw62tiN06tMtVZmY vL5Q+D0mQ3vifJm0tJsAC4eIGFCa9UjsW8jXgO/Y4TPuOE3Z+BpN7yI694cGDfWd uwdRA+VrG5jj3GAAMsCu346fhe0c/Z9P6dz92D7Q0xYVhQQ+bnwG9WYB4afPtZka O17KPxla76t4D8+SxT67ywBe+xnPb//q0Ep60yJKrbOIlgB31MhnhWl6nTZH/SQ5 qAQCfzzecWhnxGt6Ie4+OUfDNDQ+B7OPtlBR7dy7etwGS46Tm81y14Xw6GhLEBX2 85GTefwnsL2JZsNw5D6WYcKbW4tVhCd3mSbyVq37o9rjYOFhVGGCJxifrlKCPbmO UVIuRUsAC0Fkm8FGxwVBPvmVJEuDIqvTZC8Y21M5ZpVgKuY44c86uQY5/h6McgRI Bviurnp9Q9Wb3pULsXJxMDKevlknMMr0SvIAzqWfS3B8FDuLB6anKs3v84KxTNFQ J3hIgghB =2NMG -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 13 13:00:55 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7D73A0BA6 for ; Wed, 13 Apr 2022 13:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.11 X-Spam-Level: X-Spam-Status: No, score=-7.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=msweet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNJvOUiXR44J for ; Wed, 13 Apr 2022 13:00:46 -0700 (PDT) Received: from mail.msweet.org (mail.msweet.org [173.255.209.91]) by ietfa.amsl.com (Postfix) with ESMTP id DDEE23A0B90 for ; Wed, 13 Apr 2022 13:00:46 -0700 (PDT) Received: from smtpclient.apple (cbl-66-186-76-47.vianet.ca [66.186.76.47]) by mail.msweet.org (Postfix) with ESMTPSA id E4D238238B; Wed, 13 Apr 2022 20:00:45 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.msweet.org E4D238238B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=msweet.org; s=default; t=1649880046; bh=qJFqzx9QR+y/otwaROuVpgSnbbEE8IorHKUfteHfCgo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=L4uWLI8rzXyRzarc7kuWspgve2VI1YH/zeVa3TE3D4svC5o77jkLeGPW/9Reo0tUU aOOK3u752/CqA1K7rlhXOSJmQ8lW+sLZC31XyJQmYpHisMqM5tVzeifYvXZi2p261W WbB1aToPKmtybghgKqfgQCO9sG3bHSDblkrHe47Q= Content-Type: multipart/signed; boundary="Apple-Mail=_35DE17AA-5AA9-43B9-BE41-41505A6B43A3"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.1\)) From: Michael Sweet In-Reply-To: <387994.1649869389@dooku> Date: Wed, 13 Apr 2022 16:00:44 -0400 Cc: Michael Sweet , iotops@ietf.org Message-Id: References: <164926156380.8707.8732915494613186098@ietfa.amsl.com> <387994.1649869389@dooku> To: Michael Richardson X-Mailer: Apple Mail (2.3696.100.1) Archived-At: Subject: Re: [Iotops] comments on draft-sweet-iot-acme-00.txt X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2022 20:00:53 -0000 --Apple-Mail=_35DE17AA-5AA9-43B9-BE41-41505A6B43A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Michael, > On Apr 13, 2022, at 1:03 PM, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Michael Sweet wrote: >> A proposed solution for locally-managed (and trusted) X.509 >> certificates, to solve the "this web site will eat your child" = errors. >> I'm working on coding up a sample implementation... >=20 >> Comments/feedback is appreciated! >=20 > As I understand it, >=20 > 1) I need to teach all the browsers which I will use at my home = include this new > trust anchor, and ideally, to trust it only for .local. > If I don't do a path restriction for .local, then the new anchor = could > impersonate any web property. That comes with significant = liability, > since they could intercept my bank cookies, steal the end users' = money, etc. Correct. Ideally this would be done at the OS level (Windows and macOS = both have what is needed to support this, and I think there has been = some recent work for Linux desktops as well) so that the browsers can = just ask the OS whether to trust a certificate for an mDNS hostname, but = it would be easy enough to implement in the browsers as well. > And, even when I do that path restriction, if there are multiple = places > that do this, then I might need to trust multiple anchors to speak = for .local. > (The one at my home, my parents' home, the small nursury school, the > church office, ....) Right, that is why you need to tie the trust anchor to the router's MAC = address (or some other unique identifier). Switch networks/routers and = you need to update the current local trust anchor. > I'm unaware of protocols to discover local trust anchors on a > per-provisioning domain basis. But actually, it's something we = probably > need. > Perhaps that's something you'd be interested in working on? Yes, specifically because I've been dealing with this issue basically = since CUPS got TLS support (20 years ago or so...) > 2) The innovation here is using RFC8555 to enroll rather than, say, = RFC7030, > or CSA/MATTER, or OPC UA, or... >=20 > * We still need to setup a local certification authority someplace. I'm hoping to end up with an implementation that can be embedded in = wireless routers. > * We need to teach IoT devices to do RFC8555. ... and have code that IoT devices can use to do so. :) > So for this proposal to fly, three things need to happen: >=20 > a) updates to browser. and/or OS, which would make supporting local trust anchors easier/more = reliable. > b) updates to IoT devices > c) updates to local network to have ACME server ... which should be pretty straight-forward on existing enterprise = networks which often have CA servers for company subdomains. For home = networks we need to get the server running on the router. > Please see our SUIB talks at IETF112 and IETF113. I've seen both presentations; sadly, I spent most of my 13 years at = Apple lobbying the security and browser folks to support self-signed = certificates for .local and link-local/private IP addresses, and every = year the warning/error messages got worse. So my confidence that we can = get browsers to support self-signed certificates with a TOFU policy is = 0. Client-driven PKI solutions still need a valid trust anchor, which in = general means a locally-distributed self-signed root (for .local) and/or = a CA-signed root (for example.com) that a (local/public) CA uses to = generate the device certificate. In my experience, managing per-device = (not to mention web server) certificates by hand doesn't scale, thus = ACME... My ACME draft is basically a "Gateway Issued Certificate" solution, just = without vendor lock-in/global oversight. If you can trust your DHCP = server/router to connect you to the Internet, you can trust it to manage = the X.509 certificates for your network or tell you which server is = doing the job... If you can't (e.g., public Wi-Fi) then you *don't* use = IoT-ACME and you *don't* use the local trust anchor. > I can't see how this is different than the requirements to deploy = RFC8995 in > he home. It also seems to include no authorized transfer of = ownership, nor > does it seem to deal with how to get (unique, per-device, because RCM) = WiFI > credentials to the device. One problem with RFC8995 is the notion that a manufacturer should have = any control over provisioning/transfer of ownership. Too many = manufacturers have either gone out of business, stopped supporting = "legacy" products, and/or added lock-in restrictions to their products = (ink/toner cartridges with chips, etc.), leaving the customer with a = paperweight in the end. Another problem is that you need Internet access to use your device, and = there are enough situations where you don't have access (intentionally = or not). We shouldn't create more reasons why you need to be online = 100% of the time just for your device to work *locally*. Finally, you need to get manufacturers on board to provide an = always-available cloud service with the corresponding liability of being = a CA, (necessarily) tracking every user's device, and protecting that = data from disclosure forever (on penalty of serious fines from the EU, = etc.) If there is a data breach, that likely will mean revoking ALL of = the device certificates that have been issued and somehow getting them = to re-register once the service is back up. WRT getting an IoT device on a network, there are already standards for = that for Ethernet and Wi-Fi, plus plenty of vendor solutions that offer = different levels of security/confidentiality. Adding more standards is = always an interesting exercise [1] but it would be nice if everyone = implemented the existing stuff first. :) [1] https://xkcd.com/927/ ________________________ Michael Sweet --Apple-Mail=_35DE17AA-5AA9-43B9-BE41-41505A6B43A3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkIbDzcZsP1Y8+PQFvmfHXsgfMkQFAmJXK+wACgkQvmfHXsgf MkTb0Q//Z7J3qsbClVjxGUP+cVbPua0WHM0lnehBjjQacAVF+cafkx4YbY9FeBF/ UQJfGSm04xIA/5n1E0sevvZfmBdxNAhfoiNzuJrNvXcSabCdYCLgh0oCRJl3XK60 mBhc379eugCI1wb+3sOe+yViaFhVOJEhVuyygC4MrstRRzNR78oSLjg2FM0lk/k8 5bKlUYlZJ5rgSl1lVld8uJrC2GCNo0Cro8+1J/DL5T4SmQlA4n2CJ+vUhEZeePOA WwA9fZ6xk5b47pz71TLTcwJtvYbSBRYfHAkNoONQjO78z/bEhHnkLyE2tMQZpLlB /zz72i/xfh1WGod3jTmzVC5xEi92fxp9kbSfmjZ5CeSdX5QtMcoFqEg1t1KdDnME OnX4/KZobpnawNmcsB/yTqVwvjKms1H7y1r2v9F6OArq3ipxTaa+utOV8csaFNkg dphffhx2nIwcCqlzOD3I6ouHLnIvAs5322iyKjvz3P0g/1e1CP1Vgkv07VUISJ25 A5ooZR4xqmKjGFsbzeyDAMCCNhvX0Lwg8zuLc2cha7SUn78zhUJ0ci864iLF6ygg uWQLSpxrNCaKFff80PC4iFX+rCtkmWvi2J4sSeSpJkGfX6pgTBgjrIugMbO76ywR RfpoI7urvrd6QYmR0jWqseyydWm8q6KkuoKu8wrV0znk3Qogk3I= =nhfc -----END PGP SIGNATURE----- --Apple-Mail=_35DE17AA-5AA9-43B9-BE41-41505A6B43A3-- From nobody Thu Apr 14 08:35:09 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7853A0847 for ; Thu, 14 Apr 2022 08:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=msweet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVOb0uGnot3z for ; Thu, 14 Apr 2022 08:35:00 -0700 (PDT) Received: from mail.msweet.org (mail.msweet.org [173.255.209.91]) by ietfa.amsl.com (Postfix) with ESMTP id 97DD23A0858 for ; Thu, 14 Apr 2022 08:35:00 -0700 (PDT) Received: from smtpclient.apple (cbl-66-186-76-47.vianet.ca [66.186.76.47]) by mail.msweet.org (Postfix) with ESMTPSA id 749FC820D6; Thu, 14 Apr 2022 15:34:57 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.msweet.org 749FC820D6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=msweet.org; s=default; t=1649950497; bh=8yup/38Au5efi36qE2iZ2bYl4U62vUsk9jZXE52PrOs=; h=From:Date:Subject:References:To:From; b=a0hzFtPfkUnSwlc2XU0eHWe92LOZs4KZgDMECTd1BruztjbCg1OonhUhxNQ9HDy2S TTMJzrQjUKeD7DPQ3JH4coGv/jwXwkk+lPT5Ybs+dAY8PoOOaiRzt8/E0/+i20n3PU cpTtd09kfiEaB6vJcu+Zid0aK4wLqNVBrSW9CZ1w= From: Michael Sweet Content-Type: multipart/signed; boundary="Apple-Mail=_2FF8C988-D52F-4865-88FD-3D932E6CDF52"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Date: Thu, 14 Apr 2022 11:34:55 -0400 References: <164995026847.2586.16228265434075815549@ietfa.amsl.com> To: iotops@ietf.org Message-Id: X-Mailer: Apple Mail (2.3696.80.82.1.1) Archived-At: Subject: [Iotops] Fwd: New Version Notification for draft-sweet-iot-acme-01.txt X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2022 15:35:06 -0000 --Apple-Mail=_2FF8C988-D52F-4865-88FD-3D932E6CDF52 Content-Type: multipart/alternative; boundary="Apple-Mail=_2A0DD77F-2B51-4AA0-8D51-56C957AC15C4" --Apple-Mail=_2A0DD77F-2B51-4AA0-8D51-56C957AC15C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Updated to use DHCP Option 30 (Vendor-Identifying Vendor Class Option) = for prototyping. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-sweet-iot-acme-01.txt > Date: April 14, 2022 at 11:31:08 AM EDT > To: "Michael Sweet" >=20 >=20 > A new version of I-D, draft-sweet-iot-acme-01.txt > has been successfully submitted by Michael Sweet and posted to the > IETF repository. >=20 > Name: draft-sweet-iot-acme > Revision: 01 > Title: ACME-Based Provisioning of IoT Devices > Document date: 2022-04-14 > Group: Individual Submission > Pages: 10 > URL: = https://www.ietf.org/archive/id/draft-sweet-iot-acme-01.txt > Status: https://datatracker.ietf.org/doc/draft-sweet-iot-acme/ > Html: = https://www.ietf.org/archive/id/draft-sweet-iot-acme-01.html > Htmlized: = https://datatracker.ietf.org/doc/html/draft-sweet-iot-acme > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-sweet-iot-acme-01 >=20 > Abstract: > This document extends the Automatic Certificate Management > Environment (ACME) [RFC8555] to provision X.509 certificates for > local Internet of Things (IoT) devices that are accepted by existing > web browsers and other software running on End User client devices. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 ________________________ Michael Sweet --Apple-Mail=_2A0DD77F-2B51-4AA0-8D51-56C957AC15C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Updated to use DHCP Option 30 (Vendor-Identifying Vendor = Class Option) for prototyping.

Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-sweet-iot-acme-01.txt
Date: = April 14, 2022 at 11:31:08 AM = EDT
To: = "Michael Sweet" <msweet@msweet.org>

A new version of I-D, draft-sweet-iot-acme-01.txt
has been successfully submitted by Michael Sweet and posted = to the
IETF repository.

Name: = = draft-sweet-iot-acme
Revision: 01
Title:= = ACME-Based Provisioning of IoT Devices
Document = date: = 2022-04-14
Group: Individual Submission
Pages:= = 10
URL: =            https://www.ietf.org/archive/id/draft-sweet-iot-acme-01.txt=
Status: =         https://datatracker.ietf.org/doc/draft-sweet-iot-acme/
Html: =           https://www.ietf.org/archive/id/draft-sweet-iot-acme-01.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-sweet-iot-acme<= br class=3D"">Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-sweet-iot-acme-01=

Abstract:
  This = document extends the Automatic Certificate Management
=   Environment (ACME) [RFC8555] to provision X.509 certificates = for
  local Internet of Things (IoT) devices = that are accepted by existing
  web browsers = and other software running on End User client devices.




The IETF = Secretariat



________________________
Michael Sweet



= --Apple-Mail=_2A0DD77F-2B51-4AA0-8D51-56C957AC15C4-- --Apple-Mail=_2FF8C988-D52F-4865-88FD-3D932E6CDF52 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkIbDzcZsP1Y8+PQFvmfHXsgfMkQFAmJYPyAACgkQvmfHXsgf MkT6+hAAq3zvdm7IBdTKxFQuyc/UaJat67brmNVP5ClocpY5J/UznA6tvj2CJvH2 V5cbhcKvIUF7vNHncP5flWibITvmJEqY13RhA4VAWC3HUro67KlzJLfeCvaawmsc cDq4o7A71fdmyLPmppH2oV25Jra5p4CNndOAl2b/O0uEQaLn79dSgm2UfGd4uQAy 1F0bfG7RxoUc+6pB1n/8mquYRMhvIn2WEPr6nuEAD9pgorsiAvSnzYplAw7b9Y3D 8baauiGqyIaTQHmjSPm9l07UHwQzAB2bMhZDP+RvY1HY15Ek6zuopxLNeW4pSmhF pkNL+Qc8lT6exQeuFAFqZkger7sCsRw9bgSR85vNGuwI5kXZB9Hs4WNhVWiPSj6f ANI/W0knICAaqgYSrd+Uqc8rk22HHfmixizLosnE3f4Rd/TFHEUo5wqL4TSte8ue 294Ko9OIewtzO9JcyP3BSvP3gkw5gjt85tqbSiwj2jRyRYww6eNPyoeWC4KamY/p zhffBpD/fPTE2T7yC5ke7XpBg9Gkw9T4E9ze/0XBnH0wWdle3eWj1c1Y3Ry5yOHR fiJOqBTakHGrGXJHa1vWEEBrT7zUrhVy+UyYxPME19s0u7lrFL4qmVBhr1ZMBC3z LFRU43kIfJndrRg0fwkbTWqtauDbPvc5wIRwkVgrC0hebOSNDgc= =zWMp -----END PGP SIGNATURE----- --Apple-Mail=_2FF8C988-D52F-4865-88FD-3D932E6CDF52-- From nobody Fri Apr 15 08:14:19 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CABF3A095C for ; Fri, 15 Apr 2022 08:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSymeVIpSBEL for ; Fri, 15 Apr 2022 08:14:13 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A863A0981 for ; Fri, 15 Apr 2022 08:14:12 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id t25so14452147lfg.7 for ; Fri, 15 Apr 2022 08:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=l9V+FljdiwXKcQqHtsx0FFFZV+zcYDwxLoDZYrybizE=; b=HaTwOqmH+QYPJIDl52Z6GWfvoUGOlZmZhsXpKQeM2NN/SRIWWgD6D+3CRUuL3HuEE9 hsUZ2NOf0lxaz42khyEmWajM4EO7o9Q4mVNpaHgQM3TE19MnNacCEOJyr+cZFpfqsOzK 1YK8U2KW+DmVNd2s/cZC9UQ6bWEp1hwBFocKw1ixoMqEz9FRdcU6CfTne7FYpQTVpey+ NnWu7BmTtD+xJ7Fn5Rs7JtFE/81fbL20fXlj8yeiD/jEhiXglX4/7RBik6qg5ZxnUZVs fUnU2C+NNSU/f3F6I81cmGS6zWWbZyimSuhMax1FHeWvzOu+RyjvoaQOl6LQYc/yghL+ JNIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=l9V+FljdiwXKcQqHtsx0FFFZV+zcYDwxLoDZYrybizE=; b=5ZIKNd6m7O3Wb2PAj/fcAFLX3C15S2kduU4M+CNMFcr8ojAXX2/Ngb83Pt+vhuj7ot H0uIvWDHhsSaN7ONNLRGyubPSWdVjP8v7FqVB5AeQQtxrcgq9UfqfC2euLudmaflwEH7 A4FJ87l/AkioyBAApx9P5sl5bnLhefqyMGyGXdgrquH3DmOgF8OR+Rs6BsHU+X3c0pV2 qZB1wCYdJN1NsmVGJJNNgFxiLYVxsMoBvaw6BdHep5aeCv7YPbxQkb/xLvYjmei0jJAf YlLwbfgyJqGDLDep3CrfvEn6Y1OiKXpqW2CokPxgc7/+2siHCDgYgm2wRWlc7QDkXc36 Ijng== X-Gm-Message-State: AOAM531rxXWf1lj58w+RksuSMiLg+aX/jxpkeyWRvNERU9puuabj3gYu ScVeT8ERrOZQa+WSoWyfqEsOwlgMVXfTUxZfClGWThl7myc= X-Google-Smtp-Source: ABdhPJwgbv+LBjwv7ZcZzj8CISZG7/1cy4qUGQanHOUTdsaE0UvRNZC7dgehhqkIvyKjkZAtY0w/Uk0jaWtCcpPp1c8= X-Received: by 2002:ac2:520a:0:b0:46b:b8fa:2ad1 with SMTP id a10-20020ac2520a000000b0046bb8fa2ad1mr5429208lfl.443.1650035650539; Fri, 15 Apr 2022 08:14:10 -0700 (PDT) MIME-Version: 1.0 References: <164995026847.2586.16228265434075815549@ietfa.amsl.com> In-Reply-To: Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Fri, 15 Apr 2022 10:13:59 -0500 Message-ID: To: Michael Sweet Cc: iotops@ietf.org Content-Type: multipart/alternative; boundary="000000000000d1325f05dcb2dcfe" Archived-At: Subject: Re: [Iotops] Fwd: New Version Notification for draft-sweet-iot-acme-01.txt X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2022 15:14:19 -0000 --000000000000d1325f05dcb2dcfe Content-Type: text/plain; charset="UTF-8" Hi Michael, I don't understand why wireless cable modem is an IoT device but lights, appliances at home are not IoT devices and ACME doesn't seem to apply to them? Behcet On Thu, Apr 14, 2022 at 10:35 AM Michael Sweet wrote: > Updated to use DHCP Option 30 (Vendor-Identifying Vendor Class Option) for > prototyping. > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for draft-sweet-iot-acme-01.txt* > *Date: *April 14, 2022 at 11:31:08 AM EDT > *To: *"Michael Sweet" > > > A new version of I-D, draft-sweet-iot-acme-01.txt > has been successfully submitted by Michael Sweet and posted to the > IETF repository. > > Name: draft-sweet-iot-acme > Revision: 01 > Title: ACME-Based Provisioning of IoT Devices > Document date: 2022-04-14 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/archive/id/draft-sweet-iot-acme-01.txt > Status: https://datatracker.ietf.org/doc/draft-sweet-iot-acme/ > Html: > https://www.ietf.org/archive/id/draft-sweet-iot-acme-01.html > Htmlized: https://datatracker.ietf.org/doc/html/draft-sweet-iot-acme > Diff: https://www.ietf.org/rfcdiff?url2=draft-sweet-iot-acme-01 > > Abstract: > This document extends the Automatic Certificate Management > Environment (ACME) [RFC8555] to provision X.509 certificates for > local Internet of Things (IoT) devices that are accepted by existing > web browsers and other software running on End User client devices. > > > > > The IETF Secretariat > > > > ________________________ > Michael Sweet > > > > -- > Iotops mailing list > Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops > --000000000000d1325f05dcb2dcfe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michael,

I don't understand why = wireless cable modem is an IoT device but lights, appliances at home are no= t IoT devices and ACME doesn't seem to apply to them?

Behcet

On Thu, Apr 14, 2022 at 10:35 AM Michael Sweet <mswe= et=3D40msweet.org@dmarc.ietf= .org> wrote:
Updated to use DHCP Option 30 (Vendor-I= dentifying Vendor Class Option) for prototyping.

Begin forwarded message:

Subject: N= ew Version Notification for draft-sweet-iot-acme-01.txt
Date: <= /b>April 14, 2022 at 11:31:08 AM EDT
=
To= : "Michael Sweet" <msweet@msweet.org>


A new version of I-D, draft-sweet-iot-acme-01.= txt
has been successfully submitted by Michael Sweet and posted to theIETF repository.

Name: draft-sweet-iot-acme
Revis= ion: 01
Title: ACME-Based Provisioning of IoT Devices
Document date: 2022-04-14
Group: Individual Su= bmission
Pages: 10
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/arc= hive/id/draft-sweet-iot-acme-01.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-sw= eet-iot-acme/
Html: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0https://www.ietf.org/archive/id/draft-sweet-iot= -acme-01.html
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/html/draft-sweet-iot-acme
Di= ff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-sweet-iot-acme-01

= Abstract:
=C2=A0=C2=A0This document extends the Automatic Certificate M= anagement
=C2=A0=C2=A0Environment (ACME) [RFC8555] to provision X.509 c= ertificates for
=C2=A0=C2=A0local Internet of Things (IoT) devices that= are accepted by existing
=C2=A0=C2=A0web browsers and other software r= unning on End User client devices.




The IETF Secretariat<= br>


________________________
Michael Sweet



--
Iotops mailing list
Iotops@ietf.org https://www.ietf.org/mailman/listinfo/iotops
--000000000000d1325f05dcb2dcfe-- From nobody Fri Apr 15 09:51:01 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF1A3A0859 for ; Fri, 15 Apr 2022 09:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=msweet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzSx_E3f1Ah0 for ; Fri, 15 Apr 2022 09:50:54 -0700 (PDT) Received: from mail.msweet.org (mail.msweet.org [173.255.209.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2073A0831 for ; Fri, 15 Apr 2022 09:50:54 -0700 (PDT) Received: from smtpclient.apple (cbl-66-186-76-47.vianet.ca [66.186.76.47]) by mail.msweet.org (Postfix) with ESMTPSA id C141981FE3; Fri, 15 Apr 2022 16:50:53 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.msweet.org C141981FE3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=msweet.org; s=default; t=1650041454; bh=YGLxarBQklPIo1lLrCa87dbz0XeBMGdrZworOBM0crA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=aEyxU8VyCDyDCFh+fqbC9agbAnN9YjAQr8AdAzliq9Pmejxs4B32AJUhBkIwQ82rY GaLmaAE6OKJQhTo63avgfW803akQeRwQgfVgqN7KVlp+c5R117qMZZqfRaLI7ted2G YRH9zJ4hVY4KvBeZbDvFOphRjR7WnFbyyUuJo3a8= Content-Type: multipart/signed; boundary="Apple-Mail=_68758F59-F4EE-46C6-A288-C0B0ABC7A221"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) From: Michael Sweet In-Reply-To: Date: Fri, 15 Apr 2022 12:50:52 -0400 Cc: iotops@ietf.org Message-Id: <1869DE73-A799-437D-BB0E-750383CB411A@msweet.org> References: <164995026847.2586.16228265434075815549@ietfa.amsl.com> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.3696.80.82.1.1) Archived-At: Subject: Re: [Iotops] New Version Notification for draft-sweet-iot-acme-01.txt X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2022 16:51:00 -0000 --Apple-Mail=_68758F59-F4EE-46C6-A288-C0B0ABC7A221 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Behcet, > On Apr 15, 2022, at 11:13 AM, Behcet Sarikaya = wrote: >=20 > Hi Michael, >=20 > I don't understand why wireless cable modem is an IoT device but = lights, appliances at home are not IoT devices and ACME doesn't seem to = apply to them? Sorry, did I say that? I do know that the CoRE WG is working on supporting constrained = environments (lights, switches, etc.) which might not have the resources = for ACME, but nothing in my draft would exclude them. Most appliances I = have experience with manage their own Internet connection (typically = setup via a mobile app) that can do ACME. Switches and lights typically = use the Zigbee protocol and depend on a bridge device to provide = Internet access, and the bridge device can do ACME. The focus of my draft is just to define the requirements for a local = ACME server, how to discover it, and how to use it to provide a higher = level of trust for IoT devices. ________________________ Michael Sweet --Apple-Mail=_68758F59-F4EE-46C6-A288-C0B0ABC7A221 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkIbDzcZsP1Y8+PQFvmfHXsgfMkQFAmJZomwACgkQvmfHXsgf MkRetg//bEK3J4eKJiAEAfFRZ+8cqyK6T3V7wbxTxL1r49B9l3Mo7lkVK6mdpwB2 FLdsmAMQEnikL1FbTV8uYJ3MQhF3CdnuVPS/glmJGW3TmwUfoGUkVnx0R93iI4Uh RDkkSzJSpGWli8aKkGjXLK4JzUG3KoPWYfRp5yhsQ9aws3IE9oVc3oyTNkngS7G0 wW5Mpj0yJj+VDnYqGx645H0vV2v2UJP1Io1hh61e5lVTPLPtzhUWwjO1PUL44eJs 3CHjdMlJwyR3TJ0tLEdW201k0aAzXAWBHEoVco6njF5ftln+okwHguU/tetA+ZVt bEZVHUu5h8ZtC0sdZYLUYH8oeofgz1RxMTeiztCuR+p4eMuTht9DQVl7DRIwSrzO MrsTVWipPBVh61Ub8etYiesU6IrQOH7edhD4HrI5lA/sFPtZR/ylzYpqgsd68Zk9 uM7WUeJBEkJ54Y3OwggK2DcerkdB+IAYEHjwD4tIbKBKBoa3FEyXBUWc+HMuLby8 LbKQ7Z6v9HZCXrf3ji4tblDAPYLBZ4chOgNIDHXyVx2ZPEPVddrTCyxCFbooKebV s8epEGzutYcQaBTKvgo79SjTQADUsWAoD/U97NU+4KU+TdKJ45w7AZ7Q5q24rb8p JCdYPa/Dm6A0UoUbUzFijEqr68yTXE7V70j6+1C1rqKtHD0D+0k= =y0Bt -----END PGP SIGNATURE----- --Apple-Mail=_68758F59-F4EE-46C6-A288-C0B0ABC7A221-- From nobody Mon Apr 18 07:48:18 2022 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9073A1138 for ; Mon, 18 Apr 2022 07:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiw6ndXleNkN for ; Mon, 18 Apr 2022 07:48:10 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B96C3A113D for ; Mon, 18 Apr 2022 07:48:10 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id n17so12130793ljc.11 for ; Mon, 18 Apr 2022 07:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=FM0omPmViVt4zLjzhEFEU3popBULA46UBkyWs6FQamM=; b=GeeTFhhfTCgxBxpJXYRqhxkIqErstSIDh5Z5xRHDBLrsHOX8raeIAvzR6E8XY+01DA 0cbf3K6WYpwhGhaAoNLSugCDq7irN5SFupmARcWsvwmIqHdk74HVlg3yGuxcO1JmMfRs iAlNS0wJTzq7g6Xkw6WNW4eXmEd+zm2w/f+rzMkDRTenkMwnJQ5Z7g8NNKLemeRuBmQC im4kprFrQKilJkK7sg/4gz41JokuyC+DGqs79j0sZe/TJQZCAVasxX9kZpZqv1SxWO/r D11y+rqhSKDEpWp6jtFiXJenj3FbQiJDQ73cRaoOkhXU3n9FokUAo7QHB6ME9NCvA+0K pgzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=FM0omPmViVt4zLjzhEFEU3popBULA46UBkyWs6FQamM=; b=sgMlQzUEBV6nGBe0aXn7dC3IVVzz5F5HxCTT4yaO6MTIuX2E9a/UuR+aJEb8FK4cIB N07h5tNqHNtrUBrxzB6dd8P+fdgukjURyR1lyhUD1E8L+V9Ncad1Ntqey9weQ6Tc41xq va8SY3ow8ESkuVE98da4ZCJH6E2EU2N9IgAnSDUa+uO+RayHGm8pV6iQC4YyUMObKJtJ cyANt8dOwz0odY8PkOj8zDSOQMwOBz6ZeTlrbaiICj6ilS9pLYPl1Vb0wkwV+432hzT/ DBSvSFZDgP7rFPLiYRBqBEXmXblyb20LQfp21MTdJlseXL+oCgZIOh/CCd80aGAbfhrg VnmQ== X-Gm-Message-State: AOAM53353NkLfY8yMDSJq0sY6ijYOBBlm2rF5x6FhNow3wEH5TV0pCzs hNY9Tl7uM2Y+BMA+fwC/Rru6u7YxPSaqUEwEaWU= X-Google-Smtp-Source: ABdhPJyJbwkmFjYEhnD2lEJ8yv/qw1D+S6a0Hz6+tto1s64tNErPU454DarzQS/B/MHzuUPdO3o6cjgiryQQiN+8sQw= X-Received: by 2002:a2e:9e11:0:b0:24c:5677:8b20 with SMTP id e17-20020a2e9e11000000b0024c56778b20mr7596076ljk.430.1650293287345; Mon, 18 Apr 2022 07:48:07 -0700 (PDT) MIME-Version: 1.0 References: <164995026847.2586.16228265434075815549@ietfa.amsl.com> <1869DE73-A799-437D-BB0E-750383CB411A@msweet.org> In-Reply-To: <1869DE73-A799-437D-BB0E-750383CB411A@msweet.org> Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Mon, 18 Apr 2022 09:47:56 -0500 Message-ID: To: Michael Sweet Cc: Behcet Sarikaya , iotops@ietf.org Content-Type: multipart/alternative; boundary="0000000000002ae21205dceed99a" Archived-At: Subject: Re: [Iotops] New Version Notification for draft-sweet-iot-acme-01.txt X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2022 14:48:16 -0000 --0000000000002ae21205dceed99a Content-Type: text/plain; charset="UTF-8" On Fri, Apr 15, 2022 at 11:50 AM Michael Sweet wrote: > Behcet, > > > On Apr 15, 2022, at 11:13 AM, Behcet Sarikaya > wrote: > > > > Hi Michael, > > > > I don't understand why wireless cable modem is an IoT device but lights, > appliances at home are not IoT devices and ACME doesn't seem to apply to > them? > > Sorry, did I say that? > > I do know that the CoRE WG is working on supporting constrained > environments (lights, switches, etc.) which might not have the resources > for ACME, but nothing in my draft would exclude them. Most appliances I > have experience with manage their own Internet connection (typically setup > via a mobile app) that can do ACME. Switches and lights typically use the > Zigbee protocol and depend on a bridge device to provide Internet access, > and the bridge device can do ACME. > > The focus of my draft is just to define the requirements for a local ACME > server, how to discover it, and how to use it to provide a higher level of > trust for IoT devices. > > Yes, this is what I understood. But I think the example or use case you chose defeats it. Why would I need a certificate of the wireless cable model. just get the IP address and use it. So my suggestion is to revise the draft to better keep the focus like you said above and explain it with a better example. Behcet > ________________________ > Michael Sweet > > > > --0000000000002ae21205dceed99a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Apr 15, 2022 at 11:50 AM Mich= ael Sweet <msweet@msweet.org>= ; wrote:
Behcet,

> On Apr 15, 2022, at 11:13 AM, Behcet Sarikaya <sarikaya2012@gmail.com> wrot= e:
>
> Hi Michael,
>
> I don't understand why wireless cable modem is an IoT device but l= ights, appliances at home are not IoT devices and ACME doesn't seem to = apply to them?

Sorry, did I say that?

I do know that the CoRE WG is working on supporting constrained environment= s (lights, switches, etc.) which might not have the resources for ACME, but= nothing in my draft would exclude them.=C2=A0 Most appliances I have exper= ience with manage their own Internet connection (typically setup via a mobi= le app) that can do ACME.=C2=A0 Switches and lights typically use the Zigbe= e protocol and depend on a bridge device to provide Internet access, and th= e bridge device can do ACME.

The focus of my draft is just to define the requirements for a local ACME s= erver, how to discover it, and how to use it to provide a higher level of t= rust for IoT devices.


Yes, this is what I understood. But I = think the example or use case you chose defeats it.
Why would I n= eed a certificate of the wireless cable model.=C2=A0just get the IP address= and use it.
So my suggestion is to revise the draft to better ke= ep the focus like you said above and explain it with a better example.

Behcet=C2=A0
________________________
Michael Sweet



--0000000000002ae21205dceed99a--