From nobody Wed Feb 9 11:16:02 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 825863A0813; Wed, 9 Feb 2022 11:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_PDS_SHORTFWD_URISHRT_QP=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 uXq_fk0Jq2mO; Wed, 9 Feb 2022 11:15:55 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0518F3A07F7; Wed, 9 Feb 2022 11:15:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 46AE2389C1; Wed, 9 Feb 2022 14:23:32 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uzNqT9aj8wg5; Wed, 9 Feb 2022 14:23:28 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9715C389C0; Wed, 9 Feb 2022 14:23:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1644434608; bh=y6085vAWfdRZPRy9ywYw57m8yuMpatT3QTEaLAGvP7w=; h=From:To:CC:Subject:In-Reply-To:References:Date:From; b=vuNMYprBmKmEeOEcFL2Xv3viAZvRlI8XIJ93fBgOmk+nPYadZbnzPaOMBlhXjKKiV 587LzL69VvQEWuHF/i91V4p7N/pMxNa96xDhUUopu/05tK2CQ7PXJlbqPb1sLY0QZz Ga17NnGxu2e2ws0XccEoFabkS1dOMz3ZHbMim4ruwzZapkjwwO0gfA9lMMcQjT8b97 tKN25L0WKZyPq17wjpF0KlOhX3OTFq0k1qUdtGsk6uuxpGPLtQKRTgqtlJW5P6FYGl Mf2iW+3c6tKtGcmUMb13SyYo8jJthwdnJWWtnMx0oAMFcWr25xb7y+O0dVc5CmFrYz kTMMDLYT8E4bg== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8D52740; Wed, 9 Feb 2022 14:15:46 -0500 (EST) From: Michael Richardson To: Jim Zubov , secdispatch@ietf.org, iotops@ietf.org, anima@ietf.org CC: Manysecured In-Reply-To: <0075B437-024A-4D84-ABD7-92FE8DAFA59F@commercebyte.com> References: <0075B437-024A-4D84-ABD7-92FE8DAFA59F@commercebyte.com> 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] [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) 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, 09 Feb 2022 19:16:01 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable TL;DR: Dispatch to IOTOPS. Hi, I've reviewed your document at: Jim Zubov wrote: > Please consider the following draft: > https://datatracker.ietf.org/doc/draft-zubov-snif/ I have three sections of comments: general ones, dispatch ones, and then so= me detailed comments on the document/protocol itself. My general comments are intended to introduce the concept for who have not (yet?!) read the documen= t. GENERAL =2D------ This seems to be solving a very similiar problem to the Manysecured SUIB problem. You can read more about SUIB at a document that is still evolving= at: https://specs.manysecured.org/suib/SUIB-requirements This was also on the IETF112 IOTOPS WG agenda: slides: https://datatracker.ietf.org/meeting/112/materials/slides-112-= iotops-suib-browsing-local-web-resources-in-a-secure-usable-manner-iot-devi= ce-configuration-as-a-special-case-00 video: https://youtu.be/OIlJrUvwDcI?t=3D1649 and we hope to return at IETF113. The SUIB problem addresses the challenge of connecting *locally* to a devic= e, and doing it securely. For this to be possible with RFC6125-DNS-ID standard browser, we need a name for the device, and we need a way to translate that name into a locally reachable IP address. The SNIF proposal does not quite solve the above problem. It does provide a useable name for the device, and it does provide for *an* address which can be used to reach the device. But, it essentially has created a kind of secure TURN service which gives a global (HTTPS) name for= a device, allowing it to be reached globally. There are some aspects of the SNIF which seem to deal with ABUSE. While the SNIF CA and Connection proxies could be run by a number of partie= s, given that the devices need to have a pre-existing relationship with those parties (and that provisioning of credential stage is out of scope according to the document), it seems that it will only really be operated by the manufacturer, or some large delegate like an ISP that sells IoT devices. What would the economic argument/incentive for other parties to operate the= se services? Still, if SNIF is replacing a manufacturer proprietary call-home protocol, there could be advantages from having well reviewed code bases, and potentially an ecosystem of SNIF Providers that manufacturers could outsour= ce to. Azure/Amazon/... could easily run such services. SNIF seems very much IPv4 NAT44 focused, and it could benefit from some understanding of IPv6 and IPv6-over-IPv4 technologies, particularly Teredo. DISPATCH COMMENTS =2D---------------- There are a lot of issues that I have with the proposal that would need significant work to document and/or sort out. As such I would definitely advise against AD sponsor. This protocol is not really big enough to warrant it's own WG, although oth= er similiar sized protocols (such as ACME) have their own WG. If ten people from four different vendors showed up and wanted to work on this, then a new WG might be reasonable. Much of SNIF is about new variations of certificate enrollment. Some of it is very similiar to draft-ietf-anima-brski-cloud. If BEHAVE was still alive, dispatching there could make sense because it's a also a new kind of TURN, and maybe it should just be a new variation. Dispatch to ACME almost makes sense. (To quote the _Broken Sword_ game: "That was almost a good idea") It could be dispatched to ANIMA. I don't think that it would make it throu= gh ANIMA with the same look, but at least we have lots of RFC7030 expertise. IOTOPS was chartered to do some IoT dispatch work, and it could be that this document should go there. It is not clear to me yet if SECDISPATCH has the patience to understand the document well enough to make a decision. DETAILED COMMENTS =2D---------------- Section 2 will need a diagram for the Proxy, Relay, Connector, Client, CA. I think that before introducing the components, a simpler walk through is needed. 3.1: Connector speaks HTTP or HTTPS. It clearly has to speak HTTPS only. How does device learn their initUrl? If it is programmed into the device by the manufacturer, then basically it's the manufacturer's service. If it is provided by the end user, through an admin interface, then how is that interface secured? DHCP option? We have a multitude of onboarding protocols now, I suggest that extensions to a few of them be provided for here. For instance, in an RFC8995 BRSKI situation, the initURL, along with an optional trust anchor to validate it (if DNS-ID verification is a problem), could be provided in the voucher. Of course, if one was doi= ng BRSKI, then it might be better to just do BRSKI-CLOUD here. This flow: https://www.ietf.org/archive/id/draft-ietf-anima-brski-cloud-02.html#n= ame-voucher-request-handled-by- is essentially exactly what is needed here. 3.2: "Any key algorithm acceptable by the CA can be used, generally RSA-409= 6 is recommended." I would not recommend RSA-4096. Effective security of RSA keys does n= ot go up linearly with size. 4096 bits just uses a lot of space for very little benefit. ECDSA, EDDSA would be better recommendations. The Connector flow where it allocates a CN is essentially the CSRattrs problem that LAMPS is clarifying in RFC7030 with the https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030-csratt= rs/ which has been neglected since IETF112, but I hope will be adopted at = IETF113. 3.3: generally, GET is a bad idea for something that allocates something. Either use X-SNIF-CN:, or the payload, not both. DRY. text/plain is probably the wrong choice for a mime type here. 3.4: PUT is an interesting choice. It's not wrong though. Having a 201 reply where one can collect a status report is nice. I wish that RFC7030 did that. 3.5: as I understand it, the certificate is actually retrived from the DN/dnsName that was allocated using http. That seems to imply that http can never be used with the device? (I don't think it should, but...) At least this should be in /.well-known. section 4 deals with the relay protocol. I didn't look at that deeply at this. It seems pretty complex, and as long as this is greenfield, why not use HTTP/2 and/or QUIC so that multiple requests can be sent over a single pinhole? This entire part is very very much IPv4 focused. IPv6 devices shouldn't need any of this. But, perhaps more to the point, UPnP pretty much already does this. So does Teredo. section 4.6 on ABUSE Management is an interesting addition. This part should be coordinated against what DOTS WG has already built. I found your security considerations section to be well written. I'm not sure I understand the IANA registration of "snif", etc. They *aren't* what IANA would call "IP protocols", which would be things li= ke TCP, UDP, SCTP, ESP, ... Has IANA *already* registered port 7123 then? =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----- iPMEAQEKAB0WIQSk7ZHEG9TCGBNASfm/sjw/rPYc8wUCYgQS4gAKCRC/sjw/rPYc 8zs7BgCQFC6w0tLWSydEUhCLgKYH17JmvlGLsOTjGCMXSYFstBk4PFceAiIU27WJ cEcU4IWXKf21XvCjK4FF2AHEu8z7+0kIej5BHApiui04+ASEkjCQhs6bdRC5tje3 L3afvnganp2bjhSNhczABsIPVSPYeyyKzeG+EsIX5FOpsO9QS0pnK0/DG85y92Ar TCGYYKCGVbJhhuPO/YgcRWlPPHINiBRraxulMJUhHH6vS43zSOOy58dUdA5Jcxkd CMZ2c7A= =Pc7V -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 9 15:42:06 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 C59B73A0EB7; Wed, 9 Feb 2022 15:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.901 X-Spam-Level: X-Spam-Status: No, score=0.901 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, PDS_OTHER_BAD_TLD=1.999, PP_MIME_FAKE_ASCII_TEXT=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=commercebyte.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 BCqWWVCmLWML; Wed, 9 Feb 2022 15:42:00 -0800 (PST) Received: from ocean1.commercebyte.com (ocean1.commercebyte.com [104.131.120.15]) (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 CCEEF3A0E9A; Wed, 9 Feb 2022 15:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=commercebyte.com; s=default; h=Date:Message-Id:Subject:MIME-Version:References:In-Reply-To:To:From; bh=ICyfXHJuzh6/Y0ld3dSId09z4uPSRdHFbfGdyyjQR6U=; b=Xp5bY8dr6S+K9JyK+LZKVMmb/4pFOf5gRMnXIPVWOj5N9EWf1RUrm85OsAW2DU1gMcckNMtUJWyn8QUoFyehgNA4CwddwUIqF5dLt2R5UY1uEqkH7zeSbHk/ovMMW8A8dHgzh2JDnZ0bG+uyEcjxDHkdJtl2IzjBeoQzT1H/0jQ=; Received: from root by ocean1.commercebyte.com with local (Exim 4.82) (envelope-from ) id 1nHwaz-0000LM-I5; Wed, 09 Feb 2022 18:41:57 -0500 From: Jim Zubov To: Michael Richardson , secdispatch@ietf.org, iotops@ietf.org, anima@ietf.org In-Reply-To: <1865.1644434146@localhost> References: <0075B437-024A-4D84-ABD7-92FE8DAFA59F@commercebyte.com>, <1865.1644434146@localhost> MIME-Version: 1.0 Message-Id: Date: Wed, 09 Feb 2022 18:41:57 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ocean1.commercebyte.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - commercebyte.com X-Get-Message-Sender-Via: ocean1.commercebyte.com: sender_ident via received_protocol == local: root/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Iotops] [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) 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, 09 Feb 2022 23:42:05 -0000 Thank You for the feedback Michael, my comments are below. (replying to all lists the response has been copied to, if it's a flooding issue - everyone pls lmk) > > TL;DR: Dispatch to IOTOPS. > > Hi, I've reviewed your document at: > > Jim Zubov wrote: > > Please consider the following draft: > > https://datatracker.ietf.org/doc/draft-zubov-snif/ > > I have three sections of comments: general ones, dispatch ones, and then > some > detailed comments on the document/protocol itself. My general comments > are > intended to introduce the concept for who have not (yet?!) read the > document. > > GENERAL > ------- > This seems to be solving a very similiar problem to the Manysecured SUIB > problem. You can read more about SUIB at a document that is still > evolving at: > https://specs.manysecured.org/suib/SUIB-requirements > > This was also on the IETF112 IOTOPS WG agenda: > slides: > https://datatracker.ietf.org/meeting/112/materials/slides-112-iotops-suib-browsing-local-web-resources-in-a-secure-usable-manner-iot-device-configuration-as-a-special-case-00 > video: https://youtu.be/OIlJrUvwDcI?t=1649 > > and we hope to return at IETF113. Right, looks like SUIB is working on a similar problem. Thanks for pointing this out. In particular, the "Sol #6 Device name DNS" slide looks quite similar to SNIF CA Proxy (Section 3). However, SUIB pursues bigger infrastructural goals such as changing the localhost TLS connection policies (I totally agree and really appreciate the effort), while SNIF is a functioning solution within the existing infrastructure, tested and proven to work in pre-production. > > The SUIB problem addresses the challenge of connecting *locally* to a > device, > and doing it securely. For this to be possible with RFC6125-DNS-ID > standard > browser, we need a name for the device, and we need a way to translate > that > name into a locally reachable IP address. > > The SNIF proposal does not quite solve the above problem. In fact, I originally designed SNIF to solve this specific problem - local-to-local trusted TLS connections. The draft describes SNIF connection through a dedicated end-to-end relay (external IP), which may be used for local-to-local too. But I was also looking for possibilities of a true local connection - and I have 2 options - * Issue a wildcard cert through SNIF CA Proxy (e.g. CN=*.domain.snif.xyz), set a DNS record for localhost.domain.snif.xyz to point to localhost's IPv4/v6, and use https://localhost.domain.snif.xyz (or other app protocol - imaps etc). However, looks like some clients treat the localhost IP as inherently unsecure, and issue a warning ever is the cert is perfectly valid. The option is still possible, but the applicability might be limited. * Another option is to override the IP routing rules. It is totally possible on iOS and Mac through a userspace VPN (only one VPN per device though - beware of possible conflicts). In fact I have a functioning solution for it, in beta now - https://github.com/vesvault/VESmail-apple (vmVPN module) https://github.com/vesvault/snif-tunl (IPv4 local terminator, required by the one above, can extend to v6) > It does provide a useable name for the device, and it does provide for > *an* > address which can be used to reach the device. But, it essentially has > created a kind of secure TURN service which gives a global (HTTPS) name > for a device, > allowing it to be reached globally. There are some aspects of the SNIF > which seem to deal with ABUSE. In fact, not just HTTPS, but any protocol over TLS - imaps, smtps etc, or any custom ports, as long as the connection is over TLS. In theory it's possible to extend to STARTTLS based protocols too. > > While the SNIF CA and Connection proxies could be run by a number of > parties, > given that the devices need to have a pre-existing relationship with those > parties (and that provisioning of credential stage is out of scope > according > to the document), it seems that it will only really be operated by the > manufacturer, or some large delegate like an ISP that sells IoT devices. > What would the economic argument/incentive for other parties to operate > these > services? > Still, if SNIF is replacing a manufacturer proprietary call-home protocol, > there could be advantages from having well reviewed code bases, and > potentially an ecosystem of SNIF Providers that manufacturers could > outsource > to. Azure/Amazon/... could easily run such services. I see two options - a SNIF server implemented by each vendor for their own devices/services, or a bigger SNIF SaaS implemented by a trusted provider, used by vendors. > > SNIF seems very much IPv4 NAT44 focused, and it could benefit from some > understanding of IPv6 and IPv6-over-IPv4 technologies, particularly > Teredo. SNIF is not exactly focused on v4, it works fine with v6 as well. It's designed to work around NAT, that's true. However, IPv6 networks may pose issues too - firewalls etc, which will prevent to directly accept incoming TCP on IPv6 address. > > DISPATCH COMMENTS > ----------------- > > There are a lot of issues that I have with the proposal that would need > significant work to document and/or sort out. As such I would definitely > advise against AD sponsor. > > This protocol is not really big enough to warrant it's own WG, although > other > similiar sized protocols (such as ACME) have their own WG. If ten people > from four different vendors showed up and wanted to work on this, then a > new > WG might be reasonable. > Much of SNIF is about new variations of certificate enrollment. > Some of it is very similiar to draft-ietf-anima-brski-cloud. > > If BEHAVE was still alive, dispatching there could make sense because it's > a > also a new kind of TURN, and maybe it should just be a new variation. > Dispatch to ACME almost makes sense. > (To quote the _Broken Sword_ game: "That was almost a good idea") > > It could be dispatched to ANIMA. I don't think that it would make it > through > ANIMA with the same look, but at least we have lots of RFC7030 expertise. > > IOTOPS was chartered to do some IoT dispatch work, and it could be that > this > document should go there. It is not clear to me yet if SECDISPATCH has > the patience to understand the document well enough to make a decision. > > DETAILED COMMENTS > ----------------- > > Section 2 will need a diagram for the Proxy, Relay, Connector, Client, CA. > I think that before introducing the components, a simpler walk through is > needed. > > 3.1: Connector speaks HTTP or HTTPS. > It clearly has to speak HTTPS only. I specified HTTP because PKCS#10 and X.509 are inherently secure to be sent over a plain connection. HTTP makes the management easier - the HTTP host is the base name of the CN which points to the CA Proxy, i specifically recommend using a wildcard CN in the Security section. The CN Allocation request MAY be sent over plain HTTP too - the returned CN is uniquely generated, and is useless until the cert is issued to it. There's only one shot of uploading the CSR, if the intruder does it first - the SNIF Connector will get an error, and will have to hard reset and get another CN. > > How does device learn their initUrl? > If it is programmed into the device by the manufacturer, then > basically > it's the manufacturer's service. > If it is provided by the end user, through an admin interface, then > how > is that interface secured? > DHCP option? > We have a multitude of onboarding protocols now, I suggest that > extensions to a few of them be provided for here. The best option is the manufacturer I believe. The manufacturer can have either their own SNIF server, or work with a trusted SaaS. This way it's zero setup for the end user, and doesn't need any infrastructure additions. In case of a device with limited user interaction (as most IoT are), the initUrl will be unique per device, and contain a kind of private ID, to work in conjunction with a unique public ID in a link (QR code) given to the user. I outlined it in the Security section without excessive details, it might be a topic for a separate document. > > For instance, in an RFC8995 BRSKI situation, the initURL, along with > an > optional trust anchor to validate it (if DNS-ID verification is a > problem), could be provided in the voucher. Of course, if one was > doing > BRSKI, then it might be better to just do BRSKI-CLOUD here. > This flow: > https://www.ietf.org/archive/id/draft-ietf-anima-brski-cloud-02.html#name-voucher-request-handled-by- > is essentially exactly what is needed here. > Some dynamic extensions are definitely a possibility. > 3.2: > "Any key algorithm acceptable by the CA can be used, generally > RSA-4096 is recommended." > I would not recommend RSA-4096. Effective security of RSA keys does > not > go up linearly with size. 4096 bits just uses a lot of space for very > little benefit. ECDSA, EDDSA would be better recommendations. > Sure, elliptic curves are better, but some old school clients may have problems with them. It may make sense to not mention the recommended algorithm in the draft, and just to follow the CA's recommendations. > The Connector flow where it allocates a CN is essentially the > CSRattrs > problem that LAMPS is clarifying in RFC7030 with the > https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030-csrattrs/ > which has been neglected since IETF112, but I hope will be adopted at > IETF113. Agreed, CSRattrs can be used. I just don't see anything besides CN that should be controlled by the CA Proxy, there are no other requirements on a CSR that SNIF Connector can benefit from accepting dynamically instead of being pre-set. > > 3.3: generally, GET is a bad idea for something that allocates something. > Either use X-SNIF-CN:, or the payload, not both. DRY. > text/plain is probably the wrong choice for a mime type here. The allocation returns a unique random CN, without obligations to ever issue a certificate to, but is a prerequisite for the CSR submission - e.g. https://snif.snif.xyz:4443/ I believe there's no security issue, as long as the CN entropy is sufficient. I specified the X-SNIF-CN: as mandatory, and text/plain body as an optional duplicate of it. To make it cleaner, I can remove the body from the specs and say the response body is to be ignored. > > 3.4: PUT is an interesting choice. It's not wrong though. > Having a 201 reply where one can collect a status report is nice. > I wish that RFC7030 did that. The point is - if the SNIF Connector gets 201 then it's ok to proceed. Otherwise - retry, and/or hard reset to get a new CN. > > 3.5: as I understand it, the certificate is actually retrived from the > DN/dnsName that was allocated using http. > That seems to imply that http can never be used with the device? > (I don't think it should, but...) > At least this should be in /.well-known. The DNS points to the SNIF server (Relay / CA Proxy). Therefore, HTTP request goes to the server, and downloads the issued and cached cert (or 503 to try later). HTTP, or any other plain protocol, cannot be relayed to the device, at least within the SNIF paradigm. The domain verification with the CA can be done either through HTTP or DNS, as the CA Proxy has control over both. In case of Let's Encrypt, a wildcard cert can only be verified with DNS. > > section 4 deals with the relay protocol. > I didn't look at that deeply at this. > It seems pretty complex, and as long as this is greenfield, why > not > use HTTP/2 and/or QUIC so that multiple requests can be sent over > a > single pinhole? It could be, SNIF can be potentially extended to do it. My objective was to simplify the implementation of SNIF Connector on a device. Within the scope of the document, the SNIF Connector opens a Service Connection TCP, sends a plain SNIF ACCEPT, and hands the entire socket over off to the TLS server process. No multiplexing, less headache in many ways. > > This entire part is very very much IPv4 focused. > IPv6 devices shouldn't need any of this. > > But, perhaps more to the point, UPnP pretty much already does this. > So does Teredo. In case of a clear static IPv6 you don't need SNIF. In real life the IoT device IP is likely to be dynamic, there might be firewalls that drop incoming SYN and whatnot. Relying on nothing but outgoing TCP connections is probably the safest way to deal with existing infrastructure, this is what SNIF is for. > > section 4.6 on ABUSE Management is an interesting addition. > This part should be coordinated against what DOTS WG has already built. > I found your security considerations section to be well written. > Good to hear, thanks. > I'm not sure I understand the IANA registration of "snif", etc. > They *aren't* what IANA would call "IP protocols", which would be things > like > TCP, UDP, SCTP, ESP, ... > Has IANA *already* registered port 7123 then? It's not an IP protocol. It's a service that listens on TCP 7123, I registered with IANA based on a previous version of the document, before I turned it into an I-D. > > > -- > Michael Richardson . o O ( IPv6 IøT consulting > ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > From nobody Thu Feb 10 07:10:46 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 08F483A08A1 for ; Thu, 10 Feb 2022 07:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVx2KqLJ3XGv for ; Thu, 10 Feb 2022 07:10:40 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 5179D3A08A0 for ; Thu, 10 Feb 2022 07:10:40 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id e11so3633732ils.3 for ; Thu, 10 Feb 2022 07:10:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=qr6Rudysx3M/k0evEDS4+dKPfTYW2C4JY6pSFFPRHEA=; b=O9lFC/LfdZW7EvDu2HuXpb+b/nLtNX2ursIr9P9vZwJuZHUnQaiACgFwV6xXo56t/3 mMko6POkpBnsLUg9/p2zTcBTIOZYbRd5G4gh8aJIkl1UONYsyxYTzmIkvrVs0yInIDey xIC6pMMzwBdZ5QTXN+62TjI5G8jjelUv9C3eAmhSjphlMPod4MP7WLIXDw+zzY3Ru13n GJeI5t0ggLKDqIXW36FapjP6/vc/BM644mBeG1uwLkL+citqG4fCC8jCZfBur/zWvrnU JubWK/Uib8gin8vxPe1vtRI+aOizHdMB2effWpQcV5ShFq+iK883os+rAXcGYhmzbtvA g00Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qr6Rudysx3M/k0evEDS4+dKPfTYW2C4JY6pSFFPRHEA=; b=xByqDmkOjm1wJYPRSERkouQHwv7OtnAlV89UHE65eaJZ/88INaX8MwfSPNIOxx794F Qt1Hp4akW5PcdvRvb8ZxBCZc71NKJm/4Rz5sczklXGkGQxWxfaQ3zeHz7lADEjvvMgsC 1/F6XceIcmn8JqR9YHBTTVamzPXJN/Yi61YYTNvCQeQQa1iNEK5Dy2dWGBjmNXF3wmXN nARYLRmwRNTe/L+dy2bURMsyu1GbKFUUhdMVuiqJqqvK/vOxIbu7hMTCZYfrpdxfRLtL S1XKqOMnpPOyJrhsuOri2Q1kYtlllxtQ5NNr4IQ2wchHUoKqF645M2qvrPbc/yTh3dHa +w5g== X-Gm-Message-State: AOAM533AKCFrmS6e5hVGJxEMWC23um26pBWGRazmYfvGDCXxOslSpUhJ e+SNAhL5h2VPvePfayOxib76gObXpXTz+CksnhSfFVOG+uVnRw== X-Google-Smtp-Source: ABdhPJxdaHzL23JiT4Qq4GfOrKFIuY4bV9GhvO0OKyuC7WWZyu5bbrydtQZIjscJR/cQPTmDXYNO8MQIrrOcahiG5pw= X-Received: by 2002:a92:b008:: with SMTP id x8mr3013844ilh.170.1644505837738; Thu, 10 Feb 2022 07:10:37 -0800 (PST) MIME-Version: 1.0 From: Warren Kumari Date: Thu, 10 Feb 2022 10:10:01 -0500 Message-ID: To: iotops@ietf.org Content-Type: multipart/alternative; boundary="0000000000004a33f105d7ab5ab9" Archived-At: Subject: [Iotops] IETF "leaderhip pipeline" 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, 10 Feb 2022 15:10:45 -0000 --0000000000004a33f105d7ab5ab9 Content-Type: text/plain; charset="UTF-8" Hi there all, An ongoing topic in the IETF & IESG is how to grow the IETF "leadership pipeline", so that when we need new AD and / or chairs, we have good candidates. Currently when a new chair needs to be appointed the process goes something like this (with some added hyperbole): The AD(s) thinks "Hmmm.. I need a chair for FOOWG, and so I need someone who understands FOO protocol. Erm.... Oh! Mary! Mary knows FOO, and she's sane and friendly and organized and will keep things moving. Everyone knows Mary, she's strong enough to push back on the crazy, she'll keep the meetings running along... She has the added advantage of not working for the same company as $other_chair, but gets on well with $other_chair. Oh! She's also already chaired BARWG and BAZWG and that went OK... She's perfect, I'll appoint Mary!". (In practice there is usually also discussions with the other chair (if any), a mail to the WG asking for volunteers, some discussions with key WG participants to see if they have any suggestions, etc, but there is still a tendency / bias to appoint someone known to the AD / "the obvious" candidate / people who have already demonstrated competence. Clearly this is suboptimal... If it is a new WG there is usually a BOF and additional discussions on BOF proponents and chairs, but the general principle holds) Often, when appointing a chair, there is a bit of a rush - a meeting is coming up, a new WG is being formed, etc, and people who would make good candidates are overlooked, or are not really confident enough to put themselves forward for a specific role. So, what I'd like to try is asking for volunteers who'd like to be considered when we are looking for chairs. In some cases it is important that the chair(s) are experts in the technology - but a lot of chairing also involves more general technical knowledge, "leadership"/diplomacy/mediation, organizational skills, babysitting, etc. I've created a Google form to record answers / help me keep track of volunteers: https://forms.gle/P8dZ8diT7Y5kFsNA7 Don't worry, filling in the form isn't a commitment to serve, but rather a "Hey, I'm interested, please keep me in mind when choosing a new FOOWG chair". Information will be shared with the current (and future) Ops & Mgmt ADs, unless you tick the "Any WG in the IETF", in which case your interest will be shared with other IESG members. Obviously, if you are not comfortable filling in the form but still want to volunteer, just email Warren and/or Rob. Also, as always, if you have any questions, comments, etc do the same.... Warren and Rob -- Perhaps they really do strive for incomprehensibility in their specs. After all, when the liturgy was in Latin, the laity knew their place. -- Michael Padlipsky -- Perhaps they really do strive for incomprehensibility in their specs. After all, when the liturgy was in Latin, the laity knew their place. -- Michael Padlipsky --0000000000004a33f105d7ab5ab9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there all,
An ongoing topic in the I= ETF & IESG is how to grow the IETF "leadership pipeline", so = that when we need new AD and / or chairs, we have good candidates.

Currently when a new chair needs to be appointed the proce= ss goes something like this (with some added hyperbole):
The = AD(s) thinks "Hmmm.. I need a chair for FOOWG, and so I need someone w= ho understands FOO protocol. Erm.... Oh! Mary! Mary knows FOO, and she'= s sane and friendly=C2=A0and organized and will keep things moving. Everyon= e knows Mary, she's strong=C2=A0enough to push back on the crazy, she&#= 39;ll keep the meetings running along... She has the added advantage of not= working for the same company=C2=A0as $other_chair, but gets on well with $= other_chair.=C2=A0 Oh! She's also already chaired BARWG and BAZWG=C2=A0= and that went OK... She's perfect, I'll appoint Mary!".=C2=A0<= /div>

(In practice there is usually also discussions wit= h the other chair (if any), a mail to the WG asking for volunteers, some di= scussions with key WG participants to see if they have any suggestions, etc= , but there is still a tendency / bias to appoint someone known to the AD /= "the obvious" candidate / people who have already=C2=A0demonstra= ted competence.=C2=A0 Clearly this is suboptimal... If=C2=A0 it is a new WG= there is usually a BOF and additional=C2=A0discussions on BOF proponents a= nd chairs, but the general principle holds)

Often,= when appointing a chair, there is a bit of a rush - a meeting is coming up= , a new WG is being formed, etc, and people who would make good candidates= =C2=A0are overlooked, or are not really confident enough to put themselves = forward for a specific=C2=A0role.=C2=A0

So, what I= 'd like to try is asking for volunteers who'd like to be considered= when we are looking for chairs. In some cases it is important that the cha= ir(s) are experts in the technology - but a lot of chairing also involves m= ore general technical knowledge, "leadership"/diplomacy/mediation= , organizational skills, babysitting, etc.=C2=A0

I= 've created a Google form to record answers / help me keep track of vol= unteers:=C2=A0https://forms.gle/P8dZ8diT7Y5kFsNA7

Don&#= 39;t worry, filling in the form isn't a commitment to serve, but rather= a "Hey, I'm interested, please keep me in mind when choosing a ne= w FOOWG=C2=A0chair".
Information will be shared with the cur= rent (and future) Ops & Mgmt ADs, unless you tick the "Any WG in t= he IETF", in which case your interest will be shared with other IESG m= embers.

Obviously, if you are not comfortable fill= ing in the form but still want to volunteer, just=C2=A0email Warren and/or = Rob.

=C2=A0Also, as always, if you have any questi= ons, comments, etc do the same....
Warren and Rob

<= /div>--
Per= haps they really do strive for incomprehensibility in their specs.
After= all, when the liturgy was in Latin, the laity knew their place.
-- Mich= ael Padlipsky

--
Perhaps = they really do strive for incomprehensibility in their specs.
After all,= when the liturgy was in Latin, the laity knew their place.
-- Michael P= adlipsky
--0000000000004a33f105d7ab5ab9-- From nobody Thu Feb 10 10:03:11 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 4C5D33A0E78; Thu, 10 Feb 2022 10:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_OTHER_BAD_TLD=1.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 8Ial0Ce_McDg; Thu, 10 Feb 2022 10:02:56 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8763A0AB8; Thu, 10 Feb 2022 10:02:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 92C8D389EC; Thu, 10 Feb 2022 13:10:36 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NUyTzGEMX1Uk; Thu, 10 Feb 2022 13:10:33 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A0A34389DB; Thu, 10 Feb 2022 13:10:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1644516633; bh=jjywtfinMLwXeW5N35J1il8W+dnft6HPNiH08zf0bvY=; h=From:To:Subject:In-Reply-To:References:Date:From; b=KKRl7Ihtw1hcFHISfuDscXC/PfL9VSNEtFMkfW/t8HxKVccq5N1xAI9yvS8EVj3FE DbaX5shIKvM/WEB0n8sJNoOtmzGsy9YvTYaPaTGokin5vIv2H/eMIILJ0FKI1+mJao C46X11dI5QkaLqeF8AQazz1RJ7PifRF7hW+B7kzCcGnt+UAVAeYB6wsNhWH8nFzGTZ R75IP0+gFnofkT7ADODdCBnSU89owLF/VK8iYp1k25DYR1wiUrG9YcnbXAWJs55lFu pAeO6EafhMC8gXb0Qm3DgeX0U29dk32hxusJH+Mi4Y9E0s4g0q/4wKbGuZO5WIJ4kg CY7vi/AZv+M/w== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0C2ABB5A; Thu, 10 Feb 2022 13:02:48 -0500 (EST) From: Michael Richardson To: Jim Zubov , secdispatch@ietf.org, iotops@ietf.org, anima@ietf.org In-Reply-To: References: <0075B437-024A-4D84-ABD7-92FE8DAFA59F@commercebyte.com>, <1865.1644434146@localhost> 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] [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) 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, 10 Feb 2022 18:03:04 -0000 --=-=-= Content-Type: text/plain Jim Zubov wrote: >> This was also on the IETF112 IOTOPS WG agenda: >> slides: >> https://datatracker.ietf.org/meeting/112/materials/slides-112-iotops-suib-browsing-local-web-resources-in-a-secure-usable-manner-iot-device-configuration-as-a-special-case-00 >> video: https://youtu.be/OIlJrUvwDcI?t=1649 >> >> and we hope to return at IETF113. > Right, looks like SUIB is working on a similar problem. Thanks for > pointing this out. In particular, the "Sol #6 Device name DNS" slide > looks quite similar to SNIF CA Proxy (Section 3). However, SUIB pursues > bigger infrastructural goals such as changing the localhost TLS > connection policies (I totally agree and really appreciate the effort), > while SNIF is a functioning solution within the existing > infrastructure, tested and proven to work in pre-production. The slides may be too vague. Changing the TLS policies is a possible solution, but probably an impractical one. Nevertheless, many people (not steeped in the arts, and often failling into the PHB category) think that it is an obvious solution, so we list it in order to explain why it won't work. >> The SUIB problem addresses the challenge of connecting *locally* to a >> device, >> and doing it securely. For this to be possible with RFC6125-DNS-ID >> standard >> browser, we need a name for the device, and we need a way to translate >> that >> name into a locally reachable IP address. >> >> The SNIF proposal does not quite solve the above problem. > In fact, I originally designed SNIF to solve this specific problem - > local-to-local trusted TLS connections. Ah, very nice to know. > * Issue a wildcard cert through SNIF CA Proxy > (e.g. CN=*.domain.snif.xyz), set a DNS record for > localhost.domain.snif.xyz to point to localhost's IPv4/v6, and use > https://localhost.domain.snif.xyz (or other app protocol - imaps > etc). However, looks like some clients treat the localhost IP as > inherently unsecure, and issue a warning ever is the cert is perfectly > valid. The option is still possible, but the applicability might be > limited. The process we described at https://specs.manysecured.org/suib/Solutions/dnsname-embedded-solution also uses a wildcard cert, but has a magic authoritative DNS server that translates the left-most label into an A or AAAA record. It's rather a cute hack, but at least: a) it's cachable b) it could even be calculated locally, if one ignores DNSSEC. > * Another option is to override the IP routing rules. It is totally > possible on iOS and Mac through a userspace VPN (only one VPN per > device though - beware of possible conflicts). In fact I have a > functioning solution for it, in beta now - That doesn't really scale to many different domains. >> Still, if SNIF is replacing a manufacturer proprietary call-home protocol, >> there could be advantages from having well reviewed code bases, and >> potentially an ecosystem of SNIF Providers that manufacturers could >> outsource >> to. Azure/Amazon/... could easily run such services. > I see two options - a SNIF server implemented by each vendor for their > own devices/services, or a bigger SNIF SaaS implemented by a trusted > provider, used by vendors. Yes, but what's the financial motive for this provider? >> SNIF seems very much IPv4 NAT44 focused, and it could benefit from some >> understanding of IPv6 and IPv6-over-IPv4 technologies, particularly >> Teredo. > SNIF is not exactly focused on v4, it works fine with v6 as well. It's > designed to work around NAT, that's true. However, IPv6 networks may > pose issues too - firewalls etc, which will prevent to directly accept > incoming TCP on IPv6 address. Teredo could be used instead and allows the relay to be stateless and distributed, and devolves to ordinary IPv6 when it is present. >> It clearly has to speak HTTPS only. > I specified HTTP because PKCS#10 and X.509 are inherently secure to be > sent over a plain connection. Yes, but there are privacy concerns which will become a pain, so better to just say HTTPS here. > The best option is the manufacturer I believe. The manufacturer can > have either their own SNIF server, or work with a trusted SaaS. This > way it's zero setup for the end user, and doesn't need any > infrastructure additions. Agreed, the manufacturer has to provision a credential. > Sure, elliptic curves are better, but some old school clients may have > problems with them. It may make sense to not mention the recommended > algorithm in the draft, and just to follow the CA's recommendations. ECDSA acceleration is pretty much ubiquitous, while RSA is not. > I believe there's no security issue, as long as the CN entropy is sufficient. > I specified the X-SNIF-CN: as mandatory, and text/plain body as an > optional duplicate of it. To make it cleaner, I can remove the body > from the specs and say the response body is to be ignored. If both are present, and they don't match, then there is confusion. So just go with one. I think that it should actually be a JSON or CBOR payload return. >> They *aren't* what IANA would call "IP protocols", which would be things >> like >> TCP, UDP, SCTP, ESP, ... >> Has IANA *already* registered port 7123 then? > It's not an IP protocol. It's a service that listens on TCP 7123, I > registered with IANA based on a previous version of the document, > before I turned it into an I-D. I think you should drop the "snif-*" sentence as it makes no sense. You have already allocated TCP port 7123 to the SNIF *service*, so that's great. -- ] Never tell me the odds! | ipv6 mesh networks [ ] 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----- iPMEAQEKAB0WIQSk7ZHEG9TCGBNASfm/sjw/rPYc8wUCYgVTRwAKCRC/sjw/rPYc 89dMBgCrP+l6VxgSthdVVnbP/y2G+hLh6gzKIizcGuzjqmnvgasndixgI33ERSZz 7LKc2F+n1jgC7IoJyr9Vy0TFf+/3hA3UagHWwOZKBXoyzUYVGC05Taz1Var/DU2G BQPpGL9Ec4MJ2ANCxmfggemue+sB4pVtiHW3q20sSPSX6LnzdUifViKBMhEk4Qo3 9W4ZnJYU+PYTDYasB+8lKO+1x7dRQEdN7+/FpGgswVm6KEtphALNs5jXOYkh4Vl5 44+1KXs= =8xit -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 10 15:23:42 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 B82B63A0DF7; Thu, 10 Feb 2022 15:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.09 X-Spam-Level: X-Spam-Status: No, score=-5.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_PDS_SHORTFWD_URISHRT_QP=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=commercebyte.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 bTubiHkQlL25; Thu, 10 Feb 2022 15:23:26 -0800 (PST) Received: from ocean1.commercebyte.com (ocean1.commercebyte.com [104.131.120.15]) (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 D61C13A0DE9; Thu, 10 Feb 2022 15:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=commercebyte.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:References:In-Reply-To:Subject:To:From:Date; bh=bZaPp/44tVpljoGwOxNHvIPzZcKUxfuoJpQRRxeQSBU=; b=BuRC1otOUmuyvPTPdRcBJt+caU2O6irHTCgKI6C8TT4VLnob5LDzZW1tipwDPlG+LgReA3ZgHVLNAnwMmymtqEzPtiUzyNYRATq8aA+QY9SX2E5BPkjrCaumogj3nN9Go7X8a9fe3v+fc27sh3Y3+edqz8XZ3d5yb5YP5wGnVbw=; Received: from [172.58.128.19] (port=1644 helo=[IPv6:::1]) by ocean1.commercebyte.com with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1nIImV-0003U9-CD; Thu, 10 Feb 2022 18:23:21 -0500 Received: from [2604:a880:400:d0::1ba9:8001]:7120 (helo=[IPv6:::1]) by [2607:fb90:9037:7ecd:28a5:b9f7:1bd1:2d89]:48022 (localhost) with VESmail ESMTP Proxy 1.59 (encrypt=FALSE mode=FALLBACK); Thu, 10 Feb 2022 18:23:19 -0500 Date: Thu, 10 Feb 2022 18:21:58 -0500 From: Jim Zubov To: secdispatch@ietf.org, Michael Richardson , Jim Zubov , iotops@ietf.org, anima@ietf.org User-Agent: K-9 Mail for Android In-Reply-To: <4026.1644516168@localhost> References: <0075B437-024A-4D84-ABD7-92FE8DAFA59F@commercebyte.com>, <1865.1644434146@localhost> <4026.1644516168@localhost> Message-ID: <685366A1-01F4-4788-B025-0F5F4CE7947F@commercebyte.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ocean1.commercebyte.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - commercebyte.com X-Get-Message-Sender-Via: ocean1.commercebyte.com: authenticated_id: jz@nixob.com Archived-At: Subject: Re: [Iotops] [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) 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, 10 Feb 2022 23:23:32 -0000 Thanks for the feedback again, my comment are below=2E I submitted a new version of the draft to reflect some changes=2E On February 10, 2022 1:02:48 PM EST, Michael Richardson wrote: > >Jim Zubov wrote: > >> This was also on the IETF112 IOTOPS WG agenda: > >> slides: > >> https://datatracker=2Eietf=2Eorg/meeting/112/materials/slides-112-= iotops-suib-browsing-local-web-resources-in-a-secure-usable-manner-iot-devi= ce-configuration-as-a-special-case-00 > >> video: https://youtu=2Ebe/OIlJrUvwDcI?t=3D1649 > >> > >> and we hope to return at IETF113=2E > > > Right, looks like SUIB is working on a similar problem=2E Thanks fo= r > > pointing this out=2E In particular, the "Sol #6 Device name DNS" sl= ide > > looks quite similar to SNIF CA Proxy (Section 3)=2E However, SUIB p= ursues > > bigger infrastructural goals such as changing the localhost TLS > > connection policies (I totally agree and really appreciate the effo= rt), > > while SNIF is a functioning solution within the existing > > infrastructure, tested and proven to work in pre-production=2E > >The slides may be too vague=2E Changing the TLS policies is a possible >solution, but probably an impractical one=2E Nevertheless, many people (= not >steeped in the arts, and often failling into the PHB category) think that= it >is an obvious solution, so we list it in order to explain why it won't wo= rk=2E Yes, still sad that localhost slipped through the cracks when the original= security standards were written=2E > > >> The SUIB problem addresses the challenge of connecting *locally* t= o a > >> device, > >> and doing it securely=2E For this to be possible with RFC6125-DNS= -ID > >> standard > >> browser, we need a name for the device, and we need a way to trans= late > >> that > >> name into a locally reachable IP address=2E > >> > >> The SNIF proposal does not quite solve the above problem=2E > > > In fact, I originally designed SNIF to solve this specific problem = - > > local-to-local trusted TLS connections=2E > >Ah, very nice to know=2E > > > * Issue a wildcard cert through SNIF CA Proxy > > (e=2Eg=2E CN=3D*=2Edomain=2Esnif=2Exyz), set a DNS record for > > localhost=2Edomain=2Esnif=2Exyz to point to localhost's IPv4/v6, an= d use > > https://localhost=2Edomain=2Esnif=2Exyz (or other app protocol - im= aps > > etc)=2E However, looks like some clients treat the localhost IP as > > inherently unsecure, and issue a warning ever is the cert is perfec= tly > > valid=2E The option is still possible, but the applicability might = be > > limited=2E > >The process we described at > https://specs=2Emanysecured=2Eorg/suib/Solutions/dnsname-embedded-solu= tion > >also uses a wildcard cert, but has a magic authoritative DNS server that >translates the left-most label into an A or AAAA record=2E It's rather a= cute >hack, but at least: > a) it's cachable > b) it could even be calculated locally, if one ignores DNSSEC=2E Yes, using a local network IP instead of a localhost IP is actually a smar= t idea=2E However, inlining the local IP in the hostname, as SUIB does, means you'll= have to change the hostname in your client every time your network is chan= ged=2E I have an thought for SNIF improvement - SNIF connector sends a SNIF DNS c= ommand to set a dynamic DNS A/AAAA for a certain hostname within the CN wil= dcard, and the CA proxy updates the DNS accordingly=2E This way the hostnam= e can be permanent, but with dynamic DNS=2E Another problem - most platforms won't let you bind to port < 1024 unless = you're a root=2E Might be ok for a device manufacturer, but is a potential = show stopper for any user space app=2E Relayed SNIF works around this probl= em since the listening ports are on the relay=2E > > > * Another option is to override the IP routing rules=2E It is total= ly > > possible on iOS and Mac through a userspace VPN (only one VPN per > > device though - beware of possible conflicts)=2E In fact I have a > > functioning solution for it, in beta now - > >That doesn't really scale to many different domains=2E Totally agreed, I just mentioned that this option works for *some* cases, = tun/tap a is possible option too if you're a root=2E > > >> Still, if SNIF is replacing a manufacturer proprietary call-home p= rotocol, > >> there could be advantages from having well reviewed code bases, an= d > >> potentially an ecosystem of SNIF Providers that manufacturers coul= d > >> outsource > > >> to=2E Azure/Amazon/=2E=2E=2E could easily run such services=2E > > > I see two options - a SNIF server implemented by each vendor for th= eir > > own devices/services, or a bigger SNIF SaaS implemented by a truste= d > > provider, used by vendors=2E > >Yes, but what's the financial motive for this provider? (1) For a vendor to run their own SNIF server: market as a true auditable = end-to-end for IoT devices they offer=2E (2) For a vendor using SNIF SaaS: market as (1) backed by {TrustedBigName} (3) For a {TrustedBigName} to run SNIF SaaS: collect fees from (2) for usi= ng their service and big name=2E As a matter of fact, SNIF relay is light on server resources=2E I've been = running it on a minimum DigitalOcean virtual server for months with more th= an a dozen connectors, the server load is a fraction of a percent=2E Of c= ourse if somebody connects IoT cameras they can generate some traffic, but = IoT vendors already handle it through their proprietary relays=2E > > >> SNIF seems very much IPv4 NAT44 focused, and it could benefit from= some > >> understanding of IPv6 and IPv6-over-IPv4 technologies, particularl= y > > >> Teredo=2E > > > SNIF is not exactly focused on v4, it works fine with v6 as well=2E= It's > > designed to work around NAT, that's true=2E However, IPv6 networks = may > > pose issues too - firewalls etc, which will prevent to directly acc= ept > > incoming TCP on IPv6 address=2E > >Teredo could be used instead and allows the relay to be stateless and >distributed, and devolves to ordinary IPv6 when it is present=2E Yes, but Teredo is IPv6 specific, the world is not strictly IPv6 yet=2E An= d it's a system level solution, while SNIF works fine in a user space=2E > > >> It clearly has to speak HTTPS only=2E > > > I specified HTTP because PKCS#10 and X=2E509 are inherently secure = to be > > sent over a plain connection=2E > >Yes, but there are privacy concerns which will become a pain, so better t= o >just say HTTPS here=2E I respectfully disagree, still think HTTP is an easier answer for SNIF=2E = The problem with HTTPS is - SNIF relay (usually) routes https port to SNIF = connectors, and does not serve it within the server=2E Having a dedicated h= ostname or an alternate port means than SNIF connectors need additional con= figuration options, or additional discovery protocols=2E On the other hand,= HTTP allows to derive all API URLs deterministically from the CN=2E I addressed the possible security concerns in more details and amended the= Security section in the draft=2E > > > The best option is the manufacturer I believe=2E The manufacturer c= an > > have either their own SNIF server, or work with a trusted SaaS=2E T= his > > way it's zero setup for the end user, and doesn't need any > > infrastructure additions=2E > >Agreed, the manufacturer has to provision a credential=2E Yes I proposed some outlines in the security section, more detailed specs = are probably better to describe in a separate draft=2E > > > Sure, elliptic curves are better, but some old school clients may h= ave > > problems with them=2E It may make sense to not mention the recommen= ded > > algorithm in the draft, and just to follow the CA's recommendations= =2E > >ECDSA acceleration is pretty much ubiquitous, while RSA is not=2E Honestly I don't think acceleration is such a big deal, most of TLS job is= symmetric ciphers anyway=2E But I agree - it's better to follow the CA sug= gestions and industry practices=2E > > > I believe there's no security issue, as long as the CN entropy is s= ufficient=2E > > > I specified the X-SNIF-CN: as mandatory, and text/plain body as an > > optional duplicate of it=2E To make it cleaner, I can remove the bo= dy > > from the specs and say the response body is to be ignored=2E > >If both are present, and they don't match, then there is confusion=2E >So just go with one=2E I think that it should actually be a JSON or CBOR= payload return=2E Agreed, I removed the response body from the draft, going with the header= =2E > > >> They *aren't* what IANA would call "IP protocols", which would be = things > >> like > >> TCP, UDP, SCTP, ESP, =2E=2E=2E > > >> Has IANA *already* registered port 7123 then? > > > It's not an IP protocol=2E It's a service that listens on TCP 7123,= I > > registered with IANA based on a previous version of the document, > > before I turned it into an I-D=2E > >I think you should drop the "snif-*" sentence as it makes no sense=2E >You have already allocated TCP port 7123 to the SNIF *service*, so that's >great=2E It's actually called "Service Names" in IANA terminology, sorry for the co= nfusion=2E I updated in the draft=2E > >-- >] Never tell me the odds! | ipv6 mesh netwo= rks [ >] Michael Richardson, Sandelman Software Works | IoT architec= t [ >] mcr@sandelman=2Eca http://www=2Esandelman=2Eca/ | ruby on= rails [ > From nobody Mon Feb 14 08:47:57 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 7B14B3A11B2; Mon, 14 Feb 2022 08:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.65 X-Spam-Level: X-Spam-Status: No, score=-6.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9d0tFopFxfJK; Mon, 14 Feb 2022 08:47:52 -0800 (PST) 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 598033A11AB; Mon, 14 Feb 2022 08:47:50 -0800 (PST) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 46122549B53; Mon, 14 Feb 2022 17:47:45 +0100 (CET) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3721D4EA659; Mon, 14 Feb 2022 17:47:45 +0100 (CET) Date: Mon, 14 Feb 2022 17:47:45 +0100 From: Toerless Eckert To: iotops@ietf.org, secdir@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Archived-At: Subject: [Iotops] (Home) user question: securing web access to insecure IOT web interfaces 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, 14 Feb 2022 16:47:56 -0000 Sorry if these are not the right list to ask this (pointers to better lists welcome), but i stumbled across i think a common problem that i am now getting curious about: - Many IOT devices / systems (controllers) have terrible security profiles. Many have just a port 80 web service without authentication. At least thats the case my question here is about as a starter. - The typical answer from "the industry" is to provide remote access to them is "Use a VPN", So just for the sake of picking an example, lets assume its IKEv2/IPsec with a server side WebPKI certificate, client side user/password and filtering of all traffic except for said web server port 80. - But of course, being able to simply use a browser is a lot more convenient, and arguably less user/client error-prone - because it does not require VPN client installation. Which then gets to the question: - Are there any useful analysis defining what exactly would constitute the most simple (combination of) application layer security mechanisms that could be considered equal or better in terms of security against attacks than such an IKEv2/IPsec VPN headend ? I assume it starts with something like reverse proxy with HTTPs+HTTP-auth, but IKEv2 also seems to have some simple DoS attack prevention that needs to be replicated, and then i guess the HTTPs connection also has some higher attack surface with all the messages one could try before successful authentication, HTTP message headers for example could provide information about the server side helping the attacker, etc. pp. Thanks! Toerless From nobody Mon Feb 14 13:21:15 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 E23173A1043; Mon, 14 Feb 2022 13:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.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 dKAtwrAWL4Lo; Mon, 14 Feb 2022 13:21:08 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E953A103D; Mon, 14 Feb 2022 13:21:06 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4JyHFp0ymcz3K7; Mon, 14 Feb 2022 22:21:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1644873662; bh=6pcXaNNO9bRF9NreDqGMJ40G5MFfehM9H0mV24pEptY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=czuMk1jGDPyQxHKFP4oa6mnqZeGSOewkoSd9ox5Op09cL1YyxujD3JUk6iDSS6w3q FGGbZljs8WA5thKdjKuH5alhQxgz/nenF5z6387DzdnjupA7h1ncQQocDunQWzKTJd r0JzfEXbNzM8WfDREfWLbJ66yBj/sZxohsLs7+dw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id oY6Cpatfxynz; Mon, 14 Feb 2022 22:21:01 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 14 Feb 2022 22:21:00 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C36CD252974; Mon, 14 Feb 2022 16:20:59 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C0A8E252973; Mon, 14 Feb 2022 16:20:59 -0500 (EST) Date: Mon, 14 Feb 2022 16:20:59 -0500 (EST) From: Paul Wouters To: Toerless Eckert cc: iotops@ietf.org, secdir In-Reply-To: Message-ID: <8acb5596-1183-67f0-adc5-c4937eb7f5e@nohats.ca> References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Iotops] [secdir] (Home) user question: securing web access to insecure IOT web interfaces 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, 14 Feb 2022 21:21:13 -0000 On Mon, 14 Feb 2022, Toerless Eckert wrote: > - Are there any useful analysis defining what exactly would constitute the most > simple (combination of) application layer security mechanisms that could be > considered equal or better in terms of security against attacks than > such an IKEv2/IPsec VPN headend ? (m)TLS ? > I assume it starts with something like reverse proxy with HTTPs+HTTP-auth, but > IKEv2 also seems to have some simple DoS attack prevention that needs to be > replicated, and then i guess the HTTPs connection also has some higher attack > surface with all the messages one could try before successful authentication, > HTTP message headers for example could provide information about the server side > helping the attacker, etc. pp. The message parsing is generally not the problem. It is doing things like DiffieHellman and Signature creation/validation that takes the most CPU. A reverse proxy of TLS endpoint should have enough resources to fend of an attack similar to IKEv2. Paul From nobody Mon Feb 14 15:22:44 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 0C4A03A131F; Mon, 14 Feb 2022 15:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.65 X-Spam-Level: X-Spam-Status: No, score=-6.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iNwDJTxAMP1; Mon, 14 Feb 2022 15:22:24 -0800 (PST) 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 EA1C73A131C; Mon, 14 Feb 2022 15:22:23 -0800 (PST) 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 E04EE549B4C; Tue, 15 Feb 2022 00:22:17 +0100 (CET) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id CE6C14EA660; Tue, 15 Feb 2022 00:22:17 +0100 (CET) Date: Tue, 15 Feb 2022 00:22:17 +0100 From: Toerless Eckert To: Paul Wouters Cc: iotops@ietf.org, secdir Message-ID: References: <8acb5596-1183-67f0-adc5-c4937eb7f5e@nohats.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8acb5596-1183-67f0-adc5-c4937eb7f5e@nohats.ca> Archived-At: Subject: Re: [Iotops] [secdir] (Home) user question: securing web access to insecure IOT web interfaces 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, 14 Feb 2022 23:22:29 -0000 On Mon, Feb 14, 2022 at 04:20:59PM -0500, Paul Wouters wrote: > On Mon, 14 Feb 2022, Toerless Eckert wrote: > > > - Are there any useful analysis defining what exactly would constitute the most > > simple (combination of) application layer security mechanisms that could be > > considered equal or better in terms of security against attacks than > > such an IKEv2/IPsec VPN headend ? > > (m)TLS ? ? > > I assume it starts with something like reverse proxy with HTTPs+HTTP-auth, but > > IKEv2 also seems to have some simple DoS attack prevention that needs to be > > replicated, and then i guess the HTTPs connection also has some higher attack > > surface with all the messages one could try before successful authentication, > > HTTP message headers for example could provide information about the server side > > helping the attacker, etc. pp. > > The message parsing is generally not the problem. I would assume every web server software whether open source or proprietary has been analysef well enough to find any buffer overflow or similar attack vectors. And given the flexibility of HTTP compared to the much more constrained binary messages of IKEv2, i can imagine that there is much higher likelyhood of security relevant bugs. But i don't know whether people have tried to quantify and compare. > It is doing things > like DiffieHellman and Signature creation/validation that takes the > most CPU. > > A reverse proxy of TLS endpoint should have enough resources to fend of > an attack similar to IKEv2. Yes, i am not concerned abour resources, just about defining required DoS protection mechanisms. Cheers Toerless > Paul -- --- tte@cs.fau.de From nobody Tue Feb 15 08:56:03 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 329EC3A0E40; Tue, 15 Feb 2022 08:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50C2g6VhlUMo; Tue, 15 Feb 2022 08:55:57 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id E3CC43A0E2B; Tue, 15 Feb 2022 08:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1644944155; d=isode.com; s=june2016; i=@isode.com; bh=Up7+NNKF1aGWbajWhnOrwpxHjYOsx6tIHB3b3v2uvQQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=S/Sqd1U6DVbSu1rwPLW+5HJsLCVd24ms8uSw16EfGE3cxn8PwH8baWWPQwL8aekcQJ9ncO x+qeffmL1O14B5akbPZIAN2OxLN+uXNGIC3AWHKSZVs2MEcdDXxPDkxXabfUNw8/b1sYrC 2x1z2zOBWfx+4dDNN55mB+Rh3+xkg/o=; Received: from [192.168.1.222] (host31-49-219-49.range31-49.btcentralplus.com [31.49.219.49]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 15 Feb 2022 16:55:55 +0000 Message-ID: <4fb03be3-9e89-c30c-638b-3e14ce543a94@isode.com> Date: Tue, 15 Feb 2022 16:55:47 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 To: iotops@ietf.org From: Alexey Melnikov Cc: "iotops-chairs@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Iotops] Call for agenda items @ IETF 113 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, 15 Feb 2022 16:56:01 -0000 Dear WG participants, Please email your WG chairs for agenda slots in Vienna. Best Regards, Alexey on behalf of chairs. From nobody Wed Feb 16 13:30:17 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 AFC923A16B7; Wed, 16 Feb 2022 13:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.1 X-Spam-Level: X-Spam-Status: No, score=-7.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ooQFbTrn0Fno; Wed, 16 Feb 2022 13:30:06 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4673A16B4; Wed, 16 Feb 2022 13:30:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C60E338A51; Wed, 16 Feb 2022 16:38:09 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id O0ztJuxPvW9E; Wed, 16 Feb 2022 16:38:07 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CA5B938A4E; Wed, 16 Feb 2022 16:38:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1645047487; bh=FkP8B8TJYJ8n7wIYP6hD54JZnMCfeZD7UzTvLPAfdYw=; h=From:To:Subject:CC:In-Reply-To:References:Date:From; b=54AhG8EOmmKx/MrQar623fenF7AfPh+Nl//qQXoUs1Kx5jYmcRTTqVMJWVb4peypq vPSz+crCycDLyLn3pxL/sVMkFP6izDJMYHLlhXGWbJ6+pZsq04jUNytdE+Ucq7THo1 HSsbf6P+E8GAhHoCioM1A0+0IoHHcUDygNa5MnwG/XGXKDiwypoIsykKdZwmlo/V8K g5SmA5GEm4P6PPcwNMYPKVkJK7ch6eItc8kFfSZzksHSR6lToIEQBliJt5B7CZhyq6 h/1m281Juz+F/3O6TN/R/0jd5wrgOL4A7hcqj/JAZNHYiFTGS3kUCuqYBOF7boF+8q KQhimlx456A6w== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 16150527; Wed, 16 Feb 2022 16:29:59 -0500 (EST) From: Michael Richardson To: Alexey Melnikov , iotops@ietf.org, "iotops-chairs\@ietf.org" CC: Henning Schulzrinne , Manysecured In-Reply-To: <4fb03be3-9e89-c30c-638b-3e14ce543a94@isode.com> References: <4fb03be3-9e89-c30c-638b-3e14ce543a94@isode.com> 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] Call for agenda items @ IETF 113 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, 16 Feb 2022 21:30:11 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alexey Melnikov wrote: > Please email your WG chairs for agenda slots > in Vienna. Under the heading of IoT ownership, which I have presented twice on, and Eliot spoke about IoT mid-life crisis, we have a few other things. * Henning Schulzrinne has some work that be spoke abo= ut at the RIOT-OS Summit on geographical IoT controls. * We've had the SECRET BOF last week that deals with how to delegate/provision credentials for other users of a "device" (car, lock, etc.) ** It is unclear to me what system allows for delegation of credentials, but there is apparently something at the CCC. I would really like to hear about such a system. Under the heading of HTTPS access to IoT devices, which might be "local", t= he SUIB document now has a reasonable number of solutions detailed. And then the SNIF work. =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----- iPMEAQEKAB0WIQSk7ZHEG9TCGBNASfm/sjw/rPYc8wUCYg1s1gAKCRC/sjw/rPYc 8zM+BgCsCyIM5wnZT5aXg/jcPw/PxFd/5VTbUo9uSDKikPfyP0ZvplA4kH2iZNSL 1J9EBDS4RoEuCwWd2AJwtOAo/6WvOY7Unhr6RKNfZY6m7LJ56p+KUhSdZ2sdncxc qOhTW7rKBRzvQ6swyw7iPupc1vbWkIyONZfehfg9FPo5oSLvRi+cV/njW/Jqcx0P equK3W1qCvhYSTXWeXqRzjsOXbz0aL4UnWFsX5tq1G+e4ES1HAwyXdd9lQs/VDeg JSTPJjo= =Rb1g -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 16 19:54: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 BB6443A0AEF; Wed, 16 Feb 2022 19:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=commercebyte.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 VJKEh55vpR1X; Wed, 16 Feb 2022 19:54:30 -0800 (PST) Received: from ocean1.commercebyte.com (ocean1.commercebyte.com [104.131.120.15]) (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 9D78E3A0B55; Wed, 16 Feb 2022 19:54:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=commercebyte.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:References:In-Reply-To:Subject:To:From:Date; bh=ZB2gJNBBHD5wZLZ9jjQONbsjjTcjJIqgTj5LGpL/S0o=; b=PCXGCrQjdLb2yMcmlGJsh5ejiGiOJd/hIf9Ix8DrdyN1I/to858Rkt5WDhmq/PZNg2B/cf/nBwUNvJeKqpaqq1PIXiA3XbaIBXG2G5Ccv+QUDdIYAyFbEd/2Ws+R9cH3eQE6UX7RIwf4RBjSYc8qiUQJGye+x61Jlv//ufwBCtQ=; Received: from [47.204.174.73] (port=40594 helo=[127.0.0.1]) by ocean1.commercebyte.com with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1nKXsC-0004DT-Nh; Wed, 16 Feb 2022 22:54:29 -0500 Received: from [206.81.2.95]:7120 (helo=[127.0.0.1]) by [192.168.254.152]:49280 (localhost) with VESmail ESMTP Proxy 1.59 (encrypt=FALSE mode=FALLBACK); Wed, 16 Feb 2022 22:54:28 -0500 Date: Wed, 16 Feb 2022 22:54:22 -0500 From: Jim Zubov To: iotops@ietf.org, anima@ietf.org User-Agent: K-9 Mail for Android In-Reply-To: <164506868864.3087.6215639232560879013@ietfa.amsl.com> References: <164506868864.3087.6215639232560879013@ietfa.amsl.com> Message-ID: <82ED3C66-583B-4A1A-A98A-5AE7E40541E2@commercebyte.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ocean1.commercebyte.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - commercebyte.com X-Get-Message-Sender-Via: ocean1.commercebyte.com: authenticated_id: jz@nixob.com Archived-At: Subject: [Iotops] Fwd: New Version Notification for draft-zubov-snif-04.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, 17 Feb 2022 03:54:36 -0000 A new revision of the SNIF draft, according to Michael Richardson's suggest= ions=2E - An https only high security option for CA proxy API, which involves an a= dditional {apiUrl} configuration parameter for SNIF connectors, - Amended security section, SNIF relay identity verification as a high sec= urity option, - Private key algo as per CA suggestions and industry practices=2E -------- Original Message -------- A new version of I-D, draft-zubov-snif-04=2Etxt has been successfully submitted by Jim Zubov and posted to the IETF repository=2E Name: draft-zubov-snif Revision: 04 Title: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-ba= sed End-to-End TLS Forwarding (SNIF) Document date: 2022-02-16 Group: Individual Submission Pages: 21 URL: https://www=2Eietf=2Eorg/archive/id/draft-zubov-snif-04=2E= txt Status: https://datatracker=2Eietf=2Eorg/doc/draft-zubov-snif/ Html: https://www=2Eietf=2Eorg/archive/id/draft-zubov-snif-04=2E= html Htmlized: https://datatracker=2Eietf=2Eorg/doc/html/draft-zubov-snif Diff: https://www=2Eietf=2Eorg/rfcdiff?url2=3Ddraft-zubov-snif-0= 4 Abstract: This document proposes a solution, referred as SNIF, that provides the means for any Internet connected device to: * allocate a globally unique anonymous hostname; * obtain and maintain a publicly trusted X=2E509 certificate issued for the allocated hostname; * accept incoming TLS connections on specific TCP ports of the allocated hostname from any TLS clients that are capable of sending Server Name Indication=2E The private key associated with the X=2E509 certificate is securely stored on the TLS terminating device, and is never exposed to any other party at any step of the process=2E About This Document This note is to be removed before publishing as an RFC=2E Status information for this document may be found at https://datatracker=2Eietf=2Eorg/doc/draft-zubov-snif=2E Information can be found at https://snif=2Ehost=2E Source for this draft and an issue tracker can be found at https://github=2Ecom/vesvault/snif-i-d=2E = =20 The IETF Secretariat From nobody Fri Feb 18 14:14: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 DDFEB3A08D0 for ; Fri, 18 Feb 2022 14:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 0ACZHnxOwzID for ; Fri, 18 Feb 2022 14:14:48 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862EB3A1543 for ; Fri, 18 Feb 2022 14:14:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EEB7438B73 for ; Fri, 18 Feb 2022 17:22:15 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FjhUy1UsyiND for ; Fri, 18 Feb 2022 17:22:14 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1CC8238B6C for ; Fri, 18 Feb 2022 17:22:14 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1645222934; bh=hYjVWT+Snv4XJGWT63ti7Ql//4e2ctYe/MsIGyvRX9A=; h=From:To:Subject:Date:From; b=Aw9CcFi8wOu1oQn4mrGHdYCNyJ8EExU5PqL6smN0dCKM/T3j7zL5nGjN5shEPwUQa 5mR17ynFSNPlITARwaBJNxqQAiyA7CEON1/xtIO2X8TEiVVdCcq91nwUY4RcFyk2pQ hN5mKMDRbhpbZJ7hSUvAoyftn6T3na9OaMWl99WE9uNsO4aJbU+pTPWYwTSa+H1iCe jPjHQF+m2qJ3XxM+VUpqBcRbqV9lOD2BhJBMYCq38SLHhBYFUVrde/RBwDc1wEraVv hhilGxIvQF8poBGxmm7qLYpX1dX8Kg6cDOMzwzl0so+m/Fh+V5Xv1dFrcZvyN+b+BV 7+bzxpHbf9M7Q== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B937E40A for ; Fri, 18 Feb 2022 17:13:57 -0500 (EST) From: Michael Richardson To: iotops@ietf.org 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: [Iotops] draft-carpenter-6man-rfc6874bis-03 and IoT devices in the home 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, 18 Feb 2022 22:14:54 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain This document tries to make it possible to write: http{,s}://[fe80::1234%eth0]/ in order to talk to IoT devices that are directly connected. (Yes, the https part is very difficult, and this document does not deal with it at all, but at present, we can't even do the http version) --=-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=74 Content-Description: forwarded message Replied: Fri, 18 Feb 2022 17:12:17 -0500 Replied: "Brian E Carpenter , =?us-ascii?Q?=3D=3FUT?= Replied: =?us-ascii?Q?F-8=3FQ=3FOle=5FTr=3Dc3=3Db8an=3F=3D?= , Replied: 6man " Return-Path: Received: from tuna.sandelman.ca [2607:f0b0:f:3::184] by localhost with IMAP (fetchmail-6.4.0.beta4) for (single-drop); Fri, 18 Feb 2022 16:19:09 -0500 (EST) Received: from tuna.sandelman.ca ([unix socket]) by tuna (Cyrus 3.0.8-Debian-3.0.8-6+deb10u6) with LMTPA; Fri, 18 Feb 2022 14:48:47 -0500 X-Cyrus-Session-Id: cyrus-31671-1645213727-1-4064781029208919315 X-Sieve: CMU Sieve 3.0 Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E66EB38B73 for ; Fri, 18 Feb 2022 14:48:46 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1nQUIKFYIhd5 for ; Fri, 18 Feb 2022 14:48:45 -0500 (EST) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPS id 1876438B6C for ; Fri, 18 Feb 2022 14:48:45 -0500 (EST) Authentication-Results: tuna.sandelman.ca; dkim=pass (1024-bit key; secure) header.d=ietf.org header.i=@ietf.org header.b="wd62Mbpc"; dkim=pass (1024-bit key) header.d=ietf.org header.i=@ietf.org header.b="StNIF0la"; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="gQuQ+QzU"; dkim-atps=neutral Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7243A13B7 for ; Fri, 18 Feb 2022 11:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1645213228; bh=lBQV+dks77TApJKNLADGpSd6KG4GkMRihmzB/AhDFyE=; h=Subject:From:To:References:Date:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=wd62MbpcTSHapJ4q/Ka066zpQlsou9bzbYwwYoX7B0Q86wrAm3negNNGr/qNbuwZF bDHj6xRrSN2DnwjpN/BlGz+ORNzUyC2QgwTFsnhChxro+4nqo6zfRCH1R071FayS+n N3ZYpeGib4KTbs/NLybVdoNw23TNU1TKj36Nvnj4= X-Mailbox-Line: From ipv6-bounces@ietf.org Fri Feb 18 11:40:25 2022 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF5B3A0F41; Fri, 18 Feb 2022 11:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1645213225; bh=lBQV+dks77TApJKNLADGpSd6KG4GkMRihmzB/AhDFyE=; h=Subject:From:To:References:Date:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=StNIF0laN2asXsV1SAAaTbMLxuJPuO4vSRm4lXB6i39cVK+ryj92QFXQgYLQRJo71 3aATmfrZqaZ043ztk6f/ILaP33rffD7UAWwfmdeMem5tvKTgKvbqyLPzJD/DqzPhP4 zWBWrQ++DcEmueIjL4CUti/BmA8ogFanbxrxsLGo= X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6AE3A0F41 for ; Fri, 18 Feb 2022 11:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 QR9MWop2jnxF for ; Fri, 18 Feb 2022 11:40:18 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 1E3E43A1427 for ; Fri, 18 Feb 2022 11:40:14 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id 195so8710473pgc.6 for ; Fri, 18 Feb 2022 11:40:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:from:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uryUikUDD4Ca+LwWFIKtWhhXTHwVettVxA2ILt84HLA=; b=gQuQ+QzUGya/QdGEWHcL4uE1u1og4HmsEouuLXUtE2w0CEyX/GT4NHCzzZu8itXUc1 LQofhwekGxqtMgj0VpB3HStUGXtHaD5RgZ8jeXt/XIbYn2O6cKYvuKUmp8YoLXcxiuoQ Pfy06hLdmnz36XNc7rYAAphZdF3rjAUQsTYXwjc88oiJfGO3QW/VCfDMK+HdNAecAXFX TSn0oAhcTcGICd3Pb6fbbiFUV44fox5HDJ/suHXNNV3sCO5q1eHXZ6zjPz6CDoVdanwT Je1wYbsa4RuuXV+NWECtjfd04wUz8ePM+gc7xh3ToWDAh62d5+QITomvUu0rCxHmZ9w1 Vu3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:from:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uryUikUDD4Ca+LwWFIKtWhhXTHwVettVxA2ILt84HLA=; b=omEG1N+GZxHMR7m8wZ9ufSfIfkiKpx5+3EmhNN2jvD7mQy4DOyMyHomWMUhCDBihhs ze4HyDsEG8jp/uDkA4xotc9hA1W9e20ffAk/tRz1w1WnE2H5BougPSVccwU8+I+L2MsC +aeM7SzBgetrv+Tf0c1Fq6ArvCDxmNTlVxZu5ZwOUnlYDfrXPkMCb+dzS6ME4G6Rc0NW 8d34xYblbsWq5RuLM4r9IQmyjk4TjkMcnrb8pt9cG6tVGZqazoH2VIxSXekzqpx0uHt8 U4pUxTpaUPFjtsje/OBoM4EFmOrawfsBB+4kqvfZfGauHQX+WE3k0yNf4r5W1+sT6NIR xwkA== X-Gm-Message-State: AOAM532Pu09FeYf7dI5ACODvSeBAt4xdagiiWoBSjes1Of6USsQz8De4 kww1qMiiiRLVvalPoTagdyk0W65KC4vUng== X-Google-Smtp-Source: ABdhPJw4+jPepkzGnN6GKqla2EpiLa9GyNHKEEBxAOrOHAJYkNhrBiH5lAR4BNsj/h/ZH5nwlug8Vw== X-Received: by 2002:a63:2dc4:0:b0:373:6512:a12f with SMTP id t187-20020a632dc4000000b003736512a12fmr7422526pgt.344.1645213213015; Fri, 18 Feb 2022 11:40:13 -0800 (PST) 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 nl8sm201017pjb.18.2022.02.18.11.40.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Feb 2022 11:40:12 -0800 (PST) Subject: Requesting WG adoption of draft-carpenter-6man-rfc6874bis-03 From: Brian E Carpenter To: =?UTF-8?Q?Ole_Tr=c3=b8an?= References: <164435080246.24571.1463637164428714834@ietfa.amsl.com> <67a7fb86-47c2-69d0-cd71-c73323dbb659@gmail.com> Message-ID: <983cb951-65c4-5b81-dfe3-b5b3ba68e352@gmail.com> Date: Sat, 19 Feb 2022 08:40:08 +1300 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: <67a7fb86-47c2-69d0-cd71-c73323dbb659@gmail.com> Content-Language: en-US Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 6man Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: ipv6-bounces@ietf.org Sender: "ipv6" SGkgT2xlLAoKV2UnZCBsaWtlIHRvIHJlcXVlc3QgV0cgYWRvcHRpb24gb2YgdGhpcyBkcmFmdCwg c2luY2UgdGhlcmUgaGF2ZSBiZWVuCm5vIGFkdmVyc2UgcmVhY3Rpb25zIHRvIHRoZSBsYXRlc3Qg dmVyc2lvbi4KCldlIGRvbid0IGZlZWwgaXQgbmVlZHMgYSBkaXNjdXNzaW9uIHNsb3QgYXQgdGhl IHVwY29taW5nIG1lZXRpbmcsIHNpbmNlCml0J3MgYmVlbiBkaXNjdXNzZWQgYmVmb3JlLiBCdXQg b2YgY291cnNlIHdlJ2Qgd2VsY29tZSBkaXNjdXNzaW9uIGhlcmUKb24gdGhlIGxpc3QuCgpSZWdh cmRzCiAgICBCcmlhbiBDYXJwZW50ZXIKT24gMDktRmViLTIyIDA5OjI4LCBCcmlhbiBFIENhcnBl bnRlciB3cm90ZToKPiBIaSwKPiAKPiBUaGUgYXV0aG9ycyBvZiB0aGlzIGRyYWZ0IGRpZCwgYXMg cHJldmlvdXNseSBtZW50aW9uZWQsIG9wZW4gZGlzY3Vzc2lvbgo+IHdpdGggdmFyaW91cyBwZW9w bGUgaW4gdGhlIGJyb3dzZXIgY29tbXVuaXR5LCBidXQgd2UgZGlkIG5vdCBmaW5kIG11Y2gKPiBl bnRodXNpYXNtIGZvciBpbXBsZW1lbnRhdGlvbi4gVW50aWwgdGhlcmUgaXMgYSBncmVhdCBpbmNy ZWFzZSBpbiBkZW1hbmQKPiBmb3IgbGluay1sb2NhbHMgdG8gYmUgc3VwcG9ydGVkIGJ5IGJyb3dz ZXJzLCB0aGUgbmVjZXNzYXJ5IHdvcmsgc2VlbXMKPiB1bmxpa2VseSB0byBiZSBkb25lLgo+IAo+ IEhvd2V2ZXIsIHdlIGJlbGlldmUgdGhhdCB0aGlzIGRlbWFuZCB3aWxsIGV2ZW50dWFsbHkgYXJp c2UgYW5kIHRoZXJlZm9yZQo+IGl0J3MgaW1wb3J0YW50IHRoYXQgdGhlIHJlbGV2YW50IFVSSSBz eW50YXggaXMgd2VsbC1kZWZpbmVkLiBUaGVyZWZvcmUsCj4gd2UndmUgdXBkYXRlZCB0aGUgZHJh ZnQuIEFwYXJ0IGZyb20gZWRpdG9yaWFsIGltcHJvdmVtZW50cywgdGhlcmUgaXMgYQo+IHNpZ25p ZmljYW50IGNoYW5nZSBpbiB0aGlzIHZlcnNpb24uIEZvbGxvd2luZyB0aGUgZGlzY3Vzc2lvbnMg YSBmZXcgbW9udGhzCj4gYWdvLCBhbmQgYWZ0ZXIgSSBzcGVudCBzb21lIHRpbWUgbG9va2luZyBp bnRvIHRoZSBVUkkgcGFyc2VycyBpbiB3Z2V0IGFuZAo+IEZpcmVmb3ggKGFuZCBhIGJyaWVmIGxv b2sgYXQgY3VybCksIHdlIHByb3Bvc2UgdG8gZHJvcCB0aGUgIiUyNSIgZW5jb2RpbmcKPiBvZiAi JSIuIFRoZSBBQk5GIGluIHRoaXMgdmVyc2lvbiwgb3JpZ2luYWxseSBzdWdnZXN0ZWQgYnkgQW5k cmV3IENhZHksCj4gcmVmbGVjdHMgdGhhdCBwcm9wb3NhbC4gVGhlcmUgaXMgZXh0cmEgZXhwbGFu YXRpb24gaW4gdGhlIHRleHQuCj4gCj4gVGhlIG90aGVyIHNpZ25maWNhbnQgY2hhbmdlIGlzIHRo YXQsIGFzIE1hcnRpbiBEw7xyc3QgcG9pbnRlZCBvdXQsIHdlCj4gYWxzbwo+IG5lZWQgdG8gZm9y bWFsbHkgdXBkYXRlIHRoZSBJUkkgc3ludGF4LiBUaGF0IHdhcyBhbiBvbWlzc2lvbiBpbiBSRkM2 ODc0Lgo+IAo+IEl0IG1heSBiZSB0aW1lIHRvIGNvbnNpZGVyIFdHIGFkb3B0aW9uIG9mIHRoaXMg ZHJhZnQuCj4gCj4gUmVnYXJkcwo+ICAgICAgIEJyaWFuICYgY28tYXV0aG9ycwo+IAo+IAo+IC0t LS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tCj4gU3ViamVjdDogSS1EIEFjdGlvbjog ZHJhZnQtY2FycGVudGVyLTZtYW4tcmZjNjg3NGJpcy0wMy50eHQKPiBEYXRlOiBUdWUsIDA4IEZl YiAyMDIyIDEyOjA2OjQyIC0wODAwCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnCj4g UmVwbHktVG86IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZwo+IFRvOiBpLWQtYW5ub3VuY2VAaWV0 Zi5vcmcKPiAKPiAKPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuCj4gCj4gCj4gICAgICAgICAgIFRp dGxlICAgICAgICAgICA6IFJlcHJlc2VudGluZyBJUHY2IFpvbmUgSWRlbnRpZmllcnMgaW4gQWRk cmVzcyBMaXRlcmFscyBhbmQgVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVycwo+ICAgICAgICAg ICBBdXRob3JzICAgICAgICAgOiBCcmlhbiBDYXJwZW50ZXIKPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgU3R1YXJ0IENoZXNoaXJlCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJv YmVydCBNLiBIaW5kZW4KPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtY2FycGVudGVyLTZtYW4t cmZjNjg3NGJpcy0wMy50eHQKPiAJUGFnZXMgICAgICAgICAgIDogMTEKPiAJRGF0ZSAgICAgICAg ICAgIDogMjAyMi0wMi0wOAo+IAo+IEFic3RyYWN0Ogo+ICAgICAgVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgaG93IHRoZSB6b25lIGlkZW50aWZpZXIgb2YgYW4gSVB2NiBzY29wZWQKPiAgICAgIGFk ZHJlc3MsIGRlZmluZWQgYXMgPHpvbmVfaWQ+IGluIHRoZSBJUHY2IFNjb3BlZCBBZGRyZXNzIEFy Y2hpdGVjdHVyZQo+ICAgICAgKFJGQyA0MDA3KSwgY2FuIGJlIHJlcHJlc2VudGVkIGluIGEgbGl0 ZXJhbCBJUHY2IGFkZHJlc3MgYW5kIGluIGEKPiAgICAgIFVuaWZvcm0gUmVzb3VyY2UgSWRlbnRp ZmllciB0aGF0IGluY2x1ZGVzIHN1Y2ggYSBsaXRlcmFsIGFkZHJlc3MuICAKSXQKPiAgICAgIHVw ZGF0ZXMgdGhlIFVSSSBHZW5lcmljIFN5bnRheCBhbmQgSW50ZXJuYXRpb25hbGl6ZWQgUmVzb3Vy Y2UKPiAgICAgIElkZW50aWZpZXIgc3BlY2lmaWNhdGlvbnMgKFJGQyAzOTg2LCBSRkMgMzk4Nykg YWNjb3JkaW5nbHksIGFuZAo+ICAgICAgb2Jzb2xldGVzIFJGQyA2ODc0Lgo+IAo+IAo+IFRoZSBJ RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOgo+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNhcnBlbnRlci02bWFuLXJmYzY4NzRiaXMv Cj4gCj4gVGhlcmUgaXMgYWxzbyBhbiBIVE1MIHZlcnNpb24gYXZhaWxhYmxlIGF0Ogo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtY2FycGVudGVyLTZtYW4tcmZjNjg3NGJp cy0wMy5odG1sCj4gCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxh YmxlIGF0Ogo+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1jYXJwZW50 ZXItNm1hbi1yZmM2ODc0YmlzLTAzCj4gCj4gCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2 YWlsYWJsZSBieSByc3luYyBhdCByc3luYy5pZXRmLm9yZzo6aW50ZXJuZXQtZHJhZnRzCj4gCj4g Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBJLUQt QW5ub3VuY2UgbWFpbGluZyBsaXN0Cj4gSS1ELUFubm91bmNlQGlldGYub3JnCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UKPiBJbnRlcm5ldC1EcmFm dCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbAo+IG9yIGZ0cDov L2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0Cj4gCgotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpJRVRG IElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QKaXB2NkBpZXRmLm9yZwpBZG1pbmlzdHJh dGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2 Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCg== --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =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----- iPMEAQEKAB0WIQSk7ZHEG9TCGBNASfm/sjw/rPYc8wUCYhAaJQAKCRC/sjw/rPYc 81jaBf96RUIJG7pBp9v8ecWh6SaZs1H32EY7QF6mxmd3n10/kMShSm/DH7fCPkhw z+ne0QxYDPYea9CfzZfpTM92nsSZWnUYDpTnT1hAB3fKOuTRcsG3nOX5jb/xx1YB ZkF9H5IKZohP1RgB065zNO6eP9eWPW5AjtPQv4/eM5FxImDZLYpEw/fqq+qWykjz kDgfVPcuV0EDsejYNrGuZO+Hga3ln4kBvhU+pAjuiulAT/pTXJqgaT2ihSqiRVEz A2Gsqyc= =PZor -----END PGP SIGNATURE----- --==-=-=-- From nobody Fri Feb 18 15:45: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 6A5733A16A2; Fri, 18 Feb 2022 15:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 THztpyP2nwKW; Fri, 18 Feb 2022 15:45:04 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DA413A161D; Fri, 18 Feb 2022 15:43:36 -0800 (PST) Received: from client-0015.vpn.uni-bremen.de (client-0015.vpn.uni-bremen.de [134.102.107.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4K0pDN6zrLzDCbr; Sat, 19 Feb 2022 00:43:32 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 666920612.689468-01858d8d68a9e9427c378643ec6a7d22 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Message-Id: <95F952FD-FDFA-4040-8D07-EECE9EC3FE16@tzi.org> Date: Sat, 19 Feb 2022 00:43:32 +0100 To: asdf@ietf.org, coin@irtf.org, iotops@ietf.org, dance@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [Iotops] Constrained Node/Network Cluster @ IETF113: DRAFT AGENDA 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, 18 Feb 2022 23:45:11 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF113. Remember that there is still quite some potential for changes. The IoT-relevant conflicts that most meet the eye this time are LPWAN/ACE (probably little actual overlap) and DRIP/ROLL/RATS (probably a little more overlap, but not that much). CFRG and ICNRG are the only RGs not on top of IoT meetings (T2TRG, like e.g. CBOR and JSONPATH, decided to go for interims instead). All times are in UTC. Note that the third and fourth weeks in March (W11 =3D pre-IETF week, W12 =3D IETF week) are Weeks of Confusion, where DST has not yet started in Europe but did already start in North America. https://datatracker.ietf.org/meeting/agenda-utc might be handy. Gr=C3=BC=C3=9Fe, Carsten SATURDAY, March 19, 2022 0830-2000 Hackathon - Grand Klimt Hall 1/2 0930-1000 Hackathon Kickoff - Grand Klimt Hall 1/2 SUNDAY, March 20, 2022 0830-1500 Hackathon - Grand Klimt Hall 1/2 (0900-1700 IETF Registration - Park Ensemble) 1300-1500 Hackathon Results Presentations - Grand Klimt Hall 1/2 (1600-1800 Welcome Reception - Grand Park Hall 1/2/3) MONDAY, March 21, 2022 0900-1100 Morning Session I G Park Hall 3 ART dispatch Dispatch WG - Joint with ARTAREA G Park Hall 1 OPS v6ops IPv6 Operations WG G Klimt Hall 2 RTG raw Reliable and Available Wireless WG G Park Hall 2 SEC dance DANE Authentication for Network Clients = Everywhere WG Park Suite 3 SEC *** teep Trusted Execution Environment = Provisioning WG 1200-1300 Afternoon session I Park Suite 8 ART sedate Serialising Extended Data About Times = and Events WG G Park Hall 2 IRTF pearg Privacy Enhancements and Assessments = Research Group Park Suite 3 SEC acme Automated Certificate Management = Environment WG Park Suite 9 SEC *** cose CBOR Object Signing and Encryption WG G Park Hall 3 TSV tsvwg Transport Area Working Group WG 1330-1530 Afternoon Session II G Klimt Hall 2 SEC *** lake Lightweight Authenticated Key Exchange = WG Park Suite 8 SEC oauth Web Authorization Protocol WG G Park Hall 1 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG TUESDAY, March 22, 2022 0900-1100 Morning Session I Park Suite 9 INT 6man IPv6 Maintenance WG G Park Hall 1 RTG can Computing-Aware Networking BOF Park Suite 3 SEC *** rats Remote ATtestation ProcedureS WG G Park Hall 3 TSV quic QUIC WG 1200-1300 Afternoon session I G Park Hall 2 INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG G Park Hall 1 IRTF qirg Quantum Internet Research Group Park Suite 3 SEC *** ace Authentication and Authorization for = Constrained Environments WG Park Suite 8 SEC emu EAP Method Update WG Park Suite 9 TSV tsvarea Transport Area Open Meeting 1330-1530 Afternoon Session II G Park Hall 1 ART httpapi Building Blocks for HTTP APIs WG Park Suite 8 INT intarea Internet Area Working Group WG G Park Hall 2 IRTF irtfopen IRTF Open Meeting Park Suite 9 RTG detnet Deterministic Networking WG G Park Hall 3 SEC secdispatch Security Dispatch WG WEDNESDAY, March 23, 2022 0900-1100 Morning Session I G Klimt Hall 2 ART moq Media Over QUIC BOF Park Suite 8 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Park Suite 9 IRTF maprg Measurement and Analysis for Protocols G Park Hall 2 RTG rtgarea Routing Area Open Meeting G Park Hall 3 SEC tls Transport Layer Security WG 1200-1300 Afternoon session I Park Suite 2 ART mediaman Media Type Maintenance WG G Park Hall 1 INT *** drip Drone Remote ID Protocol WG Park Suite 8 RTG *** roll Routing Over Low power and Lossy = networks WG Park Suite 3 SEC mls Messaging Layer Security WG G Park Hall 3 SEC *** rats Remote ATtestation ProcedureS WG G Park Hall 2 TSV taps Transport Services WG 1330-1530 Afternoon Session II Park Suite 3 RTG bier Bit Indexed Explicit Replication WG 1600-1800 IETF Plenary - Grand Park Hall 1-3 THURSDAY, March 24, 2022 0900-1100 Morning Session I G Park Hall 1 INT savnet Source Address Validation in = Intra-domain and Inter-domain Networks BOF G Park Hall 2 IRTF coinrg Computing in the Network Research Group Park Suite 9 OPS *** iotops IOT Operations WG G Park Hall 3 SEC saag Security Area Open Meeting 1200-1300 Afternoon session I G Park Hall 3 INT madinas MAC Address Device Identification for = Network and Application Services WG G Klimt Hall 2 IRTF panrg Path Aware Networking RG Park Suite 8 RTG rift Routing In Fat Trees WG Park Suite 3 SEC privacypass Privacy Pass WG G Park Hall 2 SEC *** suit Software Updates for Internet of Things = WG 1330-1530 Afternoon Session II G Klimt Hall 2 ART webtrans WebTransport WG G Park Hall 3 IRTF cfrg Crypto Forum Park Suite 2 SEC oauth Web Authorization Protocol WG FRIDAY, March 25, 2022 0900-1100 Morning Session I G Klimt Hall 2 ART *** core Constrained RESTful Environments WG G Park Hall 3 INT add Adaptive DNS Discovery WG G Park Hall 2 SEC gnap Grant Negotiation and Authorization = Protocol WG Park Suite 8 SEC openpgp Open Specification for Pretty Good = Privacy WG 1130-1330 Afternoon Session I Park Suite 3 IRTF icnrg Information-Centric Networking G Klimt Hall 2 OPS anima Autonomic Networking Integrated Model = and Approach WG G Park Hall 3 TSV tsvwg Transport Area Working Group WG (### DST STARTS IN EUROPE ON SUNDAY ###) _______________________________________________ T2TRG mailing list T2TRG@irtf.org https://www.irtf.org/mailman/listinfo/t2trg From nobody Wed Feb 23 02:37:08 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 878A93A0A2B; Wed, 23 Feb 2022 02:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_OTHER_BAD_TLD=1.999, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=qaV5v3mb; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=qaV5v3mb 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 ZqQrSeOAzjt1; Wed, 23 Feb 2022 02:36:34 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on061e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::61e]) (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 361293A0A36; Wed, 23 Feb 2022 02:36:32 -0800 (PST) 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=E7uk2PphTtbZM/8dmtGW04vwETGZ2cIE+KP9FCaJ444=; b=qaV5v3mbogJGc1o0po1s82hWHj6oFnEwju4CT0Nauu+WkE74NFjYx9OM4slZHtPDLh7J8kGGgc/sqLii+vUgpQKikM/Kto6yynkPKVqmGAipaTsqFirJKMxtxxNvrQuz2/hJTfTdYQhucGV8jFzQiiRA35Xd3BvHnSPKJkfCsrs= Received: from AM5PR0601CA0031.eurprd06.prod.outlook.com (2603:10a6:203:68::17) by PAXPR08MB7492.eurprd08.prod.outlook.com (2603:10a6:102:2b5::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.26; Wed, 23 Feb 2022 10:36:26 +0000 Received: from VE1EUR03FT003.eop-EUR03.prod.protection.outlook.com (2603:10a6:203:68:cafe::49) by AM5PR0601CA0031.outlook.office365.com (2603:10a6:203:68::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.22 via Frontend Transport; Wed, 23 Feb 2022 10:36:26 +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 VE1EUR03FT003.mail.protection.outlook.com (10.152.18.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.22 via Frontend Transport; Wed, 23 Feb 2022 10:36:24 +0000 Received: ("Tessian outbound 341d209a0e52:v113"); Wed, 23 Feb 2022 10:36:24 +0000 X-CR-MTA-TID: 64aa7808 Received: from ffb1b4ecbc3c.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 56436921-B5F1-4E6C-AAA6-7368C061F35F.1; Wed, 23 Feb 2022 10:36:18 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id ffb1b4ecbc3c.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 23 Feb 2022 10:36:18 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CJTEEku7YKJgl4WzSI0H1nrX++E4mqNp4MKheRpyrdu2Q5S5DmDoD+eEmr7PQItMy/hW7OvlXkHLM9FfXq4YaEM63EOo65tv/mL+akdDxffLQ0JU013kPp2WrjvQfi59mwiOzQnal0qvS2aqBbIV6Z3l5hPX694W3qbZTb8cwy/5Tjjh+4klJhNMEisPy3Wk1Aiyx3ZipmOiQl/KokGN3Mi/HU9F4rKqKZ+wcgDSRr3uydcqHUfvkLS0A2CQEMDNHxUcrnmBKz89lpMumKs6ZjQdObOBzPEHpz1J0GA9TKdUrNIM+mEtXZsWyJsa9sCiHZFvS73kE0PTzux6yZoqpg== 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=E7uk2PphTtbZM/8dmtGW04vwETGZ2cIE+KP9FCaJ444=; b=lxSp4kOPb8uFJNHXs6xRukzPtrUHe+Itsr8NWH2crS8YnBAil2HywcHxmwxY3JGfw2lubQDRjvAfaGcVTY6lrxZ5tJXXbcDwXx5P0OUUy91kaW3xCkjsaWKK4z+W5xvq4IYQPs/s2Z5QgD2FmoS94Op/+tioIck0lRGaAZHv7qASpeyOBhIAbvXAMichP5R7hNLB3TGr2+QWdCdRoj01TTz+ThUJpF6483OvM0a4URSShsXJzpex/PNwyp/EvSF9s+syLyAo/LjYzTSbthwV8KAsB4Q60CkIqh9sJlOFMh/l0utsyGRqwbz01CkVJgSz2Oxi6Mc6kPb0qYyb3q4dQQ== 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=E7uk2PphTtbZM/8dmtGW04vwETGZ2cIE+KP9FCaJ444=; b=qaV5v3mbogJGc1o0po1s82hWHj6oFnEwju4CT0Nauu+WkE74NFjYx9OM4slZHtPDLh7J8kGGgc/sqLii+vUgpQKikM/Kto6yynkPKVqmGAipaTsqFirJKMxtxxNvrQuz2/hJTfTdYQhucGV8jFzQiiRA35Xd3BvHnSPKJkfCsrs= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by VI1PR08MB2909.eurprd08.prod.outlook.com (2603:10a6:802:1e::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.22; Wed, 23 Feb 2022 10:36:15 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::b478:3f3d:2464:65c8]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::b478:3f3d:2464:65c8%6]) with mapi id 15.20.4995.027; Wed, 23 Feb 2022 10:36:15 +0000 From: Hannes Tschofenig To: Jim Zubov , "secdispatch@ietf.org" , Michael Richardson , "iotops@ietf.org" , "anima@ietf.org" Thread-Topic: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) Thread-Index: AQHYHtVKop3offyr+0q9saoG3HE46Kyg/hiw Date: Wed, 23 Feb 2022 10:36:15 +0000 Message-ID: References: <0075B437-024A-4D84-ABD7-92FE8DAFA59F@commercebyte.com>, <1865.1644434146@localhost> <4026.1644516168@localhost> <685366A1-01F4-4788-B025-0F5F4CE7947F@commercebyte.com> In-Reply-To: <685366A1-01F4-4788-B025-0F5F4CE7947F@commercebyte.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: B5B438B4FD07654093A6AE0CB0C4F9E8.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: 4acbf725-cd2d-4ef9-0f7c-08d9f6b8576b x-ms-traffictypediagnostic: VI1PR08MB2909:EE_|VE1EUR03FT003:EE_|PAXPR08MB7492: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: 4ZKT98tUSJLM+UozoBs6YQgrgmTe3XHf2KySuqgDx9autlTXhoah4yHJaGhLvaIENf6Tx4KiRv5lchhZwhTtK3cBWQmDY6kEw68ssNhs27NE8SZnMLTTHqW3pGrm9PrdnH4XmySvhtT6MLnpzT7WVjg/ON+0uMY64KcPU5R9H17+jaFI4FGjad2S3rZsMvr/ekAvoht5mjFAVzOf9Lt9zZmD0C67K+brtvKf3IpEVSNq+8dIW7lqoFGNXYBzlzIENlKjHx56Ljh540c0/89T0gWLNrhc7VeMbdsyUWs1xGXt6CZa+okvy9mC+BsS34KszDzuJV2yHFR01j28FIgqLZRjhu27BukMXwEmY5QgbOa8BL203o6hD6AMBfJda3ROyHWzcdHnvLe2cDrc+iIj4aF6JsUiuR5+VndwDQqgJ+uSO30s8zTc8tB38QAz/EC4NUYRTHFE301Oh3i/EwqC8nOfuvONsBCsgfx4y/ydssG6zbmRi3un3YJrCA4CHdu+HKzkzRcOCC2CUzwQe1tH18rWwIgC0xhOnyuVSaeXGjPEFgpdSGOtms2wmUAnU9ZhMw01TbAFFsk3h8o31dIvnxBNuk0Qq0277pRBxavPe2JXS+NSJ2VqZavrWz+GQelLVxwMYtNv6e/FbUfblxVB71sYPDC3hBGRzj22k+JEmxT2LP4r9luY5VqL5CBgyASL8gWyl00Ktq0ao2jtYgrCfpVA7cveCTldt+b52CkE+Pfb09Q26x/IP0kyIelQ22upukecAlDuuy0QYPTke1ijKHgXMkjNI5UeSL+SM6xsjLIhzLt8dgqEGtQrS9OJQVdM03rskj6Z4MmO0RsXyiJvog5y9XMWeAlu4QQEJ20DFiA= 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)(52536014)(30864003)(38100700002)(66574015)(38070700005)(83380400001)(5660300002)(55016003)(2906002)(8936002)(33656002)(66446008)(6506007)(966005)(26005)(186003)(9686003)(66946007)(76116006)(53546011)(66556008)(122000001)(8676002)(71200400001)(66476007)(316002)(508600001)(7696005)(86362001)(110136005)(64756008)(69594002); 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: VI1PR08MB2909 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: VE1EUR03FT003.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 58a9eb3a-f158-4670-1fa5-08d9f6b851e9 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 2UF7n7AOH7RFz/s1WLsRPS+w0BBhhPHp1Y0qyVfNVPZJdvTBhYcJgQ1weXFI3LFCZK1Fx9SlZdywvieUD+dJR9PuFCq6AsxqUF8JZAm3iedkXkcTWzprm/o6ez+Ho/TSAy6v/A68j7TEBvwwkrZD5Th9x2mzvoQYkRanomO5ozgYrUeaMU7/oHk0ovsrdj4hQgsvRNhMcQ2wSC8ObmPmpVeXzmq3xQK98Bjulcsfs5JaS7LQg53KhxlWgtRP+j6KqksZ5/mWds/vlZsIcjNPC1Ses+T5iTeKdhu6QYiBBNwNt5gJV8NMsk7D5Y4Vf0qLw1srpwjWfPOsWPY5VgtMQ01/e7oF5reKjefjLhUi6xc3UWBTexJuhabxKArU0NhVHwczAsXrWRBsoe/ePYYclZAp6uXg9ard+igXZhpR4+DW9DlMrohYLxvHXvQsV3kIHOuBVg6L8rLPskaDMOG5VfpcxNQgTf0n4+OHBWRBsS7S1QKHpA5A2vI12igf2mohDQEFuj7ZTHzVxj4/eGoS0aLhJJf1g/mQ+ZtGhxWMlqaatL6y68gO2BgYacPNscye159KkGVfpnyP8w1LGdEP3CvxRy2FB0e2mo7QrEKAyYoRI9wGQa8PeiXE6651dnnl8WgNJZIkybKeZg0aPFNZA3XyhPZxVPz8nVnLFcvYFUbkoCXkF3hSjHooP8XGkALSlpc8Vq0eh+PBNAQWNj+cANIFsD2qMrjmB2RNPgocQ67Ceh6SOmLLEUTwOh6lIC89gdCX5aCU3JwmeZo159zM2lu3X+sMU3UtjehQuhBVspdEhh7TmCdnNn01cUl15OhX 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)(46966006)(36840700001)(40470700004)(30864003)(52536014)(2906002)(316002)(70586007)(70206006)(33656002)(8676002)(40460700003)(450100002)(81166007)(5660300002)(8936002)(110136005)(26005)(36860700001)(186003)(55016003)(82310400004)(508600001)(83380400001)(7696005)(966005)(47076005)(336012)(53546011)(356005)(9686003)(66574015)(86362001)(6506007)(69594002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2022 10:36:24.8185 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4acbf725-cd2d-4ef9-0f7c-08d9f6b8576b 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: VE1EUR03FT003.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR08MB7492 Archived-At: Subject: Re: [Iotops] [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) 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, 23 Feb 2022 10:36:39 -0000 Hi all, Thanks for this contribution, Jim. Reading through the document I agree that the SUIB topic discussed in the I= OTOPS WG appears relevant. I also wonder whether the work in the DANISH gro= up (see https://datatracker.ietf.org/wg/danish/about/) is relevant. Regarding the use in IoT I have a question for my understanding. In a nutshell, you introduce a proxy that allocates a hostname and requests= a creation of a certificate on behalf of the IoT device. To get this to work you rely on three assumptions: (1) There has to be a communication infrastructure that associates the "ano= nymous" hostname with a specific device and conveys these identifiers to th= e relevant parties. (2) You assume that a party that wants to contact the IoT device is able to= reach the device (i.e. the IoT device is not behind a firewall or NAT). (3) Someone operating IoT devices has to trust the proxy since it is easy f= or the proxy to associate a hostname with a public key that was created by = the proxy (rather than the end device). This essentially allows the proxy t= o impersonating the IoT device. Is my understanding correct? Ciao Hannes -----Original Message----- From: Secdispatch On Behalf Of Jim Zubov Sent: Friday, February 11, 2022 12:22 AM To: secdispatch@ietf.org; Michael Richardson ; Jim Z= ubov ; iotops@ietf.org; anima@ietf.org Subject: Re: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on I= oT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) Thanks for the feedback again, my comment are below. I submitted a new version of the draft to reflect some changes. On February 10, 2022 1:02:48 PM EST, Michael Richardson wrote: > >Jim Zubov wrote: > >> This was also on the IETF112 IOTOPS WG agenda: > >> slides: > >> https://datatracker.ietf.org/meeting/112/materials/slides-112-iotop= s-suib-browsing-local-web-resources-in-a-secure-usable-manner-iot-device-co= nfiguration-as-a-special-case-00 > >> video: https://youtu.be/OIlJrUvwDcI?t=3D1649 > >> > >> and we hope to return at IETF113. > > > Right, looks like SUIB is working on a similar problem. Thanks for > > pointing this out. In particular, the "Sol #6 Device name DNS" slide > > looks quite similar to SNIF CA Proxy (Section 3). However, SUIB purs= ues > > bigger infrastructural goals such as changing the localhost TLS > > connection policies (I totally agree and really appreciate the effor= t), > > while SNIF is a functioning solution within the existing > > infrastructure, tested and proven to work in pre-production. > >The slides may be too vague. Changing the TLS policies is a possible >solution, but probably an impractical one. Nevertheless, many people >(not steeped in the arts, and often failling into the PHB category) >think that it is an obvious solution, so we list it in order to explain wh= y it won't work. Yes, still sad that localhost slipped through the cracks when the original = security standards were written. > > >> The SUIB problem addresses the challenge of connecting *locally* to= a > >> device, > >> and doing it securely. For this to be possible with RFC6125-DNS-ID > >> standard > >> browser, we need a name for the device, and we need a way to transl= ate > >> that > >> name into a locally reachable IP address. > >> > >> The SNIF proposal does not quite solve the above problem. > > > In fact, I originally designed SNIF to solve this specific problem - > > local-to-local trusted TLS connections. > >Ah, very nice to know. > > > * Issue a wildcard cert through SNIF CA Proxy > > (e.g. CN=3D*.domain.snif.xyz), set a DNS record for > > localhost.domain.snif.xyz to point to localhost's IPv4/v6, and use > > https://localhost.domain.snif.xyz (or other app protocol - imaps > > etc). However, looks like some clients treat the localhost IP as > > inherently unsecure, and issue a warning ever is the cert is perfect= ly > > valid. The option is still possible, but the applicability might be > > limited. > >The process we described at > >https://specs.manysecured.org/suib/Solutions/dnsname-embedded-solution > >also uses a wildcard cert, but has a magic authoritative DNS server >that translates the left-most label into an A or AAAA record. It's >rather a cute hack, but at least: > a) it's cachable > b) it could even be calculated locally, if one ignores DNSSEC. Yes, using a local network IP instead of a localhost IP is actually a smart= idea. However, inlining the local IP in the hostname, as SUIB does, means you'll = have to change the hostname in your client every time your network is chang= ed. I have an thought for SNIF improvement - SNIF connector sends a SNIF DNS co= mmand to set a dynamic DNS A/AAAA for a certain hostname within the CN wild= card, and the CA proxy updates the DNS accordingly. This way the hostname c= an be permanent, but with dynamic DNS. Another problem - most platforms won't let you bind to port < 1024 unless y= ou're a root. Might be ok for a device manufacturer, but is a potential sho= w stopper for any user space app. Relayed SNIF works around this problem si= nce the listening ports are on the relay. > > > * Another option is to override the IP routing rules. It is totally > > possible on iOS and Mac through a userspace VPN (only one VPN per > > device though - beware of possible conflicts). In fact I have a > > functioning solution for it, in beta now - > >That doesn't really scale to many different domains. Totally agreed, I just mentioned that this option works for *some* cases, t= un/tap a is possible option too if you're a root. > > >> Still, if SNIF is replacing a manufacturer proprietary call-home pr= otocol, > >> there could be advantages from having well reviewed code bases, and > >> potentially an ecosystem of SNIF Providers that manufacturers could > >> outsource > > >> to. Azure/Amazon/... could easily run such services. > > > I see two options - a SNIF server implemented by each vendor for the= ir > > own devices/services, or a bigger SNIF SaaS implemented by a trusted > > provider, used by vendors. > >Yes, but what's the financial motive for this provider? (1) For a vendor to run their own SNIF server: market as a true auditable e= nd-to-end for IoT devices they offer. (2) For a vendor using SNIF SaaS: market as (1) backed by {TrustedBigName} (3) For a {TrustedBigName} to run SNIF SaaS: collect fees from (2) for usin= g their service and big name. As a matter of fact, SNIF relay is light on server resources. I've been run= ning it on a minimum DigitalOcean virtual server for months with more than = a dozen connectors, the server load is a fraction of a percent. Of course= if somebody connects IoT cameras they can generate some traffic, but IoT v= endors already handle it through their proprietary relays. > > >> SNIF seems very much IPv4 NAT44 focused, and it could benefit from = some > >> understanding of IPv6 and IPv6-over-IPv4 technologies, > particularly > > >> Teredo. > > > SNIF is not exactly focused on v4, it works fine with v6 as well. It= 's > > designed to work around NAT, that's true. However, IPv6 networks may > > pose issues too - firewalls etc, which will prevent to directly acce= pt > > incoming TCP on IPv6 address. > >Teredo could be used instead and allows the relay to be stateless and >distributed, and devolves to ordinary IPv6 when it is present. Yes, but Teredo is IPv6 specific, the world is not strictly IPv6 yet. And i= t's a system level solution, while SNIF works fine in a user space. > > >> It clearly has to speak HTTPS only. > > > I specified HTTP because PKCS#10 and X.509 are inherently secure to = be > > sent over a plain connection. > >Yes, but there are privacy concerns which will become a pain, so better >to just say HTTPS here. I respectfully disagree, still think HTTP is an easier answer for SNIF. The= problem with HTTPS is - SNIF relay (usually) routes https port to SNIF con= nectors, and does not serve it within the server. Having a dedicated hostna= me or an alternate port means than SNIF connectors need additional configur= ation options, or additional discovery protocols. On the other hand, HTTP a= llows to derive all API URLs deterministically from the CN. I addressed the possible security concerns in more details and amended the = Security section in the draft. > > > The best option is the manufacturer I believe. The manufacturer can > > have either their own SNIF server, or work with a trusted SaaS. This > > way it's zero setup for the end user, and doesn't need any > > infrastructure additions. > >Agreed, the manufacturer has to provision a credential. Yes I proposed some outlines in the security section, more detailed specs a= re probably better to describe in a separate draft. > > > Sure, elliptic curves are better, but some old school clients may ha= ve > > problems with them. It may make sense to not mention the recommended > > algorithm in the draft, and just to follow the CA's recommendations. > >ECDSA acceleration is pretty much ubiquitous, while RSA is not. Honestly I don't think acceleration is such a big deal, most of TLS job is = symmetric ciphers anyway. But I agree - it's better to follow the CA sugges= tions and industry practices. > > > I believe there's no security issue, as long as the CN entropy is su= fficient. > > > I specified the X-SNIF-CN: as mandatory, and text/plain body as an > > optional duplicate of it. To make it cleaner, I can remove the body > > from the specs and say the response body is to be ignored. > >If both are present, and they don't match, then there is confusion. >So just go with one. I think that it should actually be a JSON or CBOR pa= yload return. Agreed, I removed the response body from the draft, going with the header. > > >> They *aren't* what IANA would call "IP protocols", which would be t= hings > >> like > >> TCP, UDP, SCTP, ESP, ... > > >> Has IANA *already* registered port 7123 then? > > > It's not an IP protocol. It's a service that listens on TCP 7123, I > > registered with IANA based on a previous version of the document, > > before I turned it into an I-D. > >I think you should drop the "snif-*" sentence as it makes no sense. >You have already allocated TCP port 7123 to the SNIF *service*, so >that's great. It's actually called "Service Names" in IANA terminology, sorry for the con= fusion. I updated in the draft. > >-- >] Never tell me the odds! | ipv6 mesh networ= ks [ >] Michael Richardson, Sandelman Software Works | IoT architect= [ >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ > _______________________________________________ Secdispatch mailing list Secdispatch@ietf.org https://www.ietf.org/mailman/listinfo/secdispatch 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 Feb 23 07:19:39 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 2C3423A107C; Wed, 23 Feb 2022 07:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.089 X-Spam-Level: X-Spam-Status: No, score=-5.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_PDS_SHORTFWD_URISHRT_QP=0.01, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=commercebyte.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 wn4Z9lT1Uq4l; Wed, 23 Feb 2022 07:19:31 -0800 (PST) Received: from ocean1.commercebyte.com (ocean1.commercebyte.com [104.131.120.15]) (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 A82983A10A1; Wed, 23 Feb 2022 07:19:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=commercebyte.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:References:In-Reply-To:Subject:To:From:Date; bh=gylf0qLCWO02RwGeP4MufZ3pxzPO36jvnFI1QQhHtIU=; b=aEoNHJ9GqqG1w6YSJ01bDmmydkgx3u3+mKqzDdKVoRUr/vsGAgNokrxKhItg12Zx7ILYX7YYk/SiF+/tA9iY/v/po47yIsRabJ1SddDl/GDhjRM1M1uwrinLy7gDWGRNdRX3pZJzrtiHmmfqG2miy9ALg/wNsk5tTBX/sFKpBnI=; Received: from [47.204.174.73] (port=39052 helo=[127.0.0.1]) by ocean1.commercebyte.com with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1nMtQO-0000A1-SN; Wed, 23 Feb 2022 10:19:29 -0500 Received: from [206.81.2.95]:7120 (helo=[127.0.0.1]) by [192.168.254.152]:47738 (localhost) with VESmail ESMTP Proxy 1.59 (encrypt=FALSE mode=FALLBACK); Wed, 23 Feb 2022 10:19:28 -0500 Date: Wed, 23 Feb 2022 10:17:14 -0500 From: Jim Zubov To: secdispatch@ietf.org, Hannes Tschofenig , Jim Zubov , "secdispatch@ietf.org" , Michael Richardson , "iotops@ietf.org" , "anima@ietf.org" User-Agent: K-9 Mail for Android In-Reply-To: References: <0075B437-024A-4D84-ABD7-92FE8DAFA59F@commercebyte.com>, <1865.1644434146@localhost> <4026.1644516168@localhost> <685366A1-01F4-4788-B025-0F5F4CE7947F@commercebyte.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ocean1.commercebyte.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - commercebyte.com X-Get-Message-Sender-Via: ocean1.commercebyte.com: authenticated_id: jz@nixob.com Archived-At: Subject: Re: [Iotops] [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) 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, 23 Feb 2022 15:19:38 -0000 Thank You for your feedback Hannes, I addressed the comments below - On February 23, 2022 5:36:15 AM EST, Hannes Tschofenig wrote: >Hi all, > >Thanks for this contribution, Jim=2E > >Reading through the document I agree that the SUIB topic discussed in the= IOTOPS WG appears relevant=2E I also wonder whether the work in the DANISH= group (see https://datatracker=2Eietf=2Eorg/wg/danish/about/) is relevant= =2E Agreed about SUIB, not quite sure about DANISH=2E DANISH is about certific= ate based authentication and PKI extensions, while SNIF is about end-to-end= relayed trusted TLS that relies on the standard PKI=2E > >Regarding the use in IoT I have a question for my understanding=2E > >In a nutshell, you introduce a proxy that allocates a hostname and reques= ts a creation of a certificate on behalf of the IoT device=2E Correct, plus an e2e TLS relay=2E > >To get this to work you rely on three assumptions: >(1) There has to be a communication infrastructure that associates the "a= nonymous" hostname with a specific device and conveys these identifiers to = the relevant parties=2E Each device is configured with an initUrl pointing to a specific CA proxy = that allocates a random hostname (a CN to be more accurate), normally a sub= domain of a master domain that has a wildcard DNS record pointing to the CA= proxy=2E Example - the initUrl for public experimental use - https://snif=2Esnif=2E= xyz:4443 The allocated wildcard CN is a subdomain of the master domain snif=2Exyz >(2) You assume that a party that wants to contact the IoT device is able = to reach the device (i=2Ee=2E the IoT device is not behind a firewall or NA= T)=2E Both the IoT device and the client connect to the SNIF relay=2E The whole = purpose of SNIF is to be able to work from behind NAT / firewall /etc, and = it's been confirmed to work in pre-production=2E In fact I had a minor hick= up with Fortigate in the process of testing which has been resolved=2E There are simplified diagrams on https://snif=2Ehost to illustrate the con= cept=2E >(3) Someone operating IoT devices has to trust the proxy since it is easy= for the proxy to associate a hostname with a public key that was created b= y the proxy (rather than the end device)=2E This essentially allows the pro= xy to impersonating the IoT device=2E > >Is my understanding correct? Yes, I mentioned this vulnerability in the security section=2E The answer = is - watch the public TLS transparency logs, any party can do it=2E If any ov= erlapping CNs are found - the CA proxy is permanently compromised, - do not use random CA proxies owned by unknown parties=2E > >Ciao >Hannes Any further questions/suggestions are welcome=2E > >-----Original Message----- >From: Secdispatch On Behalf Of Jim Zubov >Sent: Friday, February 11, 2022 12:22 AM >To: secdispatch@ietf=2Eorg; Michael Richardson ;= Jim Zubov ; iotops@ietf=2Eorg; anima@ietf=2E= org >Subject: Re: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on= IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) > >Thanks for the feedback again, my comment are below=2E >I submitted a new version of the draft to reflect some changes=2E > >On February 10, 2022 1:02:48 PM EST, Michael Richardson wrote: >> >>Jim Zubov wrote: >> >> This was also on the IETF112 IOTOPS WG agenda: >> >> slides: >> >> https://datatracker=2Eietf=2Eorg/meeting/112/materials/slides-112= -iotops-suib-browsing-local-web-resources-in-a-secure-usable-manner-iot-dev= ice-configuration-as-a-special-case-00 >> >> video: https://youtu=2Ebe/OIlJrUvwDcI?t=3D1649 >> >> >> >> and we hope to return at IETF113=2E >> >> > Right, looks like SUIB is working on a similar problem=2E Thanks f= or >> > pointing this out=2E In particular, the "Sol #6 Device name DNS" s= lide >> > looks quite similar to SNIF CA Proxy (Section 3)=2E However, SUIB = pursues >> > bigger infrastructural goals such as changing the localhost TLS >> > connection policies (I totally agree and really appreciate the eff= ort), >> > while SNIF is a functioning solution within the existing >> > infrastructure, tested and proven to work in pre-production=2E >> >>The slides may be too vague=2E Changing the TLS policies is a possible >>solution, but probably an impractical one=2E Nevertheless, many people >>(not steeped in the arts, and often failling into the PHB category) >>think that it is an obvious solution, so we list it in order to explain = why it won't work=2E > >Yes, still sad that localhost slipped through the cracks when the origina= l security standards were written=2E > >> >> >> The SUIB problem addresses the challenge of connecting *locally* = to a >> >> device, >> >> and doing it securely=2E For this to be possible with RFC6125-DN= S-ID >> >> standard >> >> browser, we need a name for the device, and we need a way to tran= slate >> >> that >> >> name into a locally reachable IP address=2E >> >> >> >> The SNIF proposal does not quite solve the above problem=2E >> >> > In fact, I originally designed SNIF to solve this specific problem= - >> > local-to-local trusted TLS connections=2E >> >>Ah, very nice to know=2E >> >> > * Issue a wildcard cert through SNIF CA Proxy >> > (e=2Eg=2E CN=3D*=2Edomain=2Esnif=2Exyz), set a DNS record for >> > localhost=2Edomain=2Esnif=2Exyz to point to localhost's IPv4/v6, a= nd use >> > https://localhost=2Edomain=2Esnif=2Exyz (or other app protocol - i= maps >> > etc)=2E However, looks like some clients treat the localhost IP as >> > inherently unsecure, and issue a warning ever is the cert is perfe= ctly >> > valid=2E The option is still possible, but the applicability might= be >> > limited=2E >> >>The process we described at >> >>https://specs=2Emanysecured=2Eorg/suib/Solutions/dnsname-embedded-soluti= on >> >>also uses a wildcard cert, but has a magic authoritative DNS server >>that translates the left-most label into an A or AAAA record=2E It's >>rather a cute hack, but at least: >> a) it's cachable >> b) it could even be calculated locally, if one ignores DNSSEC=2E > >Yes, using a local network IP instead of a localhost IP is actually a sma= rt idea=2E >However, inlining the local IP in the hostname, as SUIB does, means you'l= l have to change the hostname in your client every time your network is cha= nged=2E >I have an thought for SNIF improvement - SNIF connector sends a SNIF DNS = command to set a dynamic DNS A/AAAA for a certain hostname within the CN wi= ldcard, and the CA proxy updates the DNS accordingly=2E This way the hostna= me can be permanent, but with dynamic DNS=2E >Another problem - most platforms won't let you bind to port < 1024 unless= you're a root=2E Might be ok for a device manufacturer, but is a potential= show stopper for any user space app=2E Relayed SNIF works around this prob= lem since the listening ports are on the relay=2E > > >> >> > * Another option is to override the IP routing rules=2E It is tota= lly >> > possible on iOS and Mac through a userspace VPN (only one VPN per >> > device though - beware of possible conflicts)=2E In fact I have a >> > functioning solution for it, in beta now - >> >>That doesn't really scale to many different domains=2E > >Totally agreed, I just mentioned that this option works for *some* cases,= tun/tap a is possible option too if you're a root=2E > >> >> >> Still, if SNIF is replacing a manufacturer proprietary call-home = protocol, >> >> there could be advantages from having well reviewed code bases, a= nd >> >> potentially an ecosystem of SNIF Providers that manufacturers cou= ld >> >> outsource >> >> >> to=2E Azure/Amazon/=2E=2E=2E could easily run such services=2E >> >> > I see two options - a SNIF server implemented by each vendor for t= heir >> > own devices/services, or a bigger SNIF SaaS implemented by a trust= ed >> > provider, used by vendors=2E >> >>Yes, but what's the financial motive for this provider? > >(1) For a vendor to run their own SNIF server: market as a true auditable= end-to-end for IoT devices they offer=2E >(2) For a vendor using SNIF SaaS: market as (1) backed by {TrustedBigName= } >(3) For a {TrustedBigName} to run SNIF SaaS: collect fees from (2) for us= ing their service and big name=2E > >As a matter of fact, SNIF relay is light on server resources=2E I've been= running it on a minimum DigitalOcean virtual server for months with more t= han a dozen connectors, the server load is a fraction of a percent=2E Of = course if somebody connects IoT cameras they can generate some traffic, but= IoT vendors already handle it through their proprietary relays=2E > >> >> >> SNIF seems very much IPv4 NAT44 focused, and it could benefit fro= m some >> >> understanding of IPv6 and IPv6-over-IPv4 technologies, >> particularly >> >> >> Teredo=2E >> >> > SNIF is not exactly focused on v4, it works fine with v6 as well= =2E It's >> > designed to work around NAT, that's true=2E However, IPv6 networks= may >> > pose issues too - firewalls etc, which will prevent to directly ac= cept >> > incoming TCP on IPv6 address=2E >> >>Teredo could be used instead and allows the relay to be stateless and >>distributed, and devolves to ordinary IPv6 when it is present=2E > >Yes, but Teredo is IPv6 specific, the world is not strictly IPv6 yet=2E A= nd it's a system level solution, while SNIF works fine in a user space=2E > >> >> >> It clearly has to speak HTTPS only=2E >> >> > I specified HTTP because PKCS#10 and X=2E509 are inherently secure= to be >> > sent over a plain connection=2E >> >>Yes, but there are privacy concerns which will become a pain, so better >>to just say HTTPS here=2E > >I respectfully disagree, still think HTTP is an easier answer for SNIF=2E= The problem with HTTPS is - SNIF relay (usually) routes https port to SNIF= connectors, and does not serve it within the server=2E Having a dedicated = hostname or an alternate port means than SNIF connectors need additional co= nfiguration options, or additional discovery protocols=2E On the other hand= , HTTP allows to derive all API URLs deterministically from the CN=2E >I addressed the possible security concerns in more details and amended th= e Security section in the draft=2E > > >> >> > The best option is the manufacturer I believe=2E The manufacturer = can >> > have either their own SNIF server, or work with a trusted SaaS=2E = This >> > way it's zero setup for the end user, and doesn't need any >> > infrastructure additions=2E >> >>Agreed, the manufacturer has to provision a credential=2E > >Yes I proposed some outlines in the security section, more detailed specs= are probably better to describe in a separate draft=2E > >> >> > Sure, elliptic curves are better, but some old school clients may = have >> > problems with them=2E It may make sense to not mention the recomme= nded >> > algorithm in the draft, and just to follow the CA's recommendation= s=2E >> >>ECDSA acceleration is pretty much ubiquitous, while RSA is not=2E > >Honestly I don't think acceleration is such a big deal, most of TLS job i= s symmetric ciphers anyway=2E But I agree - it's better to follow the CA su= ggestions and industry practices=2E > >> >> > I believe there's no security issue, as long as the CN entropy is = sufficient=2E >> >> > I specified the X-SNIF-CN: as mandatory, and text/plain body as an >> > optional duplicate of it=2E To make it cleaner, I can remove the b= ody >> > from the specs and say the response body is to be ignored=2E >> >>If both are present, and they don't match, then there is confusion=2E >>So just go with one=2E I think that it should actually be a JSON or CBO= R payload return=2E > >Agreed, I removed the response body from the draft, going with the header= =2E > > >> >> >> They *aren't* what IANA would call "IP protocols", which would be= things >> >> like >> >> TCP, UDP, SCTP, ESP, =2E=2E=2E >> >> >> Has IANA *already* registered port 7123 then? >> >> > It's not an IP protocol=2E It's a service that listens on TCP 7123= , I >> > registered with IANA based on a previous version of the document, >> > before I turned it into an I-D=2E >> >>I think you should drop the "snif-*" sentence as it makes no sense=2E >>You have already allocated TCP port 7123 to the SNIF *service*, so >>that's great=2E > >It's actually called "Service Names" in IANA terminology, sorry for the c= onfusion=2E I updated in the draft=2E > > > >> >>-- >>] Never tell me the odds! | ipv6 mesh netw= orks [ >>] Michael Richardson, Sandelman Software Works | IoT archite= ct [ >>] mcr@sandelman=2Eca http://www=2Esandelman=2Eca/ | ruby o= n rails [ >> > >_______________________________________________ >Secdispatch mailing list >Secdispatch@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/secdispatch >IMPORTANT NOTICE: The contents of this email and any attachments are conf= idential and may also be privileged=2E If you are not the intended recipien= t, please 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=2E Thank you=2E > >_______________________________________________ >Secdispatch mailing list >Secdispatch@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/secdispatch From nobody Thu Feb 24 02:38:29 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 F260C3A08D5; Thu, 24 Feb 2022 02:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_OTHER_BAD_TLD=1.999, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=TvpxFw+A; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=TvpxFw+A 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 CbcU5LJCN0xR; Thu, 24 Feb 2022 02:38:06 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on060c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::60c]) (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 9F89E3A091B; Thu, 24 Feb 2022 02:38:05 -0800 (PST) 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=wEiLMq+XZ38XnKvthhi7htt+0g5xsSPH5jAE4tyDc0k=; b=TvpxFw+AZWGqkzr6hAE7GYwbg67FW/S4lVX2ZyMi5+8LPLa27sI9TFs0rd+4tCi1/zb6e/CpMroGjUC+kY0nA8IFr1+3K3eHS9BVQMfTuZ0laotAITG22bXpVPls05tBNHN7DwMKdKaGSVty6BRnCq68fSw4Q6pXDSiv3ZC74gg= Received: from AS9PR06CA0246.eurprd06.prod.outlook.com (2603:10a6:20b:45f::12) by DB9PR08MB6649.eurprd08.prod.outlook.com (2603:10a6:10:26c::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.22; Thu, 24 Feb 2022 10:37:57 +0000 Received: from VE1EUR03FT029.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:45f:cafe::14) by AS9PR06CA0246.outlook.office365.com (2603:10a6:20b:45f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.22 via Frontend Transport; Thu, 24 Feb 2022 10:37:57 +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 VE1EUR03FT029.mail.protection.outlook.com (10.152.18.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.22 via Frontend Transport; Thu, 24 Feb 2022 10:37:55 +0000 Received: ("Tessian outbound 63bb5eb69ee8:v113"); Thu, 24 Feb 2022 10:37:55 +0000 X-CR-MTA-TID: 64aa7808 Received: from e0c69bcfc1a0.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 1A880ABE-CFDB-4799-9ACC-49301AD68292.1; Thu, 24 Feb 2022 10:37:49 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e0c69bcfc1a0.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 24 Feb 2022 10:37:49 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nHDFVQOQukcd78Uv6gYWHmwZd+VjO/ojt2wsqkh3PWOtSMK3Q/ixTfvp2eqI4+pnd4w6d4n2gWCu7rLjq2DWcn/QG/NFkwBwc3SHgpURYpPj3Cp7u9CPjo5as1K8pdhpooAqMOMKSaig3/Y8M9BYtf0FYzMYxTCClS90+TwQ585Z2khgYF21cXBtxwLlZOiWPduROW0RaJKdUGYxHYjuzNBZXEi2wserxC1obPjhfW3PQ3MNALW9p807KhS1xCBRF6uIjYO/GhHU5wN10bgg55x2OuWKzwV2zhT9/R9fyk66OFHoPN6XzajjJNtpNyRe2/arT312glL3wQzlz/bOfA== 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=wEiLMq+XZ38XnKvthhi7htt+0g5xsSPH5jAE4tyDc0k=; b=Pw8yjGIA3BQ14erafMNIVrtTsOcD5FO6lxwtODSfSuCJ/9y/r9JsUFRDZJYZNj/0g2c5XLiUvlFBZu9e4pqYbCfYD1TXCvPLDBXe6XINW6WaX8BWWWuH2+XepcfZ6sStbSTdH+x8KRpnPJSy6VVxvV3BrPuS5dJ9aro23km5fhmzipJusXSncEk41NRlNn9v++KvB+x70wC5drkfwj8yWzRq/xs/pce1e1yVP/W2joQl1ETLpAN5V8QQQUQzoHvJxPJWRKFurHvQ2sGek6L92fXJTSTvRCE1dDKH2Y46xyRq7Vjc7EzC8tI2zqcwHvMMgxPsfHgFjykc9g62oiR23Q== 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=wEiLMq+XZ38XnKvthhi7htt+0g5xsSPH5jAE4tyDc0k=; b=TvpxFw+AZWGqkzr6hAE7GYwbg67FW/S4lVX2ZyMi5+8LPLa27sI9TFs0rd+4tCi1/zb6e/CpMroGjUC+kY0nA8IFr1+3K3eHS9BVQMfTuZ0laotAITG22bXpVPls05tBNHN7DwMKdKaGSVty6BRnCq68fSw4Q6pXDSiv3ZC74gg= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by VI1PR08MB2829.eurprd08.prod.outlook.com (2603:10a6:802:22::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.21; Thu, 24 Feb 2022 10:37:46 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::b478:3f3d:2464:65c8]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::b478:3f3d:2464:65c8%5]) with mapi id 15.20.5017.024; Thu, 24 Feb 2022 10:37:46 +0000 From: Hannes Tschofenig To: Jim Zubov , "secdispatch@ietf.org" , "secdispatch@ietf.org" , Michael Richardson , "iotops@ietf.org" , "anima@ietf.org" Thread-Topic: [Iotops] [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) Thread-Index: AQHYHtVKop3offyr+0q9saoG3HE46Kyg/hiwgABVHACAAAMKAA== Date: Thu, 24 Feb 2022 10:37:46 +0000 Message-ID: References: <0075B437-024A-4D84-ABD7-92FE8DAFA59F@commercebyte.com>, <1865.1644434146@localhost> <4026.1644516168@localhost> <685366A1-01F4-4788-B025-0F5F4CE7947F@commercebyte.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: BC58F46847054545A6C12BA3C67F46E6.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: 151980da-76a8-4058-c1c0-08d9f781b809 x-ms-traffictypediagnostic: VI1PR08MB2829:EE_|VE1EUR03FT029:EE_|DB9PR08MB6649: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: v1OPT+x7/5jt/G7RAOSpRdk7JTmh83xx+z8QGU5m0nXdu4ZoRwRBy9zigT3NTHZmhdoIbazV/aZuxQFkLkt2lfyQLL3L8EXBzxcwcqNQMQ8PhkGxOvyjimeOt+1vu7q51Zl+uKZxHAc1eC4j7YJ41zuF2UqDNoslEAxFBhCsdw7nzE2nGatXCWnxjFWtzRn3mM98yvnR/6PvVjlE12PMw7N2MWxGWRt5mf4ZfNHZvWloy/COR9w516RDbuFsRPcjtiZbFzfjtIG5AtsKXzBTqPeoFWwSOistzxIHciHmtbPU5OqowmJelmCP50YVP6aLYwkj6puWfBA4xIro5ftC9BdQUv4qK+5gdXT6Jq3LUMkF0bNbHuvcvCC2LWbEl1Uk2WUJq+6cN2uUHoISTbhP1MTFn4CnpAUaX4xdWJ6JuW47QL7vTAnPaNgKX2Moc/B0TQaGgabDcFCs7oV6gl9bxXtSQahuxJ1zBRaD7F32O/Bwo+QDwiAsqeuzyrZk96Lhf0ZuJyErlF1GfyTbgezyxtgtPiRQkCIVgE+EEMTcHe8fU339wW3KgJ+dsB2acWc0DY+H7e8FWn3aF7hooRgv5mbzSgKjzwJESHDbuZJHxc1R0dQ+PNOgr8iGiYfHcBykDPDGz7gE4xc6y9RL/jPASC25f2sJBbsT8SBVb+6jA5JchyAucIxg0vuvM1SqVOesPUvuj1IQ+7FOHt+GTHtcyeBlR0GWAZ1e1wfxLpMesHJCU5oQtZLL5d75aT4eGnjJhv/HICZjntnyTkxsxF/Zo1GdbrhqtMYEgW2fvzefOFgAj4QsF2oDFWCJM8F8JJKlovz/nWsSifif09oVUeafXcEBAxtO1uKyHCeQ5Tb9A5Q= 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)(86362001)(55016003)(71200400001)(76116006)(6506007)(53546011)(8936002)(66946007)(66446008)(30864003)(66574015)(9686003)(2906002)(122000001)(7696005)(38070700005)(66556008)(52536014)(66476007)(64756008)(8676002)(38100700002)(26005)(83380400001)(316002)(110136005)(33656002)(966005)(5660300002)(186003)(508600001)(69594002); 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: VI1PR08MB2829 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: VE1EUR03FT029.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 33c9a8ca-bc0e-4957-48be-08d9f781b261 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: piG5beYSZBw1Xr9jPbHIJBeb8ZsOt4Bl1kWnkAMg7rbYgrcK9LN/cS8xeDUxjsQvcsUOaDEYrK46Qg2B9p6aWRCzdc+fQiX8WjyHwvdHuIRCFbhRP5rcCG20zwPnO8BVE35bJcIyrN45e/ezebpkgJqUPFY5d1tE/f2aBj47IvvmoZX5/LqngFmlK3js2eXQTukzMlFuiitlxfPNdU4lazWi89VwPddNo5AoagyH2EDvG2HzKdqk2RdMd0vn5qw7Xlys0hGJ0YoAv3LQ1pZso+e2VfA4lbkhwF/rDQTVoVDxmgOkkXmkh+mQIyaGLQoOnpyd5rNVze12RQiP+rfL5ZqI/WKkvEg4ZR3EDJY3H52J3UsARi9TyYDd1ITb0cQKugMOFq31hIbhPvJvvJeB6vFKI2oQhuXVkBAyWZPQcI1QG6AG3iv7jCSHicLSoxyqXk/k9Tw+qSv7rR72HJdaoqX1E54WYSo5K9USKq0gji8fRoCHtQZNG2W5mgJNxtUd2+R7MKJSxY39Mu7DE40jgT+inxCkq+ir55DEU3p7P0R0HsPD0ZhB3iNrT0BX5lzvvWEFuqK61+DExOrqfbtrMCYGBZ9pZZiKpRAkWkMOl6ITCywb//kWw5bNl1uy7QhUYfKcPQLnxYwpYKEit6kSLJhnIoMddbV4skqrFtZBtaKBNlMbC8pWW8toHh2YbeVHXLAxK/9dh1IsNbLvY9oi4j32/PJhj816WVQkTDch3RMTxZa4Q8MoSwVBhl2wbNtnQUpnLFo9xlq3t/36XXaI/QFpNr28CmJXlt2T+XhwnRVf+jjNQaRnwv8A4fQHbj8e 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)(36840700001)(46966006)(40470700004)(70586007)(70206006)(2906002)(9686003)(8676002)(47076005)(508600001)(52536014)(8936002)(450100002)(36860700001)(966005)(40460700003)(86362001)(186003)(83380400001)(30864003)(316002)(53546011)(26005)(6506007)(55016003)(33656002)(356005)(5660300002)(336012)(66574015)(82310400004)(81166007)(110136005)(7696005)(69594002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Feb 2022 10:37:55.7943 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 151980da-76a8-4058-c1c0-08d9f781b809 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: VE1EUR03FT029.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB6649 Archived-At: Subject: Re: [Iotops] [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) 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, 24 Feb 2022 10:38:11 -0000 Hi Jim, Thanks for the quick response. The link to your website is helpful. I now u= nderstood that you would also relay the communication through the proxy, wh= ich deals with the IoT device being behind a NAT and/or firewall if the IoT= device keeps the connection alive. I wonder whether you have considered to re-use an existing device managemen= t solutions since those is widely deployed today? Ciao Hannes -----Original Message----- From: Iotops On Behalf Of Jim Zubov Sent: Wednesday, February 23, 2022 4:17 PM To: secdispatch@ietf.org; Hannes Tschofenig ; Ji= m Zubov ; secdispatch@ietf.org; Michael Richard= son ; iotops@ietf.org; anima@ietf.org Subject: Re: [Iotops] [Secdispatch] I-D: Deploying Publicly Trusted TLS Ser= vers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) Thank You for your feedback Hannes, I addressed the comments below - On February 23, 2022 5:36:15 AM EST, Hannes Tschofenig wrote: >Hi all, > >Thanks for this contribution, Jim. > >Reading through the document I agree that the SUIB topic discussed in the = IOTOPS WG appears relevant. I also wonder whether the work in the DANISH gr= oup (see https://datatracker.ietf.org/wg/danish/about/) is relevant. Agreed about SUIB, not quite sure about DANISH. DANISH is about certificate= based authentication and PKI extensions, while SNIF is about end-to-end re= layed trusted TLS that relies on the standard PKI. > >Regarding the use in IoT I have a question for my understanding. > >In a nutshell, you introduce a proxy that allocates a hostname and request= s a creation of a certificate on behalf of the IoT device. Correct, plus an e2e TLS relay. > >To get this to work you rely on three assumptions: >(1) There has to be a communication infrastructure that associates the "an= onymous" hostname with a specific device and conveys these identifiers to t= he relevant parties. Each device is configured with an initUrl pointing to a specific CA proxy t= hat allocates a random hostname (a CN to be more accurate), normally a subd= omain of a master domain that has a wildcard DNS record pointing to the CA = proxy. Example - the initUrl for public experimental use - https://snif.snif.xyz:4= 443 The allocated wildcard CN is a subdomain of the master domain snif.xyz >(2) You assume that a party that wants to contact the IoT device is able t= o reach the device (i.e. the IoT device is not behind a firewall or NAT). Both the IoT device and the client connect to the SNIF relay. The whole pur= pose of SNIF is to be able to work from behind NAT / firewall /etc, and it'= s been confirmed to work in pre-production. In fact I had a minor hickup wi= th Fortigate in the process of testing which has been resolved. There are simplified diagrams on https://snif.host to illustrate the concep= t. >(3) Someone operating IoT devices has to trust the proxy since it is easy = for the proxy to associate a hostname with a public key that was created by= the proxy (rather than the end device). This essentially allows the proxy = to impersonating the IoT device. > >Is my understanding correct? Yes, I mentioned this vulnerability in the security section. The answer is - watch the public TLS transparency logs, any party can do it. If any overl= apping CNs are found - the CA proxy is permanently compromised, - do not use random CA proxies owned by unknown parties. > >Ciao >Hannes Any further questions/suggestions are welcome. > >-----Original Message----- >From: Secdispatch On Behalf Of Jim Zubov >Sent: Friday, February 11, 2022 12:22 AM >To: secdispatch@ietf.org; Michael Richardson ; >Jim Zubov ; iotops@ietf.org; anima@ietf.org >Subject: Re: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers >on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) > >Thanks for the feedback again, my comment are below. >I submitted a new version of the draft to reflect some changes. > >On February 10, 2022 1:02:48 PM EST, Michael Richardson wrote: >> >>Jim Zubov wrote: >> >> This was also on the IETF112 IOTOPS WG agenda: >> >> slides: >> >> https://datatracker.ietf.org/meeting/112/materials/slides-112-ioto= ps-suib-browsing-local-web-resources-in-a-secure-usable-manner-iot-device-c= onfiguration-as-a-special-case-00 >> >> video: https://youtu.be/OIlJrUvwDcI?t=3D1649 >> >> >> >> and we hope to return at IETF113. >> >> > Right, looks like SUIB is working on a similar problem. Thanks for >> > pointing this out. In particular, the "Sol #6 Device name DNS" slid= e >> > looks quite similar to SNIF CA Proxy (Section 3). However, SUIB pur= sues >> > bigger infrastructural goals such as changing the localhost TLS >> > connection policies (I totally agree and really appreciate the effo= rt), >> > while SNIF is a functioning solution within the existing >> > infrastructure, tested and proven to work in pre-production. >> >>The slides may be too vague. Changing the TLS policies is a possible >>solution, but probably an impractical one. Nevertheless, many people >>(not steeped in the arts, and often failling into the PHB category) >>think that it is an obvious solution, so we list it in order to explain w= hy it won't work. > >Yes, still sad that localhost slipped through the cracks when the original= security standards were written. > >> >> >> The SUIB problem addresses the challenge of connecting *locally* t= o a >> >> device, >> >> and doing it securely. For this to be possible with RFC6125-DNS-I= D >> >> standard >> >> browser, we need a name for the device, and we need a way to trans= late >> >> that >> >> name into a locally reachable IP address. >> >> >> >> The SNIF proposal does not quite solve the above problem. >> >> > In fact, I originally designed SNIF to solve this specific problem = - >> > local-to-local trusted TLS connections. >> >>Ah, very nice to know. >> >> > * Issue a wildcard cert through SNIF CA Proxy >> > (e.g. CN=3D*.domain.snif.xyz), set a DNS record for >> > localhost.domain.snif.xyz to point to localhost's IPv4/v6, and use >> > https://localhost.domain.snif.xyz (or other app protocol - imaps >> > etc). However, looks like some clients treat the localhost IP as >> > inherently unsecure, and issue a warning ever is the cert is perfec= tly >> > valid. The option is still possible, but the applicability might be >> > limited. >> >>The process we described at >> >>https://specs.manysecured.org/suib/Solutions/dnsname-embedded-solution >> >>also uses a wildcard cert, but has a magic authoritative DNS server >>that translates the left-most label into an A or AAAA record. It's >>rather a cute hack, but at least: >> a) it's cachable >> b) it could even be calculated locally, if one ignores DNSSEC. > >Yes, using a local network IP instead of a localhost IP is actually a smar= t idea. >However, inlining the local IP in the hostname, as SUIB does, means you'll= have to change the hostname in your client every time your network is chan= ged. >I have an thought for SNIF improvement - SNIF connector sends a SNIF DNS c= ommand to set a dynamic DNS A/AAAA for a certain hostname within the CN wil= dcard, and the CA proxy updates the DNS accordingly. This way the hostname = can be permanent, but with dynamic DNS. >Another problem - most platforms won't let you bind to port < 1024 unless = you're a root. Might be ok for a device manufacturer, but is a potential sh= ow stopper for any user space app. Relayed SNIF works around this problem s= ince the listening ports are on the relay. > > >> >> > * Another option is to override the IP routing rules. It is totally >> > possible on iOS and Mac through a userspace VPN (only one VPN per >> > device though - beware of possible conflicts). In fact I have a >> > functioning solution for it, in beta now - >> >>That doesn't really scale to many different domains. > >Totally agreed, I just mentioned that this option works for *some* cases, = tun/tap a is possible option too if you're a root. > >> >> >> Still, if SNIF is replacing a manufacturer proprietary call-home p= rotocol, >> >> there could be advantages from having well reviewed code bases, an= d >> >> potentially an ecosystem of SNIF Providers that manufacturers coul= d >> >> outsource >> >> >> to. Azure/Amazon/... could easily run such services. >> >> > I see two options - a SNIF server implemented by each vendor for th= eir >> > own devices/services, or a bigger SNIF SaaS implemented by a truste= d >> > provider, used by vendors. >> >>Yes, but what's the financial motive for this provider? > >(1) For a vendor to run their own SNIF server: market as a true auditable = end-to-end for IoT devices they offer. >(2) For a vendor using SNIF SaaS: market as (1) backed by >{TrustedBigName} >(3) For a {TrustedBigName} to run SNIF SaaS: collect fees from (2) for usi= ng their service and big name. > >As a matter of fact, SNIF relay is light on server resources. I've been ru= nning it on a minimum DigitalOcean virtual server for months with more than= a dozen connectors, the server load is a fraction of a percent. Of cours= e if somebody connects IoT cameras they can generate some traffic, but IoT = vendors already handle it through their proprietary relays. > >> >> >> SNIF seems very much IPv4 NAT44 focused, and it could benefit from= some >> >> understanding of IPv6 and IPv6-over-IPv4 technologies, >> particularly >> >> >> Teredo. >> >> > SNIF is not exactly focused on v4, it works fine with v6 as well. I= t's >> > designed to work around NAT, that's true. However, IPv6 networks ma= y >> > pose issues too - firewalls etc, which will prevent to directly acc= ept >> > incoming TCP on IPv6 address. >> >>Teredo could be used instead and allows the relay to be stateless and >>distributed, and devolves to ordinary IPv6 when it is present. > >Yes, but Teredo is IPv6 specific, the world is not strictly IPv6 yet. And = it's a system level solution, while SNIF works fine in a user space. > >> >> >> It clearly has to speak HTTPS only. >> >> > I specified HTTP because PKCS#10 and X.509 are inherently secure to= be >> > sent over a plain connection. >> >>Yes, but there are privacy concerns which will become a pain, so >>better to just say HTTPS here. > >I respectfully disagree, still think HTTP is an easier answer for SNIF. Th= e problem with HTTPS is - SNIF relay (usually) routes https port to SNIF co= nnectors, and does not serve it within the server. Having a dedicated hostn= ame or an alternate port means than SNIF connectors need additional configu= ration options, or additional discovery protocols. On the other hand, HTTP = allows to derive all API URLs deterministically from the CN. >I addressed the possible security concerns in more details and amended the= Security section in the draft. > > >> >> > The best option is the manufacturer I believe. The manufacturer can >> > have either their own SNIF server, or work with a trusted SaaS. Thi= s >> > way it's zero setup for the end user, and doesn't need any >> > infrastructure additions. >> >>Agreed, the manufacturer has to provision a credential. > >Yes I proposed some outlines in the security section, more detailed specs = are probably better to describe in a separate draft. > >> >> > Sure, elliptic curves are better, but some old school clients may h= ave >> > problems with them. It may make sense to not mention the recommende= d >> > algorithm in the draft, and just to follow the CA's recommendations= . >> >>ECDSA acceleration is pretty much ubiquitous, while RSA is not. > >Honestly I don't think acceleration is such a big deal, most of TLS job is= symmetric ciphers anyway. But I agree - it's better to follow the CA sugge= stions and industry practices. > >> >> > I believe there's no security issue, as long as the CN entropy is s= ufficient. >> >> > I specified the X-SNIF-CN: as mandatory, and text/plain body as an >> > optional duplicate of it. To make it cleaner, I can remove the body >> > from the specs and say the response body is to be ignored. >> >>If both are present, and they don't match, then there is confusion. >>So just go with one. I think that it should actually be a JSON or CBOR p= ayload return. > >Agreed, I removed the response body from the draft, going with the header. > > >> >> >> They *aren't* what IANA would call "IP protocols", which would be = things >> >> like >> >> TCP, UDP, SCTP, ESP, ... >> >> >> Has IANA *already* registered port 7123 then? >> >> > It's not an IP protocol. It's a service that listens on TCP 7123, I >> > registered with IANA based on a previous version of the document, >> > before I turned it into an I-D. >> >>I think you should drop the "snif-*" sentence as it makes no sense. >>You have already allocated TCP port 7123 to the SNIF *service*, so >>that's great. > >It's actually called "Service Names" in IANA terminology, sorry for the co= nfusion. I updated in the draft. > > > >> >>-- >>] Never tell me the odds! | ipv6 mesh netwo= rks [ >>] Michael Richardson, Sandelman Software Works | IoT architec= t [ >>] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ >> > >_______________________________________________ >Secdispatch mailing list >Secdispatch@ietf.org >https://www.ietf.org/mailman/listinfo/secdispatch >IMPORTANT NOTICE: The contents of this email and any attachments are confi= dential and may also be privileged. If you are not the intended recipient, = please notify the sender immediately and do not disclose the contents to an= y other person, use it for any purpose, or store or copy the information in= any medium. Thank you. > >_______________________________________________ >Secdispatch mailing list >Secdispatch@ietf.org >https://www.ietf.org/mailman/listinfo/secdispatch -- Iotops mailing list Iotops@ietf.org https://www.ietf.org/mailman/listinfo/iotops 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 Thu Feb 24 06:43:17 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 7782B3A07E4; Thu, 24 Feb 2022 06:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.087 X-Spam-Level: X-Spam-Status: No, score=-0.087 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, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_PDS_SHORTFWD_URISHRT_QP=0.01, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=commercebyte.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 5gWc5lx7Ec4W; Thu, 24 Feb 2022 06:43:09 -0800 (PST) Received: from ocean1.commercebyte.com (ocean1.commercebyte.com [104.131.120.15]) (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 2DEA73A07B4; Thu, 24 Feb 2022 06:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=commercebyte.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:References:In-Reply-To:Subject:To:From:Date; bh=gMdPrUnkbVgGlXX2jms2C1zSwi852kURqgZVSMNTkxA=; b=e4AWBZc5OaFJNGYwDuhzykvqb7eJrT7NMBiytJjo+MsWVMVAzrIoIv2FoJ4/TELlWjQbzdwhbyQhNWvnSsWk1paEF92rmhbpgIz4pU7JNNwMWYSIC2Y9Q6aTUzTbGAO6u94BOetSTTI5wvfRoqkqpQ70+PCKKXnVzmTmjS/CEH8=; Received: from [47.204.174.73] (port=43424 helo=[127.0.0.1]) by ocean1.commercebyte.com with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1nNFKk-0008Oa-Kc; Thu, 24 Feb 2022 09:43:07 -0500 Received: from [206.81.2.95]:7120 (helo=[127.0.0.1]) by [192.168.254.152]:39110 (localhost) with VESmail ESMTP Proxy 1.59 (encrypt=FALSE mode=FALLBACK); Thu, 24 Feb 2022 09:43:06 -0500 Date: Thu, 24 Feb 2022 09:42:57 -0500 From: Jim Zubov To: Hannes Tschofenig , Jim Zubov , "secdispatch@ietf.org" , Michael Richardson , "iotops@ietf.org" , "anima@ietf.org" User-Agent: K-9 Mail for Android In-Reply-To: References: <0075B437-024A-4D84-ABD7-92FE8DAFA59F@commercebyte.com>, <1865.1644434146@localhost> <4026.1644516168@localhost> <685366A1-01F4-4788-B025-0F5F4CE7947F@commercebyte.com> Message-ID: <665685D3-B9AA-4A5E-B5B0-33D313A40716@commercebyte.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----FG15COL8L8O8PLJUN0S11AF88ICT5W Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ocean1.commercebyte.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - commercebyte.com X-Get-Message-Sender-Via: ocean1.commercebyte.com: authenticated_id: jz@nixob.com Archived-At: Subject: Re: [Iotops] [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) 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, 24 Feb 2022 14:43:15 -0000 ------FG15COL8L8O8PLJUN0S11AF88ICT5W Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Hannes, I just want to emphasize once again that the relay is end to end TLS=2E There are some IoT management solutions on the market, both open source an= d proprietary, but as far as I can tell none of them fully follows the end = to end paradigm=2E I believe it's worth having a universal cross-vendor sol= ution that handles SNIF device onboarding, maintains the credentials in a l= ocal secure storage, and consolidates https based management interface host= ed by individual devices through SNIF=2E The requirements for such solution is a topic for a separate draft, althou= gh I already outlined the possible secure onboarding process in the securit= y section=2E On February 24, 2022 5:37:46 AM EST, Hannes Tschofenig wrote: >Hi Jim, > >Thanks for the quick response=2E The link to your website is helpful=2E I= now understood that you would also relay the communication through the pro= xy, which deals with the IoT device being behind a NAT and/or firewall if t= he IoT device keeps the connection alive=2E > >I wonder whether you have considered to re-use an existing device managem= ent solutions since those is widely deployed today? > >Ciao >Hannes > >-----Original Message----- >From: Iotops On Behalf Of Jim Zubov >Sent: Wednesday, February 23, 2022 4:17 PM >To: secdispatch@ietf=2Eorg; Hannes Tschofenig ; Jim Zubov ; secdispatch@ietf=2Eorg; Mic= hael Richardson ; iotops@ietf=2Eorg; anima@ietf=2E= org >Subject: Re: [Iotops] [Secdispatch] I-D: Deploying Publicly Trusted TLS S= ervers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) > >Thank You for your feedback Hannes, I addressed the comments below - > >On February 23, 2022 5:36:15 AM EST, Hannes Tschofenig wrote: >>Hi all, >> >>Thanks for this contribution, Jim=2E >> >>Reading through the document I agree that the SUIB topic discussed in th= e IOTOPS WG appears relevant=2E I also wonder whether the work in the DANIS= H group (see https://datatracker=2Eietf=2Eorg/wg/danish/about/) is relevant= =2E > >Agreed about SUIB, not quite sure about DANISH=2E DANISH is about certifi= cate based authentication and PKI extensions, while SNIF is about end-to-en= d relayed trusted TLS that relies on the standard PKI=2E > >> >>Regarding the use in IoT I have a question for my understanding=2E >> >>In a nutshell, you introduce a proxy that allocates a hostname and reque= sts a creation of a certificate on behalf of the IoT device=2E > >Correct, plus an e2e TLS relay=2E >> >>To get this to work you rely on three assumptions: >>(1) There has to be a communication infrastructure that associates the "= anonymous" hostname with a specific device and conveys these identifiers to= the relevant parties=2E > >Each device is configured with an initUrl pointing to a specific CA proxy= that allocates a random hostname (a CN to be more accurate), normally a su= bdomain of a master domain that has a wildcard DNS record pointing to the C= A proxy=2E >Example - the initUrl for public experimental use - https://snif=2Esnif= =2Exyz:4443 The allocated wildcard CN is a subdomain of the master domain s= nif=2Exyz > > >>(2) You assume that a party that wants to contact the IoT device is able= to reach the device (i=2Ee=2E the IoT device is not behind a firewall or N= AT)=2E > >Both the IoT device and the client connect to the SNIF relay=2E The whole= purpose of SNIF is to be able to work from behind NAT / firewall /etc, and= it's been confirmed to work in pre-production=2E In fact I had a minor hic= kup with Fortigate in the process of testing which has been resolved=2E >There are simplified diagrams on https://snif=2Ehost to illustrate the co= ncept=2E > > >>(3) Someone operating IoT devices has to trust the proxy since it is eas= y for the proxy to associate a hostname with a public key that was created = by the proxy (rather than the end device)=2E This essentially allows the pr= oxy to impersonating the IoT device=2E >> >>Is my understanding correct? > >Yes, I mentioned this vulnerability in the security section=2E The answer= is >- watch the public TLS transparency logs, any party can do it=2E If any o= verlapping CNs are found - the CA proxy is permanently compromised, >- do not use random CA proxies owned by unknown parties=2E > > >> >>Ciao >>Hannes > >Any further questions/suggestions are welcome=2E > >> >>-----Original Message----- >>From: Secdispatch On Behalf Of Jim Zubo= v >>Sent: Friday, February 11, 2022 12:22 AM >>To: secdispatch@ietf=2Eorg; Michael Richardson = ; >>Jim Zubov ; iotops@ietf=2Eorg; anima@ietf= =2Eorg >>Subject: Re: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers >>on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) >> >>Thanks for the feedback again, my comment are below=2E >>I submitted a new version of the draft to reflect some changes=2E >> >>On February 10, 2022 1:02:48 PM EST, Michael Richardson wrote: >>> >>>Jim Zubov wrote: >>> >> This was also on the IETF112 IOTOPS WG agenda: >>> >> slides: >>> >> https://datatracker=2Eietf=2Eorg/meeting/112/materials/slides-11= 2-iotops-suib-browsing-local-web-resources-in-a-secure-usable-manner-iot-de= vice-configuration-as-a-special-case-00 >>> >> video: https://youtu=2Ebe/OIlJrUvwDcI?t=3D1649 >>> >> >>> >> and we hope to return at IETF113=2E >>> >>> > Right, looks like SUIB is working on a similar problem=2E Thanks = for >>> > pointing this out=2E In particular, the "Sol #6 Device name DNS" = slide >>> > looks quite similar to SNIF CA Proxy (Section 3)=2E However, SUIB= pursues >>> > bigger infrastructural goals such as changing the localhost TLS >>> > connection policies (I totally agree and really appreciate the ef= fort), >>> > while SNIF is a functioning solution within the existing >>> > infrastructure, tested and proven to work in pre-production=2E >>> >>>The slides may be too vague=2E Changing the TLS policies is a possible >>>solution, but probably an impractical one=2E Nevertheless, many people >>>(not steeped in the arts, and often failling into the PHB category) >>>think that it is an obvious solution, so we list it in order to explain= why it won't work=2E >> >>Yes, still sad that localhost slipped through the cracks when the origin= al security standards were written=2E >> >>> >>> >> The SUIB problem addresses the challenge of connecting *locally*= to a >>> >> device, >>> >> and doing it securely=2E For this to be possible with RFC6125-D= NS-ID >>> >> standard >>> >> browser, we need a name for the device, and we need a way to tra= nslate >>> >> that >>> >> name into a locally reachable IP address=2E >>> >> >>> >> The SNIF proposal does not quite solve the above problem=2E >>> >>> > In fact, I originally designed SNIF to solve this specific proble= m - >>> > local-to-local trusted TLS connections=2E >>> >>>Ah, very nice to know=2E >>> >>> > * Issue a wildcard cert through SNIF CA Proxy >>> > (e=2Eg=2E CN=3D*=2Edomain=2Esnif=2Exyz), set a DNS record for >>> > localhost=2Edomain=2Esnif=2Exyz to point to localhost's IPv4/v6, = and use >>> > https://localhost=2Edomain=2Esnif=2Exyz (or other app protocol - = imaps >>> > etc)=2E However, looks like some clients treat the localhost IP a= s >>> > inherently unsecure, and issue a warning ever is the cert is perf= ectly >>> > valid=2E The option is still possible, but the applicability migh= t be >>> > limited=2E >>> >>>The process we described at >>> >>>https://specs=2Emanysecured=2Eorg/suib/Solutions/dnsname-embedded-solut= ion >>> >>>also uses a wildcard cert, but has a magic authoritative DNS server >>>that translates the left-most label into an A or AAAA record=2E It's >>>rather a cute hack, but at least: >>> a) it's cachable >>> b) it could even be calculated locally, if one ignores DNSSEC=2E >> >>Yes, using a local network IP instead of a localhost IP is actually a sm= art idea=2E >>However, inlining the local IP in the hostname, as SUIB does, means you'= ll have to change the hostname in your client every time your network is ch= anged=2E >>I have an thought for SNIF improvement - SNIF connector sends a SNIF DNS= command to set a dynamic DNS A/AAAA for a certain hostname within the CN w= ildcard, and the CA proxy updates the DNS accordingly=2E This way the hostn= ame can be permanent, but with dynamic DNS=2E >>Another problem - most platforms won't let you bind to port < 1024 unles= s you're a root=2E Might be ok for a device manufacturer, but is a potentia= l show stopper for any user space app=2E Relayed SNIF works around this pro= blem since the listening ports are on the relay=2E >> >> >>> >>> > * Another option is to override the IP routing rules=2E It is tot= ally >>> > possible on iOS and Mac through a userspace VPN (only one VPN per >>> > device though - beware of possible conflicts)=2E In fact I have a >>> > functioning solution for it, in beta now - >>> >>>That doesn't really scale to many different domains=2E >> >>Totally agreed, I just mentioned that this option works for *some* cases= , tun/tap a is possible option too if you're a root=2E >> >>> >>> >> Still, if SNIF is replacing a manufacturer proprietary call-home= protocol, >>> >> there could be advantages from having well reviewed code bases, = and >>> >> potentially an ecosystem of SNIF Providers that manufacturers co= uld >>> >> outsource >>> >>> >> to=2E Azure/Amazon/=2E=2E=2E could easily run such services=2E >>> >>> > I see two options - a SNIF server implemented by each vendor for = their >>> > own devices/services, or a bigger SNIF SaaS implemented by a trus= ted >>> > provider, used by vendors=2E >>> >>>Yes, but what's the financial motive for this provider? >> >>(1) For a vendor to run their own SNIF server: market as a true auditabl= e end-to-end for IoT devices they offer=2E >>(2) For a vendor using SNIF SaaS: market as (1) backed by >>{TrustedBigName} >>(3) For a {TrustedBigName} to run SNIF SaaS: collect fees from (2) for u= sing their service and big name=2E >> >>As a matter of fact, SNIF relay is light on server resources=2E I've bee= n running it on a minimum DigitalOcean virtual server for months with more = than a dozen connectors, the server load is a fraction of a percent=2E Of= course if somebody connects IoT cameras they can generate some traffic, bu= t IoT vendors already handle it through their proprietary relays=2E >> >>> >>> >> SNIF seems very much IPv4 NAT44 focused, and it could benefit fr= om some >>> >> understanding of IPv6 and IPv6-over-IPv4 technologies, >>> particularly >>> >>> >> Teredo=2E >>> >>> > SNIF is not exactly focused on v4, it works fine with v6 as well= =2E It's >>> > designed to work around NAT, that's true=2E However, IPv6 network= s may >>> > pose issues too - firewalls etc, which will prevent to directly a= ccept >>> > incoming TCP on IPv6 address=2E >>> >>>Teredo could be used instead and allows the relay to be stateless and >>>distributed, and devolves to ordinary IPv6 when it is present=2E >> >>Yes, but Teredo is IPv6 specific, the world is not strictly IPv6 yet=2E = And it's a system level solution, while SNIF works fine in a user space=2E >> >>> >>> >> It clearly has to speak HTTPS only=2E >>> >>> > I specified HTTP because PKCS#10 and X=2E509 are inherently secur= e to be >>> > sent over a plain connection=2E >>> >>>Yes, but there are privacy concerns which will become a pain, so >>>better to just say HTTPS here=2E >> >>I respectfully disagree, still think HTTP is an easier answer for SNIF= =2E The problem with HTTPS is - SNIF relay (usually) routes https port to S= NIF connectors, and does not serve it within the server=2E Having a dedicat= ed hostname or an alternate port means than SNIF connectors need additional= configuration options, or additional discovery protocols=2E On the other h= and, HTTP allows to derive all API URLs deterministically from the CN=2E >>I addressed the possible security concerns in more details and amended t= he Security section in the draft=2E >> >> >>> >>> > The best option is the manufacturer I believe=2E The manufacturer= can >>> > have either their own SNIF server, or work with a trusted SaaS=2E= This >>> > way it's zero setup for the end user, and doesn't need any >>> > infrastructure additions=2E >>> >>>Agreed, the manufacturer has to provision a credential=2E >> >>Yes I proposed some outlines in the security section, more detailed spec= s are probably better to describe in a separate draft=2E >> >>> >>> > Sure, elliptic curves are better, but some old school clients may= have >>> > problems with them=2E It may make sense to not mention the recomm= ended >>> > algorithm in the draft, and just to follow the CA's recommendatio= ns=2E >>> >>>ECDSA acceleration is pretty much ubiquitous, while RSA is not=2E >> >>Honestly I don't think acceleration is such a big deal, most of TLS job = is symmetric ciphers anyway=2E But I agree - it's better to follow the CA s= uggestions and industry practices=2E >> >>> >>> > I believe there's no security issue, as long as the CN entropy is= sufficient=2E >>> >>> > I specified the X-SNIF-CN: as mandatory, and text/plain body as a= n >>> > optional duplicate of it=2E To make it cleaner, I can remove the = body >>> > from the specs and say the response body is to be ignored=2E >>> >>>If both are present, and they don't match, then there is confusion=2E >>>So just go with one=2E I think that it should actually be a JSON or CB= OR payload return=2E >> >>Agreed, I removed the response body from the draft, going with the heade= r=2E >> >> >>> >>> >> They *aren't* what IANA would call "IP protocols", which would b= e things >>> >> like >>> >> TCP, UDP, SCTP, ESP, =2E=2E=2E >>> >>> >> Has IANA *already* registered port 7123 then? >>> >>> > It's not an IP protocol=2E It's a service that listens on TCP 712= 3, I >>> > registered with IANA based on a previous version of the document, >>> > before I turned it into an I-D=2E >>> >>>I think you should drop the "snif-*" sentence as it makes no sense=2E >>>You have already allocated TCP port 7123 to the SNIF *service*, so >>>that's great=2E >> >>It's actually called "Service Names" in IANA terminology, sorry for the = confusion=2E I updated in the draft=2E >> >> >> >>> >>>-- >>>] Never tell me the odds! | ipv6 mesh net= works [ >>>] Michael Richardson, Sandelman Software Works | IoT archit= ect [ >>>] mcr@sandelman=2Eca http://www=2Esandelman=2Eca/ | ruby = on rails [ >>> >> >>_______________________________________________ >>Secdispatch mailing list >>Secdispatch@ietf=2Eorg >>https://www=2Eietf=2Eorg/mailman/listinfo/secdispatch >>IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged=2E If you are not the intended recipie= nt, please notify the sender immediately and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the informatio= n in any medium=2E Thank you=2E >> >>_______________________________________________ >>Secdispatch mailing list >>Secdispatch@ietf=2Eorg >>https://www=2Eietf=2Eorg/mailman/listinfo/secdispatch > >-- >Iotops mailing list >Iotops@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/iotops >IMPORTANT NOTICE: The contents of this email and any attachments are conf= idential and may also be privileged=2E If you are not the intended recipien= t, please 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=2E Thank you=2E ------FG15COL8L8O8PLJUN0S11AF88ICT5W Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Hannes,
I just want to emphasize once ag= ain that the relay is end to end TLS=2E
There are some IoT management so= lutions on the market, both open source and proprietary, but as far as I ca= n tell none of them fully follows the end to end paradigm=2E I believe it's= worth having a universal cross-vendor solution that handles SNIF device on= boarding, maintains the credentials in a local secure storage, and consolid= ates https based management interface hosted by individual devices through = SNIF=2E
The requirements for such solution is a topic for a separate dra= ft, although I already outlined the possible secure onboarding process in t= he security section=2E

On February 24, 20= 22 5:37:46 AM EST, Hannes Tschofenig <Hannes=2ETschofenig@arm=2Ecom> = wrote:
Hi Jim,

Thanks for the quick res=
ponse=2E The link to your website is helpful=2E I now understood that you w=
ould also relay the communication through the proxy, which deals with the I=
oT device being behind a NAT and/or firewall if the IoT device keeps the co=
nnection alive=2E

I wonder whether you have considered to re-use an =
existing device management solutions since those is widely deployed today?<=
br>
Ciao
Hannes

-----Original Message-----
From: Iotops <=
;iotops-bounces@ietf=2Eorg> On Behalf Of Jim Zubov
Sent: Wednesday, F=
ebruary 23, 2022 4:17 PM
To: secdispatch@ietf=2Eorg; Hannes Tschofenig &=
lt;Hannes=2ETschofenig@arm=2Ecom>; Jim Zubov <ietf-list@commercebyte=
=2Ecom>; secdispatch@ietf=2Eorg; Michael Richardson <mcr+ietf@sandelm=
an=2Eca>; iotops@ietf=2Eorg; anima@ietf=2Eorg
Subject: Re: [Iotops] [=
Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Usi=
ng SNI-based End-to-End TLS Forwarding (SNIF)

Thank You for your fee=
dback Hannes, I addressed the comments below -

On February 23, 2022 =
5:36:15 AM EST, Hannes Tschofenig <Hannes=2ETschofenig@arm=2Ecom> wro=
te:
Hi all,

Than=
ks for this contribution, Jim=2E

Reading through the document I agre=
e that the SUIB topic discussed in the IOTOPS WG appears relevant=2E I also=
 wonder whether the work in the DANISH group (see https://datatracker=2Eietf=2Eorg/wg/d=
anish/about/) is relevant=2E

Agreed about SUIB, not=
 quite sure about DANISH=2E DANISH is about certificate based authenticatio=
n and PKI extensions, while SNIF is about end-to-end relayed trusted TLS th=
at relies on the standard PKI=2E


Regarding the use in IoT I have a question for my underst=
anding=2E

In a nutshell, you introduce a proxy that allocates a host=
name and requests a creation of a certificate on behalf of the IoT device=
=2E

Correct, plus an e2e TLS relay=2E

To get this to work you rely on thre=
e assumptions:
(1) There has to be a communication infrastructure that a=
ssociates the "anonymous" hostname with a specific device and conveys these=
 identifiers to the relevant parties=2E

Each device is =
configured with an initUrl pointing to a specific CA proxy that allocates a=
 random hostname (a CN to be more accurate), normally a subdomain of a mast=
er domain that has a wildcard DNS record pointing to the CA proxy=2E
Exa=
mple - the initUrl for public experimental use - https://snif=2Esnif=2Exyz:4443 The allocated wildcard =
CN is a subdomain of the master domain snif=2Exyz


(2) You assume that a party that wants t=
o contact the IoT device is able to reach the device (i=2Ee=2E the IoT devi=
ce is not behind a firewall or NAT)=2E

Both the IoT dev=
ice and the client connect to the SNIF relay=2E The whole purpose of SNIF i=
s to be able to work from behind NAT / firewall /etc, and it's been confirm=
ed to work in pre-production=2E In fact I had a minor hickup with Fortigate=
 in the process of testing which has been resolved=2E
There are simplifi=
ed diagrams on https://snif=2Ehost to i=
llustrate the concept=2E


(3) Someone operating IoT devices has to trust the proxy since it=
 is easy for the proxy to associate a hostname with a public key that was c=
reated by the proxy (rather than the end device)=2E This essentially allows=
 the proxy to impersonating the IoT device=2E

Is my understanding co=
rrect?

Yes, I mentioned this vulnerability in the secur=
ity section=2E The answer is
- watch the public TLS transparency logs, a=
ny party can do it=2E If any overlapping CNs are found - the CA proxy is pe=
rmanently compromised,
- do not use random CA proxies owned by unknown p=
arties=2E



C=
iao
Hannes

Any further questions/suggestions are wel=
come=2E


-----Or=
iginal Message-----
From: Secdispatch <secdispatch-bounces@ietf=2Eorg=
> On Behalf Of Jim Zubov
Sent: Friday, February 11, 2022 12:22 AM
=
To: secdispatch@ietf=2Eorg; Michael Richardson <mcr+ietf@sandelman=2Eca&=
gt;;
Jim Zubov <ietf-list@commercebyte=2Ecom>; iotops@ietf=2Eorg; =
anima@ietf=2Eorg
Subject: Re: [Secdispatch] I-D: Deploying Publicly Trus=
ted TLS Servers
on IoT Devices Using SNI-based End-to-End TLS Forwarding=
 (SNIF)

Thanks for the feedback again, my comment are below=2E
I =
submitted a new version of the draft to reflect some changes=2E

On F=
ebruary 10, 2022 1:02:48 PM EST, Michael Richardson <mcr+ietf@sandelman=
=2Eca> wrote:

Ji=
m Zubov <ietf-list@commercebyte=2Ecom> wrote:
 This was also on the IETF112 IOTOPS WG agenda:
 slides:
 https://datatracker=2Eietf=2Eorg/meeting/=
112/materials/slides-112-iotops-suib-browsing-local-web-resources-in-a-secu=
re-usable-manner-iot-device-configuration-as-a-special-case-00
 vide=
o:  https://youtu=2Ebe/=
OIlJrUvwDcI?t=3D1649

 and we hope to return at IETF113=2E

Right, looks like SUIB is working on a similar problem=2E Thanks for
po=
inting this out=2E In particular, the "Sol #6 Device name DNS" slide
loo=
ks quite similar to SNIF CA Proxy (Section 3)=2E However, SUIB pursues
b=
igger infrastructural goals such as changing the localhost TLS
connectio=
n policies (I totally agree and really appreciate the effort),
while SNI=
F is a functioning solution within the existing
infrastructure, tested a=
nd proven to work in pre-production=2E

The slides may b=
e too vague=2E  Changing the TLS policies is a possible
solution, but pr=
obably an impractical one=2E  Nevertheless, many people
(not steeped in =
the arts, and often failling into the PHB category)
think that it is an =
obvious solution, so we list it in order to explain why it won't work=2E

Yes, still sad that localhost slipped through the cracks =
when the original security standards were written=2E


 The SUIB prob=
lem addresses the challenge of connecting *locally* to a
 device,
 an=
d doing it securely=2E  For this to be possible with RFC6125-DNS-ID
 sta=
ndard
 browser, we need a name for the device, and we need a way to tran=
slate
 that
 name into a locally reachable IP address=2E

 The =
SNIF proposal does not quite solve the above problem=2E

In fact, I o=
riginally designed SNIF to solve this specific problem -
local-to-local =
trusted TLS connections=2E

Ah, very nice to know=2E
=

* Issue a wildcard cer=
t through SNIF CA Proxy
(e=2Eg=2E CN=3D*=2Edomain=2Esnif=2Exyz), set a D=
NS record for
localhost=2Edomain=2Esnif=2Exyz to point to localhost's IP=
v4/v6, and use
https=
://localhost=2Edomain=2Esnif=2Exyz (or other app protocol - imaps
et=
c)=2E However, looks like some clients treat the localhost IP as
inheren=
tly unsecure, and issue a warning ever is the cert is perfectly
valid=2E=
 The option is still possible, but the applicability might be
limited=2E=


The process we described at

https:/=
/specs=2Emanysecured=2Eorg/suib/Solutions/dnsname-embedded-solution
=

also uses a wildcard cert, but has a magic authoritative DNS server
=
that translates the left-most label into an A or AAAA record=2E  It's
ra=
ther a cute hack, but at least:
  a) it's cachable
  b) it could even=
 be calculated locally, if one ignores DNSSEC=2E

Yes, u=
sing a local network IP instead of a localhost IP is actually a smart idea=
=2E
However, inlining the local IP in the hostname, as SUIB does, means =
you'll have to change the hostname in your client every time your network i=
s changed=2E
I have an thought for SNIF improvement - SNIF connector sen=
ds a SNIF DNS command to set a dynamic DNS A/AAAA for a certain hostname wi=
thin the CN wildcard, and the CA proxy updates the DNS accordingly=2E This =
way the hostname can be permanent, but with dynamic DNS=2E
Another probl=
em - most platforms won't let you bind to port < 1024 unless you're a ro=
ot=2E Might be ok for a device manufacturer, but is a potential show stoppe=
r for any user space app=2E Relayed SNIF works around this problem since th=
e listening ports are on the relay=2E



* Another option is to override the IP routing rules=2E It is totally
p=
ossible on iOS and Mac through a userspace VPN (only one VPN per
device =
though - beware of possible conflicts)=2E In fact I have a
functioning s=
olution for it, in beta now -

That doesn't really scale=
 to many different domains=2E

Totally agreed, I just me=
ntioned that this option works for *some* cases, tun/tap a is possible opti=
on too if you're a root=2E


Still, if SNIF is replacing a manufact=
urer proprietary call-home protocol,
there could be advantages from havi=
ng well reviewed code bases, and
potentially an ecosystem of SNIF Provid=
ers that manufacturers could
outsource

=

to=2E  Azure/Amazon/=2E=2E=2E could easily run such =
services=2E

I see two options - a SNIF server implemented by each ve=
ndor for their
own devices/services, or a bigger SNIF SaaS implemented b=
y a trusted
provider, used by vendors=2E

Yes, but wh=
at's the financial motive for this provider?

(1) For a =
vendor to run their own SNIF server: market as a true auditable end-to-end =
for IoT devices they offer=2E
(2) For a vendor using SNIF SaaS: market a=
s (1) backed by
{TrustedBigName}
(3) For a {TrustedBigName} to run SN=
IF SaaS: collect fees from (2) for using their service and big name=2E
<=
br>As a matter of fact, SNIF relay is light on server resources=2E I've bee=
n running it on a minimum DigitalOcean virtual server for months with more =
than a dozen connectors,   the server load is a fraction of a percent=2E Of=
 course if somebody connects IoT cameras they can generate some traffic, bu=
t IoT vendors already handle it through their proprietary relays=2E

=


SNIF seems very much IPv4 NAT44 focused, and it could benefit from someunderstanding of IPv6 and IPv6-over-IPv4 technologies,
 particularly

Teredo=2E

SNIF=
 is not exactly focused on v4, it works fine with v6 as well=2E It's
des=
igned to work around NAT, that's true=2E However, IPv6 networks may
pose=
 issues too - firewalls etc, which will prevent to directly accept
incom=
ing TCP on IPv6 address=2E

Teredo could be used instead=
 and allows the relay to be stateless and
distributed, and devolves to o=
rdinary IPv6 when it is present=2E

Yes, but Teredo is I=
Pv6 specific, the world is not strictly IPv6 yet=2E And it's a system level=
 solution, while SNIF works fine in a user space=2E


It clearly has =
to speak HTTPS only=2E

I specified HTTP because PKCS#10 and X=2E50=
9 are inherently secure to be
sent over a plain connection=2E

Yes, but there are privacy concerns which will become a pain, so<=
br>better to just say HTTPS here=2E

I respectfully disa=
gree, still think HTTP is an easier answer for SNIF=2E The problem with HTT=
PS is - SNIF relay (usually) routes https port to SNIF connectors, and does=
 not serve it within the server=2E Having a dedicated hostname or an altern=
ate port means than SNIF connectors need additional configuration options, =
or additional discovery protocols=2E On the other hand, HTTP allows to deri=
ve all API URLs deterministically from the CN=2E
I addressed the possibl=
e security concerns in more details and amended the Security section in the=
 draft=2E



<=
blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; bord=
er-left: 1px solid #8ae234; padding-left: 1ex;">The best option is the manu=
facturer I believe=2E The manufacturer can
have either their own SNIF se=
rver, or work with a trusted SaaS=2E This
way it's zero setup for the en=
d user, and doesn't need any
infrastructure additions=2E

Agreed, the manufacturer has to provision a credential=2E

Yes I proposed some outlines in the security section, more detailed=
 specs are probably better to describe in a separate draft=2E


Sure, elliptic curves are better, but some old school =
clients may have
problems with them=2E It may make sense to not mention =
the recommended
algorithm in the draft, and just to follow the CA's reco=
mmendations=2E

ECDSA acceleration is pretty much ubiqui=
tous, while RSA is not=2E

Honestly I don't think accele=
ration is such a big deal, most of TLS job is symmetric ciphers anyway=2E B=
ut I agree - it's better to follow the CA suggestions and industry practice=
s=2E


I believe there's no security issue,=
 as long as the CN entropy is sufficient=2E

I specified the X-SNIF-CN: as mandato=
ry, and text/plain body as an
optional duplicate of it=2E To make it cle=
aner, I can remove the body
from the specs and say the response body is =
to be ignored=2E

If both are present, and they don't ma=
tch, then there is confusion=2E
So just go with one=2E  I think that it =
should actually be a JSON or CBOR payload return=2E

Agr=
eed, I removed the response body from the draft, going with the header=2E


They *aren't* what IANA would call "IP protocols", which would =
be things
like
TCP, UDP, SCTP, ESP, =2E=2E=2E

Has IANA *already* registered port 7123 t=
hen?

It's not an IP protocol=2E It's a service that listens on TCP 7=
123, I
registered with IANA based on a previous version of the document,=

before I turned it into an I-D=2E

I think you shoul=
d drop the "snif-*" sentence as it makes no sense=2E
You have already al=
located TCP port 7123 to the SNIF *service*, so
that's great=2E

It's actually called "Service Names" in IANA terminology, sorry=
 for the confusion=2E I updated in the draft=2E




--
]               Never tell m=
e the odds!                 | ipv6 mesh networks [
]   Michael Richardso=
n, Sandelman Software Works        |    IoT architect   [
]     mcr@sand=
elman=2Eca  http://www=2Esandelman=
=2Eca/        |   ruby on rails    [

Secdispatc=
h mailing list
Secdispatch@ietf=2Eorg
https://www=2Eietf=2Eorg/mailman/listi=
nfo/secdispatch
IMPORTANT NOTICE: The contents of this email and any=
 attachments are confidential and may also be privileged=2E If you are not =
the intended recipient, please notify the sender immediately and do not dis=
close the contents to any other person, use it for any purpose, or store or=
 copy the information in any medium=2E Thank you=2E
Secdispatch mailing =
list
Secdispatch@ietf=2Eorg
https://www=2Eietf=2Eorg/mailman/listinfo/secdispa=
tch

--
Iotops mailing list
Iotops@ietf=2Eorg<=
br>https://www=
=2Eietf=2Eorg/mailman/listinfo/iotops
IMPORTANT NOTICE: The contents=
 of this email and any attachments are confidential and may also be privile=
ged=2E If you are not the intended recipient, please notify the sender imme=
diately and do not disclose the contents to any other person, use it for an=
y purpose, or store or copy the information in any medium=2E Thank you=2E
------FG15COL8L8O8PLJUN0S11AF88ICT5W-- From nobody Fri Feb 25 17:39:02 2022 Return-Path: X-Original-To: iotops@ietf.org Delivered-To: iotops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 612303A1302; Fri, 25 Feb 2022 17:29:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: iotops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164583895737.24617.169440254843980546@ietfa.amsl.com> Date: Fri, 25 Feb 2022 17:29:17 -0800 Archived-At: Subject: [Iotops] iotops - Requested session has been scheduled for IETF 113 X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2022 01:29:27 -0000 Dear Alexey Melnikov, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. iotops Session 1 (2:00 requested) Thursday, 24 March 2022, Morning Session I 1000-1200 Room Name: Park Suite 9 size: 165 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/113/sessions/iotops.ics Request Information: --------------------------------------------------------- Working Group Name: IOT Operations Area Name: Operations and Management Area Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): Number of Attendees: 100 Conflicts to Avoid: People who must be present: Alexey Melnikov Henk Birkholz Warren "Ace" Kumari Resources Requested: Special Requests: We typically use 1-1.5 hours, so downgrading 2 hours to 1 is Ok. --------------------------------------------------------- From nobody Sat Feb 26 10:04:17 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 8BBCF3A0AB4; Sat, 26 Feb 2022 10:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=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 JgFPzlf7B-Mn; Sat, 26 Feb 2022 10:04:11 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C918C3A0C42; Sat, 26 Feb 2022 10:03:40 -0800 (PST) Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4K5ZJV3mXvzDCc0; Sat, 26 Feb 2022 19:03:38 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 667591418.267503-58872359a9f7bce0814e898f9dec4e80 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Message-Id: <7F85B289-8947-449E-97CF-5073E2979196@tzi.org> Date: Sat, 26 Feb 2022 19:03:38 +0100 To: asdf@ietf.org, coin@irtf.org, iotops@ietf.org, dance@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [Iotops] [Cbor] Constrained Node/Network Cluster @ IETF113: FINAL AGENDA 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: Sat, 26 Feb 2022 18:04:15 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF113. Remember that further agenda changes can still happen. The IoT-relevant conflicts that most meet the eye this time are LPWAN/ACE (probably little actual overlap) and DRIP/ROLL/RATS (probably a little more overlap, but not that much). CFRG and ICNRG are the only RGs not on top of IoT meetings (T2TRG, like e.g. CBOR and JSONPATH, decided to go for interims instead). In the "FINAL" agenda, DANCE is now on top of CORE; not much else has changed from a constrained node networks point of view. All times are in UTC. Note that the third and fourth weeks in March (W11 =3D pre-IETF week, W12 =3D IETF week) are Weeks of Confusion, where DST has not yet started in Europe but did already start in North America. https://datatracker.ietf.org/meeting/agenda-utc might be handy. Gr=C3=BC=C3=9Fe, Carsten (### DST in US, no DST in EU ###) SATURDAY, March 19, 2022 0830-2000 Hackathon - Grand Klimt Hall 1/2 0930-1000 Hackathon Kickoff - Grand Klimt Hall 1/2 SUNDAY, March 20, 2022 0830-1500 Hackathon - Grand Klimt Hall 1/2 (0900-1700 IETF Registration - Park Ensemble) 1300-1500 Hackathon Results Presentations - Grand Klimt Hall 1/2 (1600-1800 Welcome Reception - Grand Park Hall 1/2/3) MONDAY, March 21, 2022 0900-1100 Morning Session I G Park Hall 3 ART dispatch Dispatch WG - Joint with ARTAREA G Park Hall 1 OPS v6ops IPv6 Operations WG G Klimt Hall 2 RTG raw Reliable and Available Wireless WG Park Suite 9 SEC openpgp Open Specification for Pretty Good = Privacy WG Park Suite 8 SEC *** teep Trusted Execution Environment = Provisioning WG 1200-1300 Afternoon session I Park Suite 8 ART sedate Serialising Extended Data About Times = and Events WG G Park Hall 2 IRTF pearg Privacy Enhancements and Assessments = Research Group Park Suite 3 SEC acme Automated Certificate Management = Environment WG Park Suite 9 SEC *** cose CBOR Object Signing and Encryption WG G Park Hall 3 TSV tsvwg Transport Area Working Group WG 1330-1530 Afternoon Session II G Klimt Hall 2 SEC *** lake Lightweight Authenticated Key Exchange = WG Park Suite 8 SEC oauth Web Authorization Protocol WG G Park Hall 1 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG TUESDAY, March 22, 2022 0900-1100 Morning Session I Park Suite 9 INT 6man IPv6 Maintenance WG G Park Hall 1 RTG can Computing-Aware Networking BOF Park Suite 3 SEC *** rats Remote ATtestation ProcedureS WG G Park Hall 3 TSV quic QUIC WG 1200-1300 Afternoon session I G Park Hall 2 INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG G Park Hall 1 IRTF qirg Quantum Internet Research Group Park Suite 3 SEC *** ace Authentication and Authorization for = Constrained Environments WG Park Suite 8 SEC emu EAP Method Update WG Park Suite 9 TSV tsvarea Transport Area Open Meeting 1330-1530 Afternoon Session II G Klimt Hall 2 INT intarea Internet Area Working Group WG G Park Hall 2 IRTF irtfopen IRTF Open Meeting G Park Hall 1 RTG detnet Deterministic Networking WG G Park Hall 3 SEC secdispatch Security Dispatch WG WEDNESDAY, March 23, 2022 0900-1100 Morning Session I G Klimt Hall 2 ART moq Media Over QUIC BOF Park Suite 8 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Park Suite 9 IRTF maprg Measurement and Analysis for Protocols G Park Hall 2 RTG rtgarea Routing Area Open Meeting G Park Hall 3 SEC tls Transport Layer Security WG 1200-1300 Afternoon session I Park Suite 2 ART mediaman Media Type Maintenance WG G Park Hall 1 INT *** drip Drone Remote ID Protocol WG Park Suite 8 RTG *** roll Routing Over Low power and Lossy = networks WG Park Suite 3 SEC mls Messaging Layer Security WG G Park Hall 3 SEC *** rats Remote ATtestation ProcedureS WG G Park Hall 2 TSV taps Transport Services WG 1330-1530 Afternoon Session II Park Suite 3 RTG bier Bit Indexed Explicit Replication WG 1600-1800 IETF Plenary - Grand Park Hall 1-3 THURSDAY, March 24, 2022 0900-1100 Morning Session I G Park Hall 2 ART httpapi Building Blocks for HTTP APIs WG G Park Hall 1 INT savnet Source Address Validation in = Intra-domain and Inter-domain Networks BOF G Klimt Hall 2 IRTF coinrg Computing in the Network Research Group Park Suite 9 OPS *** iotops IOT Operations WG G Park Hall 3 SEC saag Security Area Open Meeting 1200-1300 Afternoon session I G Park Hall 3 INT madinas MAC Address Device Identification for = Network and Application Services WG G Klimt Hall 2 IRTF panrg Path Aware Networking RG Park Suite 8 RTG rift Routing In Fat Trees WG Park Suite 3 SEC privacypass Privacy Pass WG G Park Hall 2 SEC *** suit Software Updates for Internet of Things = WG 1330-1530 Afternoon Session II G Klimt Hall 2 ART webtrans WebTransport WG G Park Hall 2 INT add Adaptive DNS Discovery WG G Park Hall 3 IRTF cfrg Crypto Forum Park Suite 2 SEC oauth Web Authorization Protocol WG FRIDAY, March 25, 2022 0900-1100 Morning Session I G Klimt Hall 2 ART *** core Constrained RESTful Environments WG Park Suite 8 SEC dance DANE Authentication for Network Clients = Everywhere WG G Park Hall 2 SEC gnap Grant Negotiation and Authorization = Protocol WG G Park Hall 3 TSV tsvwg Transport Area Working Group WG 1130-1330 Afternoon Session I Park Suite 3 IRTF icnrg Information-Centric Networking G Klimt Hall 2 OPS anima Autonomic Networking Integrated Model = and Approach WG (### DST STARTS IN EUROPE ON SUNDAY ###) _______________________________________________ CBOR mailing list CBOR@ietf.org https://www.ietf.org/mailman/listinfo/cbor