From nobody Tue Feb 1 04:43:30 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126733A0869 for ; Tue, 1 Feb 2022 04:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.897 X-Spam-Level: X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQhX71Aeq0Ql for ; Tue, 1 Feb 2022 04:43:16 -0800 (PST) Received: from st43p00im-ztdg10071801.me.com (st43p00im-ztdg10071801.me.com [17.58.63.171]) (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 BEC753A0864 for ; Tue, 1 Feb 2022 04:43:16 -0800 (PST) Received: from smtpclient.apple (c-69-255-21-229.hsd1.va.comcast.net [69.255.21.229]) by st43p00im-ztdg10071801.me.com (Postfix) with ESMTPSA id 04EB83C0F71; Tue, 1 Feb 2022 12:34:51 +0000 (UTC) From: John Curran Message-Id: <45FB4652-FE54-4356-AD24-12CB91495F79@istaff.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_C8F807D5-3CB0-47F4-85C2-3E19F0D8B051" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Date: Tue, 1 Feb 2022 07:34:50 -0500 In-Reply-To: <004f01d8170a$25c35620$714a0260$@acm.org> Cc: Michael Richardson , n.lukianets@openethics.ai, art@ietf.org, dispatch@ietf.org, hrpc@irtf.org, secdispatch@ietf.org To: Larry Masinter References: <6dac86b0eb3b96490dadffdc0f1d307a@openethics.ai> <3343.1643661981@localhost> <004f01d8170a$25c35620$714a0260$@acm.org> X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-02-01_03:2022-02-01, 2022-02-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1030 mlxscore=0 mlxlogscore=535 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2009150000 definitions=main-2202010069 Archived-At: Subject: Re: [Secdispatch] [hrpc] [art] Open Ethics Transparency Protocol X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2022 12:43:21 -0000 --Apple-Mail=_C8F807D5-3CB0-47F4-85C2-3E19F0D8B051 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 31 Jan 2022, at 8:22 PM, Larry Masinter wrote: >=20 > Check out=20 > https://github.com/w3ctag/ethical-web-principles > which seems to have some momentum and some similar goals. Larry -=20 A very interesting initiative - thanks for sharing.=20 After brief review, it would appear that the web folks have a = signficiant advantage in their efforts to protect human rights on the = web, as they are successful in affirmatively stating their desired = outcome for its users =E2=80=93=20 e.g. "The web must make it possible for people to verify the information = they see=E2=80=9D - this speaks directly to the functionality that must = be provided to the users rather than the human rights implications of an = application failing to do so=E2=80=A6 An interesting thought exercise lies in considering why the IETF/IRTF = work in this area differs in this regard - I suspect it is not lack of = desire, but inherent to dealing with many protocols and implied = application contexts rather than one predominant model (i.e. the = user/web browser context). It is quite reasonable that the abundance = of protocols and user contexts results in pragmatic limits in = postulating desired user functionality for an ethical Internet, but it = does raise the question of whether more focused efforts for the most = popular applications (e.g. email, messaging) could be undertaken in = other contexts or for some reason are simply unachievable outside of the = web context... Thanks again for the pointer to this work!=20 /John Disclaimer: my views alone - may cause drowsiness - do not read while = operating heavy machinery. =20 --Apple-Mail=_C8F807D5-3CB0-47F4-85C2-3E19F0D8B051 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 31 Jan 2022, at 8:22 PM, = Larry Masinter <LMM@acm.org> wrote:

Check = out
=             &n= bsp; https://github.com/w3ctag/ethical-web-principles
which seems to have some momentum and some similar = goals.

Larry = - 

A very interesting = initiative - thanks for sharing. 

After brief review, it would appear that the web = folks have a signficiant advantage in their efforts to protect human = rights on the web, as they are successful in affirmatively stating their = desired outcome for its users =E2=80=93 
e.g. "The web must = make it possible for people to verify the information they see=E2=80=9D = - this speaks directly to the functionality that must be provided to the = users rather than the human rights implications of an application = failing to do so=E2=80=A6

An interesting thought exercise lies in = considering why the IETF/IRTF work in this area differs in this regard - = I suspect it is not lack of desire, but inherent to dealing with many = protocols and implied application contexts rather than one predominant = model (i.e. the user/web browser context).   It is quite reasonable = that the abundance of protocols and user contexts results in pragmatic = limits in postulating desired user functionality for an ethical = Internet, but it does raise the question of whether more focused efforts = for the most popular applications (e.g. email, messaging) could be = undertaken in other contexts or for some reason are simply unachievable = outside of the web context...

Thanks again for the pointer to this = work! 
/John

Disclaimer:  my views alone - may cause drowsiness - do = not read while operating heavy machinery.    

= --Apple-Mail=_C8F807D5-3CB0-47F4-85C2-3E19F0D8B051-- From nobody Tue Feb 1 06:03:47 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3501B3A0E1F; Tue, 1 Feb 2022 06:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.434 X-Spam-Level: X-Spam-Status: No, score=-1.434 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_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=openethics.ai 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 OEVHU1Q_OxyD; Tue, 1 Feb 2022 06:03:31 -0800 (PST) Received: from nlskm21.hostsila.org (nlskm21.hostsila.org [88.218.28.6]) (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 8801B3A0E1C; Tue, 1 Feb 2022 06:03:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openethics.ai; s=default; h=Content-Transfer-Encoding:Content-Type: Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EdcFijR6lcZqZq5gZAH6j9q5cGhvocgplKVUl60fpH8=; b=a1Ci/qEd3mnRNy+7uqZOARMlGu 57Uo4z/jBs56RjLXPuefYx8j0E/hUw1dGnHbai5xMXGa0kCo12j9BrH3OUYfSGVWh8cITWII/gJey zRl405b5HDUgfG76qjcsSPPD8IdndoRN486cx8MRuDVDM3X9BzAxGIDfXVXqxzF0jFUhGKVhONX6D uddeEFM7DoLVKxURvRQ89IQTxxWGxxbIG018lG4xOz7XLlH4cymDU73Vz7evPO8/rC1G6jsBILBPD HIluV7HDjMSvOfLHQIInX8JaElzI/OZxmjnZVg1kIEC78tAhvDYh4UbJ6Qc+onOJwQtUKF5qHJKj/ Pd3zWuww==; Received: from [127.0.0.1] (port=43946 helo=nlskm21.hostsila.org) by nlskm21.hostsila.org with esmtpa (Exim 4.94.2) (envelope-from ) id 1nEtkl-0008VH-C7; Tue, 01 Feb 2022 16:03:26 +0200 MIME-Version: 1.0 Date: Tue, 01 Feb 2022 16:03:25 +0200 From: n.lukianets@openethics.ai To: John Curran , ghelfrich@internews.org, Michael Richardson , Larry Masinter Cc: art@ietf.org, dispatch@ietf.org, hrpc@irtf.org, secdispatch@ietf.org In-Reply-To: <45FB4652-FE54-4356-AD24-12CB91495F79@istaff.org> References: <6dac86b0eb3b96490dadffdc0f1d307a@openethics.ai> <3343.1643661981@localhost> <004f01d8170a$25c35620$714a0260$@acm.org> <45FB4652-FE54-4356-AD24-12CB91495F79@istaff.org> User-Agent: Roundcube Webmail/1.4.12 Message-ID: <3dc66e6f6ce450f20f5154bdd80a72f8@openethics.ai> X-Sender: n.lukianets@openethics.ai Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - nlskm21.hostsila.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - openethics.ai X-Get-Message-Sender-Via: nlskm21.hostsila.org: authenticated_id: n.lukianets@openethics.ai X-Authenticated-Sender: nlskm21.hostsila.org: n.lukianets@openethics.ai X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Secdispatch] [hrpc] [art] Open Ethics Transparency Protocol X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2022 14:03:37 -0000 Thanks a lot John, Gina, Larry, Michael. All your comments are very valuable here I'll try to put my reflections as a response in one single email to continue the conversation. @Michael, > Are you talking about security disclosures? > Or something else? The approach/lens that we're taking here is to allow describing every autonomous system with the help of the ethical "vector". We are aiming to bring at least a very basic formalism to what is now becoming a buzzword. https://openethics.ai/vector/ Security part in the disclosure which forms these vectors is a component, but not everything. In some applications security is key, while in others users are ready to compromise security for other "values" > I don't really understand the semantics of the content When we have a disclosure, we transform it in the machine-readable form (the one you've seen in the section 5). Then we present this disclosure in the machine-readable form - to other machines And to humans - in the form of icons. The basic implementation of the label is available here https://openethics.ai/label/ The machine-readable file and the visual label could be generated here https://openethics.ai/label/generate/ > in some ways it is similiar to securitytxt in syntax Indeed, the securitytxt is similar to the extent that they provide mechanism to the disclosure. In Open Ethics I've decided to bring the infrastructure for the signatures (PGP in the securitytxt implementation). PGP doesn't cover the case of disclosure withdrawal which is critical for the applications that > think you need a more detailed, more well worked set of examples Thank you! This is something that I should focus on, 100% @Gina, > Is this referring to Datasheets for Datasets? Yes, this is very close and linked. Let me explain. 1) Datasheets for Datasets, Google Model Cards, are integral part to describe the Training Datasets. We're augmenting it with Data Passport. The Data Passport has a purpose at depicting the origins of the training datasets by bringing a standardized approach to convey information about data annotation processes, data labelers profiles, and correct scoping of the labeler’s job. https://github.com/OpenEthicsAI/OEDP 2) We insist that the information about training datasets/decision logic is key in the disclosure, however should be augmented by to other pillars to call systems "disclosure-complete". Together they are: (A) Code libraries/components, including the approach to data processing and data transfer. (B) Decision Space, restricted vs unrestricted, plus information about failure modes of the system. (C) Training data and heuristics origins. 3) Transparency Protocol is not only about the process of the disclosure formation, but importantly about how it should be exchanged. The goal is so that transparency will not be only on the "surface", but will also tell us something about the components with their approaches, practices, processes, code put in place. @Larry, @John Thanks a lot, we've been looking at this work at W3C . This is close with the overall mission, but different in implementation. We're guided by a very similar set of assumptions. https://openethics.ai/manifesto/ What we believe is that similar statements should become widespread. However, it is not sufficient for a regulator or a community of "ethical" developers to start using them. They should be communicated in a standard manner. What is crucial is to unlock the bottom-up regulatory mechanisms, and to make sure that every user/consumer with no knowledge of security, privacy, fairness, bias, safety, architecture, etc, will start learning more about labels on the digital products. This has happened in other industries like food, construction, pharma, but not yet in the IT. Looking forward to your feedback and thank you a lot for your contributions and thoughts. Nikita Lukianets --- On 2022-02-01 14:34, John Curran wrote: >> On 31 Jan 2022, at 8:22 PM, Larry Masinter wrote: >> >> Check out >> https://github.com/w3ctag/ethical-web-principles >> which seems to have some momentum and some similar goals. > > Larry - > >> A very interesting initiative - thanks for sharing. >> >> After brief review, it would appear that the web folks have a >> signficiant advantage in their efforts to protect human rights on >> the web, as they are successful in affirmatively stating their >> desired outcome for its users – e.g. "The web must make it >> possible for people to verify the information they see” - this >> speaks directly to the functionality that must be provided to the >> users rather than the human rights implications of an application >> failing to do so… > >> > >> An interesting thought exercise lies in considering why the >> IETF/IRTF work in this area differs in this regard - I suspect it is >> not lack of desire, but inherent to dealing with many protocols and >> implied application contexts rather than one predominant model (i.e. >> the user/web browser context). It is quite reasonable that the >> abundance of protocols and user contexts results in pragmatic limits >> in postulating desired user functionality for an ethical Internet, >> but it does raise the question of whether more focused efforts for >> the most popular applications (e.g. email, messaging) could be >> undertaken in other contexts or for some reason are simply >> unachievable outside of the web context... > > Thanks again for the pointer to this work! > /John > Disclaimer: my views alone - may cause drowsiness - do not read while > operating heavy machinery. From nobody Tue Feb 8 07:49:30 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035663A10BB for ; Tue, 8 Feb 2022 07:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 vrU_VNMKy4GQ for ; Tue, 8 Feb 2022 07:49:00 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 C5FDD3A11CC for ; Tue, 8 Feb 2022 07:48:42 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id o25so13992271qkj.7 for ; Tue, 08 Feb 2022 07:48:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Vt4enJ+CZiY8/XuEjtSLiYQA4/v+J7yDocuEyQbxE9c=; b=E0cIAjTg6teCDLnY2rhh6uvI28ouMf7uEOYAIalUvXWKGbadjeSssdE8q5xDTDrATM 20ByhFjmijvaiaUPjlmbkjNhQytwbEcZ+yWrhxN/yhXY1neAmKzUmI7q0QxSReqrI0OV AP3PzvjrMxZdC+yC6pjgW1cQlvyG+EgZlQV34= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Vt4enJ+CZiY8/XuEjtSLiYQA4/v+J7yDocuEyQbxE9c=; b=JpLyoI6Ld5bLXDpIogM6s+C+iJ/YAjScGACI3xNDBEvYkTAqOM2swFuw863aIxshlu mAaLtpqihGnhOwkQorspTzffPaM/I/UfgCHK/2e9g9+kBCwiwlfSFRwD8ecdaskXcVhK NTAOTQEJWLqIs5eD3CHeYgtLS4pv5xlsioDVOLAR4hl7TP96531vhk5cgxzslEvm4p9R jAmOeESkj/o2PxijUXnxxkTUIMDsdnAzsiQmbFwI62s4931WUnyzh3/EyZ9rCu3kbGCQ LUGYPDRb3uSvj/vLROai+FJShxvLi+tASJGaX3N7JBVFo/zD83hSbjBtRe6wFqd7sav7 TpOg== X-Gm-Message-State: AOAM531byhcF2j+ehenRKGfzHmM238hJ+lF2pKT7X12TP7VV3LvKR7GO 7oG/Ctr1kb0I04lzOvKZWaqKNw== X-Google-Smtp-Source: ABdhPJwzrgmpnE//dqMPdQqKTulrrj++6GCihhpoi+gj09om2bv5z1PYVTsDFDfAqC5TtH5qSw0a3g== X-Received: by 2002:a05:620a:c96:: with SMTP id q22mr3000285qki.658.1644335320832; Tue, 08 Feb 2022 07:48:40 -0800 (PST) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id j15sm7596388qta.83.2022.02.08.07.48.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Feb 2022 07:48:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Sean Turner In-Reply-To: <164321863329.27385.6340387845625300575@ietfa.amsl.com> Date: Tue, 8 Feb 2022 10:48:39 -0500 Cc: dispatch@ietf.org, secdispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <164321863329.27385.6340387845625300575@ietfa.amsl.com> To: secret@ietf.org X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Secdispatch] Secure Credential Transfer (secret) BOF Virtual Meeting: 2022-02-10 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2022 15:49:16 -0000 Apologies for the multiple cross-posts. I have uploaded the slides for Thursday=E2=80=99s BOF. Cheers, spt > On Jan 26, 2022, at 12:37, IESG Secretary = wrote: >=20 > The Secure Credential Transfer (secret) BOF will hold a virtual = interim meeting on 2022-02-10 from 09:00 to 11:00 America/Los_Angeles = (17:00 to 19:00 UTC). >=20 > Agenda: >=20 > Intro > Use cases > Requirements > WG charter discussion: = https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.md= > Conclusion >=20 > Draft: = https://datatracker.ietf.org/doc/html/draft-secure-credential-transfer-03 >=20 > Information about remote participation: > = https://meetings.conf.meetecho.com/interim/?short=3Dd1a67502-8fe8-4fc2-bb9= b-f2e2f4594bb4 >=20 > The meeting will happen over Meetecho. To join the session, you will = need to use your IETF Datatracker (https://datatracker.ietf.org/) login, = which you should create ahead of time if you don't already have one. If = you have forgotten your IETF Datatracker password, you can request a = reset (https://datatracker.ietf.org/accounts/reset/). For more = information, see the Meetecho guide for participants = (https://www.ietf.org/how/meetings/technology/meetecho-guide-participant/)= . >=20 > BOF Request: = https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-bof-req= uest/ >=20 > Description: >=20 > We presented the secure credential draft to Dispatch on Monday of IETF = week (2021). There was a lot of interest, but folks asked for additional = detail on the problem statement, requirements, and use cases. It was = decided that we weren=E2=80=99t ready to form a WG right away and = instead endeavored to schedule a BoF to review the above items prior to = forming a WG. The goal is to allow users with secure credentials on = their mobile devices to be able to shares entitlements that these = credentials grant to other users. This would be achieved by defining and = standardizing a protocol that will facilitate such credential transfers = from individual to individual. The protocol will leverage a =E2=80=9Crelay= server=E2=80=9D to transfer data from sender to recipient. The scope of = the transfer is limited to a single origin device and a single = destination device. This system does not exist today in a = standards-based, cross-platform and cross-channel capacity. The goal of = this BoF is to answer some of the questions that came up during the = Dispatch meeting (such as, why can=E2=80=99t these credentials simply be = lifted and cloned and then sent to the recipient?). We also want to = provide additional detail into the applicable use cases, and some of the = security and privacy requirements for the solution. The ultimate goal is = to form a WG to discuss the initiative in an ongoing capacity. >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From nobody Tue Feb 8 10:17:52 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B9E3A0E7E for ; Tue, 8 Feb 2022 10:17:50 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 QCssw4CVyHls for ; Tue, 8 Feb 2022 10:17:45 -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 8C71F3A0FCE for ; Tue, 8 Feb 2022 10:17:34 -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:Subject:To:From:Date; bh=Osbx5QsYoqCcUAlGeOnH3timFVy/8dxIoL752v3Uok4=; b=Bk+XHvL1qCPHmlgCO50wh4zT3UlzbyJB1R/a7oUG9GBz7Zr5auw88eLLYAIFO5DjflHksw4WTanw2bZuxAWEpYcYnmA+9ejZuKjnzbDi+wK50f8SrRRmCIsquRmbRbRDxpvngAmGWw2bmx4eTEBzSXKH589p+gW7LTb2ocWKSYY=; Received: from 50-79-151-250-static.hfc.comcastbusiness.net ([50.79.151.250]:6534 helo=[127.0.0.1]) by ocean1.commercebyte.com with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1nHV3T-0005ky-Gk for secdispatch@ietf.org; Tue, 08 Feb 2022 13:17:31 -0500 Received: from [206.81.2.95]:7120 (helo=[127.0.0.1]) by [172.16.0.48]:49698 (localhost) with VESmail ESMTP Proxy 1.59 (encrypt=FALSE mode=FALLBACK); Tue, 08 Feb 2022 13:17:31 -0500 Date: Tue, 08 Feb 2022 13:17:28 -0500 From: Jim Zubov To: secdispatch@ietf.org User-Agent: K-9 Mail for Android Message-ID: <0075B437-024A-4D84-ABD7-92FE8DAFA59F@commercebyte.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----HCVAYVS113LYJRREFO6IKYF4VX2H3G 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: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2022 18:17:51 -0000 ------HCVAYVS113LYJRREFO6IKYF4VX2H3G Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Please consider the following draft: https://datatracker=2Eietf=2Eorg/doc/draft-zubov-snif/ The document describes a set of protocols for publicly trusted serverless = TLS that can be used as an end-to-end IoT security solution=2E The solution had been tested in pre-production=2E The complete source code= is in the public domain - https://github=2Ecom/vesvault/snif Any feedback, suggestions, and recommendations of an IETF group adoption a= re welcome=2E Thank You - Jim Zubov VESvault Corp CTO / Co-founder ------HCVAYVS113LYJRREFO6IKYF4VX2H3G Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Please consider the following draft:

https://data= tracker=2Eietf=2Eorg/doc/draft-zubov-snif/

The document describe= s a set of protocols for publicly trusted serverless TLS that can be used a= s an end-to-end IoT security solution=2E

The solution had been teste= d in pre-production=2E The complete source code is in the public domain -
https://github=2Ecom/v= esvault/snif

Any feedback, suggestions, and recommendations of a= n IETF group adoption are welcome=2E


Thank You -

Jim Zubo= v
VESvault Corp
CTO / Co-founder

------HCVAYVS113LYJRREFO6IKYF4VX2H3G-- From nobody Wed Feb 9 11:16:31 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@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: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch 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:20 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@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: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch 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 09:14:26 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBFE3A0E37; Thu, 10 Feb 2022 09:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.677 X-Spam-Level: X-Spam-Status: No, score=-7.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoKZCtvPskFD; Thu, 10 Feb 2022 09:13:25 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40063.outbound.protection.outlook.com [40.107.4.63]) (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 603C33A0F42; Thu, 10 Feb 2022 09:13:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g89yVsMF1T8pgG6eahHsO0bevGFyQcsiMWSyrDRBwJtsTNBaFzT1ku75eJUdY0UNSySLkIxQokw82rEQZN1mRhGquA+uIvdqAKBPvvwWhmro482BiNIqPZNqO99+O4FhfM+8lxtrdrNrMHM8f9iZg3Sdh/enJBUhW58OtuLVisRYUYdybs2lgMS5GSJBNoPQMtj3erWsgIyC5pz2if0j1Z5Zc4GFh4y7ADrYbO8CCLIlaQtrb5+FhyH7BiomOnv72GF+GqGwJBZ/YRCZ+BYE+ov9XlQb+gb9O1cYGlgk4qFyBfk4M5MqBrdvHRo+i7jXobu7JvLVHMelmqCarMX6yg== 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=Ow8RHGbSChg0A7qhwQeRfYlsYMugvoOcQ9DvYJf4vLY=; b=XqyJaaUxnjLTeQzGoBQAQpu1dFQCk/FgQ0AB2kiLNV+/LWxHrSd0NDCgSVBrqKeoeIb0ffZdvrIIFAd0ZFXL+zwtMKKaK7s+xwMDxC2olcBGjch7T3lrfl9QCU9yAlxjH4DfGkerTu9K935BXGxZ8Oa/KLUgJh6c6nucMqdLIAmPpq0W0sxmlfZyNqPYcs6lDzsrKYZe6joIn+iNLq6mnln/wKCiilGPiRdtb6yrQz3FXtMQhC9RjiPYtZFRkvJQid+yjdo0ckizazw4xr8XxokZ/1kKQKt/mCLOszkXBeRypUH4OzdZ1bBaL5X9zP39B3kLxkE+NjFoKhlCxLqPCQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ow8RHGbSChg0A7qhwQeRfYlsYMugvoOcQ9DvYJf4vLY=; b=E8cArHBWHBMAnDnSi1nsTOVy53OL8Uvhk8qkYZKZHfyPsGR5WdA/N1JbY5Qw1mXRFkl88vOS1JzkQ+mq1Kd+54v36uzYE74+ngcgoqteCQCar/hjZl3wzvS9fQEa7jwEUl4Uj/X0oniBm9qNA6WEYfwN92603o2LSxbP9ezFNDs= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by DB7PR07MB6012.eurprd07.prod.outlook.com (2603:10a6:10:37::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.10; Thu, 10 Feb 2022 17:12:52 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::b1e2:6c17:3ba8:9fdc]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::b1e2:6c17:3ba8:9fdc%5]) with mapi id 15.20.4995.006; Thu, 10 Feb 2022 17:12:52 +0000 From: Francesca Palombini To: "dispatch@ietf.org" , "saag@ietf.org" , "secdispatch@ietf.org" Thread-Topic: [Secret] Secure Credential Transfer (secret) BOF Virtual Meeting: 2022-02-10 Thread-Index: AQHYEttrGDmcw5z0QkCuZIEBWQK9xayNHCMw Date: Thu, 10 Feb 2022 17:12:52 +0000 Message-ID: References: <164321863329.27385.6340387845625300575@ietfa.amsl.com> In-Reply-To: <164321863329.27385.6340387845625300575@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0b0aadd1-bb1d-46c0-1e05-08d9ecb89289 x-ms-traffictypediagnostic: DB7PR07MB6012:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: AddXQz/Y2DgU7Rwem8bQN10kACajmyqBxfDGcpErUb0yu7vR28lKYpb+mg3Ms16VZWHCjjb4cFutxOdqYyjR19lV82cJ9y1fCw1FbsGMk3/tLA17hK+Ser2AELZwWDxF636DO38XhDdlJL1P/uUGXs4b3mZTJ6Yx2y8EhpWihxKnxCkrYZipT9aFD1M6BtGlfkIRyRLY+Jji1jQ4ma6amt0/yiDMTck+YVYhBvoCAdFoi38bLjDGFjGtYxhspVj7vi80ksbySiknvj0TQVs7M7Go4yr1UKdHVxcLQD6aQ57I8cMP1Z5dSN09LfdITxNDPJoulBFCoQOj6BmEPRoMhhzHUrK19WMRDlM1Bs/eYDn51nz2e883L24VxAfDijKFy/CRejap1kf+5I+sr4S9Y97YkSSOoXNC08eyAZDX/P14yWQkl8mRX7U9aO35eHuug8nQKEOHlDz++Tw88aSrrmy5JCQilhsMwm3E/i2HEhptSX0L+ZQszRAhmDUDaLEVizvqBMqzM/S/1/f0QLh/Z/FXWvX/YOTIb2wkI7KOAsoDeSoKcv2yit/adRMUbAEqt9GvqjqnWSQHn8mwC/G50GJcDVOz12nOj8j6ILrHO7N/KGGM54QkLRVPu5/0HIgt+doG1L/Vkj8wMe7U8juorZSaosFQjLFX2hHmG3dL9J+dTXaZ6BYouWiZhFfMnVUf9LNpjb8/t66Oh/dhoEJY6YoJDbYpKdjWrmcjGu/XRarZ8CBQqUON3QNXBCDBQYIwm2yyZPFYwcEgQZEI9fQah1u19YlnotiikDeYTRnbm+MSHt4mUr2O+gNdrmfuaS/5LDq9QNDbKxU3TIXqz6FL/bzjl2/hPT04z8RGMqPUyj8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(55016003)(38070700005)(966005)(186003)(5660300002)(122000001)(82960400001)(110136005)(316002)(53546011)(450100002)(71200400001)(33656002)(83380400001)(2906002)(166002)(38100700002)(64756008)(76116006)(8676002)(8936002)(86362001)(508600001)(66946007)(6506007)(52536014)(7696005)(44832011)(9686003)(66556008)(66446008)(66476007)(91956017)(219293001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 2 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?zcOBpsUOrgbDYxX0YmOu7kvVn1Il8ys/qtVHpAb8SFELiSU4lGHjlPYL?= =?Windows-1252?Q?WAREgndYKV6iG5A4GJPbVciIBFZ7Th6fhS29rdf9hDTGmCAS3jm2ck2a?= =?Windows-1252?Q?TQwsfR/J++poCmKXdnsAyAvX6NK+eO5SC+q3aGHjw7xSVFbZRQJN6kJp?= =?Windows-1252?Q?9aTOtrucsfp6r9ohwZ5xFH9SoY24DRB54r/zUicbiPA+V9LqBisl5CVr?= =?Windows-1252?Q?xhbbDy4xgKzK5oJbWCUiyAGultsMQ86MFNj8tph4EzLHTtmIiO8U/JnE?= =?Windows-1252?Q?61hq3B7A5QVhX9l2Q7GLfEgUYM4cdw3lrqy72PoVyVh1s+ZQ1Fd+5OZM?= =?Windows-1252?Q?vMGqEGbnYBMdSGVdfD/71+LaM99BOUudxI9kGf6oeyM0CCLAEhnAtoKf?= =?Windows-1252?Q?wWFpDjqhSUPxmBHiPW0hXP4oixyhZM8znJYaVqEUO9PTIRl+iuF08skk?= =?Windows-1252?Q?uveay9H43kbgw4hwitMnlec6Y4Qny9Qj6MyJgysZa2i3tuX9/RHtl4Hw?= =?Windows-1252?Q?0hsOlfPClby2wxaW9OnmxuAWX8CIzJ52Q8vBWBh9KQS69ahr25MMFJLc?= =?Windows-1252?Q?FIwHaLLg0GI87QzSxvTRh8mgD/dGOa4TqtNSudoHLqJd28Hgb/Bk7cTK?= =?Windows-1252?Q?AKN8aS1wPkGZ96FRc9O19Yve4rpx4s4tw41DoQdhTLFH+9rMl2YKOy8o?= =?Windows-1252?Q?OPFaLRc1TWfTixlv0IYP6rZ/nVze6KDSbYN5PA0HRt7muHGFmLa2Y39D?= =?Windows-1252?Q?Gf4tSBMylw3B5tpXGHuEFARc+DUL0j6Uijee/GJLXTogtTFbITrynSZh?= =?Windows-1252?Q?HD5EB08Wcr4jzkSMewmzpBWbWOJvGEcHMtLOqFlpT+OvlQHi5h6JlHii?= =?Windows-1252?Q?68qSxPnaMgjYeXD78FaEx7NI3cTzruD9Q9AFBspHV9ZLAkq2QgkLBMyl?= =?Windows-1252?Q?HUCtEck1Six0uq8yn78YNgvnMylvzGJBiWbxc/MHFN4dDUdKAB87GBpf?= =?Windows-1252?Q?40lYQScgPc5bScvX3oE5JTtFz9kp6VLzTdejpmyuFwKQjLR3lQ/Oyxt2?= =?Windows-1252?Q?YqP2ORdgfC6l47i0ZXP30o0LSXNDg6wbiKJnNtYWSh/O9u8zT3uxxKPZ?= =?Windows-1252?Q?TV23Wa7tJN/v4U1qNlrpjSVwTNMkyR2Sjc99MFDnFmPysFhz7PpaMgsv?= =?Windows-1252?Q?ewSIbnGdMUQCE9QK55Zec5EzuoqZFWdxCAjk9gpuB/uKCEKvlMY2U5q/?= =?Windows-1252?Q?mEll/v9pmGG1Vr8pG6r+jaOYiiseaIr656hn78wIcYNIjUwnfbbN6UiD?= =?Windows-1252?Q?zF+DwNzA2L9YXhMMy1iWToloyEL6xcu7+CD0vpoYOQSa68Rp9+u1pvZg?= =?Windows-1252?Q?ACgmGtODBwKhsRAq1yk1ZeKaeNFy/oXk5cfE/usCi8A753we59Ly9F04?= =?Windows-1252?Q?lurBs3y4pn8WehKnFdccj2cekzjSLUjbEL6RU+rMJU/B03uBGw0WCks6?= =?Windows-1252?Q?uQCBpUWD10X7f2QRUb0ztXXpMjCMLOvC9OO3Hnr6BuYX0wkXtpyw7lKc?= =?Windows-1252?Q?h7o2GJ6WfpBO+xNHbQMWTFcMrOx5jKAIamSmOqS2JnMl7eb+SmMVF2pm?= =?Windows-1252?Q?bDuMoh5Vyc7eCye9J20Wndzpy0OvIak/+U312Ny6BZpqLU2Av+skipgX?= =?Windows-1252?Q?m0NwY+scYlWyEBHL+64A/QW/0IdUxiuLwCGcMcrMprbf0Wz1AZkbjjRo?= =?Windows-1252?Q?Q3yxzKOi0dRsLFiVqQd/agwQIfZt1z2vh/v+1vPBkMru5WUyQ6mImgFJ?= =?Windows-1252?Q?UJqB8hWhgDOkwu24PMXH/O0622c0Gp89mkispXTkoIgGn3pgRNaDB4LF?= =?Windows-1252?Q?itwNU/Pn+PYmcpKS1F0zdP8bYiNrzDqov8UsWykNTNUJPuzAbyNmoxH5?= =?Windows-1252?Q?FencpW+A?= x-ms-exchange-antispam-messagedata-1: Uumxkk9gMlZv2xSmsQD0CveSZS3tAmrSLmw= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB421725F4BC460ED0873AF5FA982F9HE1PR07MB4217eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0b0aadd1-bb1d-46c0-1e05-08d9ecb89289 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2022 17:12:52.5139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Da0xs91QgzV622T0GpTbrmKgLQLqh4PFvzmTA2MdPNVoMk0rP0gkObhpsyDzoQ8mUFGOj9GOF9Kb19lWd55pBfEoB0BdkTYInbNcB4KPo/CNvRt2NQSuo22chjOR7cF9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB6012 Archived-At: Subject: Re: [Secdispatch] [Secret] Secure Credential Transfer (secret) BOF Virtual Meeting: 2022-02-10 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2022 17:13:30 -0000 --_000_HE1PR07MB421725F4BC460ED0873AF5FA982F9HE1PR07MB4217eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable FYI, happening now. Francesca From: Secret on behalf of IESG Secretary Date: Wednesday, 26 January 2022 at 18:37 To: IETF-Announce Cc: secret@ietf.org Subject: [Secret] Secure Credential Transfer (secret) BOF Virtual Meeting: = 2022-02-10 The Secure Credential Transfer (secret) BOF will hold a virtual interim mee= ting on 2022-02-10 from 09:00 to 11:00 America/Los_Angeles (17:00 to 19:00 = UTC). Agenda: Intro Use cases Requirements WG charter discussion: https://github.com/dimmyvi/secure-credential-tra= nsfer/blob/main/charter.md Conclusion Draft: https://datatracker.ietf.org/doc/html/draft-secure-credential-transf= er-03 Information about remote participation: https://ws.conf.meetecho.com/conference/?short=3Dd1a67502-8fe8-4fc2-bb9b-f2= e2f4594bb4 The meeting will happen over Meetecho. To join the session, you will need t= o use your IETF Datatracker (https://datatracker.ietf.org/) login, which yo= u should create ahead of time if you don't already have one. If you have fo= rgotten your IETF Datatracker password, you can request a reset (https://da= tatracker.ietf.org/accounts/reset/). For more information, see the Meetecho= guide for participants (https://www.ietf.org/how/meetings/technology/meete= cho-guide-participant/). BOF Request: https://datatracker.ietf.org/doc/bofreq-secure-credential-tran= sfer-bof-request/ Description: We presented the secure credential draft to Dispatch on Monday of IETF week= (2021). There was a lot of interest, but folks asked for additional detail= on the problem statement, requirements, and use cases. It was decided that= we weren=92t ready to form a WG right away and instead endeavored to sched= ule a BoF to review the above items prior to forming a WG. The goal is to a= llow users with secure credentials on their mobile devices to be able to sh= ares entitlements that these credentials grant to other users. This would b= e achieved by defining and standardizing a protocol that will facilitate su= ch credential transfers from individual to individual. The protocol will le= verage a =93relay server=94 to transfer data from sender to recipient. The = scope of the transfer is limited to a single origin device and a single des= tination device. This system does not exist today in a standards-based, cro= ss-platform and cross-channel capacity. The goal of this BoF is to answer s= ome of the questions that came up during the Dispatch meeting (such as, why= can=92t these credentials simply be lifted and cloned and then sent to the= recipient?). We also want to provide additional detail into the applicable= use cases, and some of the security and privacy requirements for the solut= ion. The ultimate goal is to form a WG to discuss the initiative in an ongo= ing capacity. -- Secret mailing list Secret@ietf.org https://www.ietf.org/mailman/listinfo/secret --_000_HE1PR07MB421725F4BC460ED0873AF5FA982F9HE1PR07MB4217eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

FYI, happ= ening now.

&nbs= p;

Francesca=

&nbs= p;

From: Secret <secret-bounces@ietf.org> o= n behalf of IESG Secretary <iesg-secretary@ietf.org>
Date: Wednesday, 26 January 2022 at 18:37
To: IETF-Announce <ietf-announce@ietf.org>
Cc: secret@ietf.org <secret@ietf.org>
Subject: [Secret] Secure Credential Transfer (secret) BOF Virtual Me= eting: 2022-02-10

The Secure Credential T= ransfer (secret) BOF will hold a virtual interim meeting on 2022-02-10 from= 09:00 to 11:00 America/Los_Angeles (17:00 to 19:00 UTC).

Agenda:

    Intro
    Use cases
    Requirements
    WG charter discussion: https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.md<= /a>
    Conclusion

Draft: https://datatracker.ietf.org/doc/html/draft-secure-credential-transfer-03

Information about remote participation:
https://ws.conf.meetecho.com/conference/?short=3Dd1a= 67502-8fe8-4fc2-bb9b-f2e2f4594bb4

The meeting will happen over Meetecho. To join the session, you will need t= o use your IETF Datatracker (http= s://datatracker.ietf.org/) login, which you should create ahead of time= if you don't already have one. If you have forgotten your IETF Datatracker password, you can request a reset= (https://datatrac= ker.ietf.org/accounts/reset/). For more information, see the Meetecho g= uide for participants (https://www.ietf.org/how/meetings/technolo= gy/meetecho-guide-participant/).

BOF Request: https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-bof-requ= est/

Description:

We presented the secure credential draft to Dispatch on Monday of IETF week= (2021). There was a lot of interest, but folks asked for additional detail= on the problem statement, requirements, and use cases. It was decided that= we weren=92t ready to form a WG right away and instead endeavored to schedule a BoF to review the above items pr= ior to forming a WG. The goal is to allow users with secure credentials on = their mobile devices to be able to shares entitlements that these credentia= ls grant to other users. This would be achieved by defining and standardizing a protocol that will facilitate = such credential transfers from individual to individual. The protocol will = leverage a =93relay server=94 to transfer data from sender to recipient. Th= e scope of the transfer is limited to a single origin device and a single destination device. This system does n= ot exist today in a standards-based, cross-platform and cross-channel capac= ity. The goal of this BoF is to answer some of the questions that came up d= uring the Dispatch meeting (such as, why can=92t these credentials simply be lifted and cloned and then sen= t to the recipient?). We also want to provide additional detail into the ap= plicable use cases, and some of the security and privacy requirements for t= he solution. The ultimate goal is to form a WG to discuss the initiative in an ongoing capacity.

--
Secret mailing list
Secret@ietf.org
https://www.ietf.o= rg/mailman/listinfo/secret

--_000_HE1PR07MB421725F4BC460ED0873AF5FA982F9HE1PR07MB4217eurp_-- From nobody Thu Feb 10 10:03:17 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@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: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch 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 12:35:30 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84863A112E for ; Thu, 10 Feb 2022 12:35:28 -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, FREEMAIL_FROM=0.001, 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=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 q_4wn0ZOHNoO for ; Thu, 10 Feb 2022 12:35:23 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2200D3A0B22 for ; Thu, 10 Feb 2022 12:35:23 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id s18so8878734ioa.12 for ; Thu, 10 Feb 2022 12:35:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=13xKg92MhHFzK342CTbRgrhby/xJRXgazddJdsZFZjI=; b=JhWe76FG8BHDocPbSDP+wPGsmq5542eQA4fQH2XfcipTG2O1huTXW3Blix1BlQxsQ4 PYX5mFLhZjNuKxhu+ibx3AXA1xi0Ftlv1ntiXS5SA5CS2uQWcHM3u2OC7k69JMIaKSBS KO+z27n/HO6YjXyNetDzA33UtX4SuFfUwTtgsElCCj5eq2x6BBbwR6M+pp+ZX8vnIEx2 hur2Om51tr+jIhsL3MsHVSCI7pylunBVSfkNsK2ebbclgnJX46YATfC1/WKYubQZ/ZWc 2uQBUwIkmoDz5Cu5jIMh9RcTdxCtiFgt/XmFgI9nCsPV08MPg3u8vyLuUAsh8GvFavGZ pSog== 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=13xKg92MhHFzK342CTbRgrhby/xJRXgazddJdsZFZjI=; b=bOre6KA5HTSCzuvGmi21009gbWzyVW1DHR3bHbkIVqdP/VffYEow06EnyDQyoQ0FLe yQVKwCAYpWhobXNzF8YiV7WdGMxtQfVTUktRWDyowesjpcA0TT/crXTNWZojj3C+epJ7 9PS5dh5s08qp+HDw0hak5xHC72PEaiBuc4dZxJ+xtf6JT6j7CAL3FngMKSHaXfhlA058 DUHcZMXWKjx9ozri1NJpcdnID9fqxRm9ZsojtLL0+ADFPZpe28thpGiRtlSikak8g1eR BCxG8M1KIWX/cSUiu4JyPVkMk2h6f0OgVUxQTVjEuqwIPh37nmE+mA9StAhlpAbGO4x/ bLNA== X-Gm-Message-State: AOAM530wEp4Wwv9QmPO9xEARS6GSicWLsNOaAjKj4Ap1EZWnL7jnC26h 4frtmv+rPXKC3S5PTGkSldWPF0FdiE01/czSh9j7xjr50lY= X-Google-Smtp-Source: ABdhPJxDsqh353Y/Qm/IHh/GdvlsKsUIIxK88bPqXOfV5y5U3+0YVFUsAogbDFBzFCR4aKIzMBYNewgCcEF0uIHA1x4= X-Received: by 2002:a05:6602:2d95:: with SMTP id k21mr4768502iow.48.1644525320201; Thu, 10 Feb 2022 12:35:20 -0800 (PST) MIME-Version: 1.0 From: Fabien Imbault Date: Thu, 10 Feb 2022 21:35:09 +0100 Message-ID: To: secdispatch@ietf.org Content-Type: multipart/alternative; boundary="00000000000088ed3a05d7afe3f4" Archived-At: Subject: [Secdispatch] Biscuit tokens X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2022 20:35:29 -0000 --00000000000088ed3a05d7afe3f4 Content-Type: text/plain; charset="UTF-8" Hello, Following previous discussions in the GNAP working group (for instance : https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/16), i'd like to know if there would be interest to support a wider variety of tokens, especially if they provide special properties (compared to JWT). In particular, there's been some work with Geoffroy Couprie on https://www.biscuitsec.org which comes with a preliminary specification (which relies on Ed25519 signatures, datalog logic and protobuf serialization - could those dependencies be an issue?) and various implementations. It allows new use cases such as decentralized authorization. Best, Fabien (co-editor of IETF GNAP) --00000000000088ed3a05d7afe3f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,=C2=A0

Following previous discuss= ions in the GNAP working group (for instance : https://github.com/ietf-wg-= gnap/gnap-resource-servers/issues/16), i'd like to know if there wo= uld be interest to support a wider variety of tokens, especially if they pr= ovide special properties (compared to JWT).

In par= ticular, there's been some work with=C2=A0Geoffroy Couprie on=C2=A0https://www.biscuitsec.org which comes with a preliminary specificat= ion (which relies on Ed25519 signatures, datalog logic and protobuf seriali= zation - could those dependencies be an issue?) and various implementations= . It allows new use cases such as decentralized authorization.
Best,
Fabien (co-editor of IETF GNAP)
--00000000000088ed3a05d7afe3f4-- From nobody Thu Feb 10 15:23:34 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@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: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch 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 Wed Feb 16 07:45:48 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3E03A1384 for ; Wed, 16 Feb 2022 07:45:46 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 Nct3PzJ1_zkH for ; Wed, 16 Feb 2022 07:45:42 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 134F33A1389 for ; Wed, 16 Feb 2022 07:45:41 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id q4so625828qki.11 for ; Wed, 16 Feb 2022 07:45:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:mime-version:subject:message-id:references:to:date; bh=/O/wpgJR3vbV8kwaoFaFdNHfE5peq7utooFRod2adQ4=; b=DlxIp26Sj2B2xW2QTGC/jKBhgEm/HSpZfS9yWa/NjuOEbI2uJWVxkC6H6wra58Rp7L /xjvlh0L7TCMwi62OVAs+Pc2sxipTwR5X8kki+mfgWrrFSFT15o/pvabYXYpYu3aide/ m0/kbg1ULAzKWswiJP/POo2QRIreSyTb882i8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=/O/wpgJR3vbV8kwaoFaFdNHfE5peq7utooFRod2adQ4=; b=AZPf2e+HuX+YEppdB6/1jk5QvhartgnSRysP16rflh8idK0DBEmLhI6319dn8vgbIi kvEv0uXvHLuupSB+7KTmq49t1y4tJu08Y51gudaEiYZpWLTuuJ5CtIUKR+z45++SSxIz SXglJwtbMuf/3QCulFZsNftVd9ffYNHKi3155xdXe5O/YOiO3h1LQdZeAgKQKqfzQuWm 8lgV8AIG6PwE4mA0o9ALQgmBigByIyyjDlL9Zf7+R5Zw77Bo3lHFt8Q0tuO54FSe4BbC FQp1U34/MN9HuZpfVD4yL0l1OouVVpvkqv6x03DCScSTOI9zToADTAYKMS/qR5NGNb8D ySKg== X-Gm-Message-State: AOAM533/02c29hrayWu5H4dokT/Ja+hatDsOo9ORLbY/SIOrImvPC4W/ 6Aq+IPB3rZVgmin45ydgYF9jb22cg7uOUA== X-Google-Smtp-Source: ABdhPJzxo4liNVZ4997M84fuA+GZd2zDFeJuha/d2DDNK6uvezIIvMGwaTvUkFpRanJPaedKxMjEjA== X-Received: by 2002:a05:620a:164a:b0:47d:1003:5062 with SMTP id c10-20020a05620a164a00b0047d10035062mr1539113qko.17.1645026339587; Wed, 16 Feb 2022 07:45:39 -0800 (PST) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id h5sm22689976qth.54.2022.02.16.07.45.38 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Feb 2022 07:45:39 -0800 (PST) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_CD3FD108-A955-416D-8139-AF2BBE6838C1" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-Id: References: <164349256362.1241.1171718350421029364@ietfa.amsl.com> To: secdispatch@ietf.org Date: Wed, 16 Feb 2022 10:45:38 -0500 X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: [Secdispatch] Fwd: I-D Action: draft-ciphersuites-in-sec-syslog-01.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 15:45:47 -0000 --Apple-Mail=_CD3FD108-A955-416D-8139-AF2BBE6838C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi! We have revised this based on some commented we received from Tom = Petch on the syslog list. We welcome comments. Cheers, spt > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-ciphersuites-in-sec-syslog-01.txt > Date: January 29, 2022 at 16:42:43 EST > To: > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Updates to the Cipher Suites in Secure Syslog > Authors : Chris Lonvick > Sean Turner > Joe Salowey > Filename : draft-ciphersuites-in-sec-syslog-01.txt > Pages : 8 > Date : 2022-01-29 >=20 > Abstract: > This document updates the cipher suites in RFC 5425, Transport Layer > Security (TLS) Transport Mapping for Syslog, and RFC 6012, Datagram > Transport Layer Security (DTLS) Transport Mapping for Syslog. It > also updates the transport protocol in RFC 6012. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ciphersuites-in-sec-syslog/ >=20 > There is also an HTML version available at: > = https://www.ietf.org/archive/id/draft-ciphersuites-in-sec-syslog-01.html >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ciphersuites-in-sec-syslog-01 >=20 >=20 > Internet-Drafts are also available by rsync at = rsync.ietf.org::internet-drafts >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_CD3FD108-A955-416D-8139-AF2BBE6838C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi! = We have revised this based on some commented we received from Tom Petch = on the syslog list. We welcome comments.

Cheers,
spt

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = I-D Action: = draft-ciphersuites-in-sec-syslog-01.txt
Date: = January 29, 2022 at 16:42:43 = EST
To: = <i-d-announce@ietf.org>
Reply-To: = internet-drafts@ietf.org


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.


=        Title =           : Updates to = the Cipher Suites in Secure Syslog
=        Authors =         : Chris Lonvick
=             &n= bsp;           &nbs= p;Sean Turner
=             &n= bsp;           &nbs= p;Joe Salowey
Filename =        : = draft-ciphersuites-in-sec-syslog-01.txt
Pages =           : 8
= Date =            : = 2022-01-29

Abstract:
=   This document updates the cipher suites in RFC 5425, = Transport Layer
  Security (TLS) Transport = Mapping for Syslog, and RFC 6012, Datagram
=   Transport Layer Security (DTLS) Transport Mapping for = Syslog.  It
  also updates the transport = protocol in RFC 6012.


The = IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ciphersuites-in-sec-sysl= og/

There is also an HTML version = available at:
https://www.ietf.org/archive/id/draft-ciphersuites-in-sec-syslo= g-01.html

A diff from the previous version = is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ciphersuites-in-sec-s= yslog-01


Internet-Drafts are = also available by rsync at rsync.ietf.org::internet-drafts


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

= --Apple-Mail=_CD3FD108-A955-416D-8139-AF2BBE6838C1-- From nobody Thu Feb 17 09:37:50 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A515E3A0D90 for ; Thu, 17 Feb 2022 09:37:47 -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 Kd2pgvji2VRJ for ; Thu, 17 Feb 2022 09:37:42 -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 EF66C3A0D97 for ; Thu, 17 Feb 2022 09:37:37 -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=lYlBpTbGB2NV7fe7oz+U6S2KGHQH/mradzsIS6ReqcY=; b=WlRV35VB86yPLvaC2Nwn4YFEN7RqzOvTQqVu6ofFppNukwyU+S9yrX6aVvj8nCM8Q3FHmEJhE2cDQrkBBxTWRRozIynA2Mop/vnqdOnoCsmUerBrJCyFo8+FWCO9jt/pptPDk5OGxo0qT2mHG21Yz/nZ8CsGlyBOwv6Uq/RQT1g=; Received: from [47.204.174.73] (port=47500 helo=[127.0.0.1]) by ocean1.commercebyte.com with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1nKkil-0002JP-In for secdispatch@ietf.org; Thu, 17 Feb 2022 12:37:35 -0500 Received: from [206.81.2.95]:7120 (helo=[127.0.0.1]) by [192.168.254.152]:43186 (localhost) with VESmail ESMTP Proxy 1.59 (encrypt=FALSE mode=FALLBACK); Thu, 17 Feb 2022 12:37:35 -0500 Date: Thu, 17 Feb 2022 12:37:26 -0500 From: Jim Zubov To: secdispatch@ietf.org User-Agent: K-9 Mail for Android In-Reply-To: <82ED3C66-583B-4A1A-A98A-5AE7E40541E2@commercebyte.com> References: <82ED3C66-583B-4A1A-A98A-5AE7E40541E2@commercebyte.com> Message-ID: <8034BD7C-7D82-4B1E-9A32-18A9493370A3@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: [Secdispatch] Fwd: New Version Notification for draft-zubov-snif-04.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2022 17:37:48 -0000 A new revision of the SNIF draft, according to Michael Richardson's sugges= tions=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 Wed Feb 23 02:37:14 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@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: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch 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:52 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@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: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch 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:22 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@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: [Secdispatch] [Iotops] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch 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:37 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@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: [Secdispatch] [Iotops] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch 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 Thu Feb 24 12:06:37 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433F23A0597 for ; Thu, 24 Feb 2022 12:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.896 X-Spam-Level: X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.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 JcvcgooYyxFO for ; Thu, 24 Feb 2022 12:06:30 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 C42F23A02BB for ; Thu, 24 Feb 2022 12:06:30 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id h16so4070567iol.11 for ; Thu, 24 Feb 2022 12:06:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gM8/61TftRvIdvEjJQv2WzBw5rYAVJZghZ9MWOBBpJI=; b=UYfO0+DJriGDuJxmPr35xb7LO+AHvwN6BjGP1JsC/9xlFwn6VfHc6cvWeVMIe1m2Pr kUV1FO4NF+PAtXbfmNLUHmszOVpw5WsRXxelvok5lTSZhFtfESRkBt3v9kXXPw9JJvxn 6GKk6H/K3M5DVwHH82UbagMv6NPMrq5oxHRzTEaETCs0VzVA3vHDVOLuS8IPblDkmrRI PZWyzivSSQ1LRtEQyh8rsdKs/aUqeoukjZ7edEKWfWl0NgfbbFv4YzN/npLmIL60PO69 jYvGPVA1f8NjtNGVVY++NqEZGmSDsc1606GNz2WmEmvWoMm9/hWJj959/lauX+tAx7qT Ievw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gM8/61TftRvIdvEjJQv2WzBw5rYAVJZghZ9MWOBBpJI=; b=HIzQLU72PGkmAAqNdU0AcihiEH/I9bWpAPm2WVL/q50TJZHKi/uofxYNsucs9diowy SMO8wG/fanQF9VfVPIjfbKeIllhQss6sOqMmVwZ0fVLciddBvShyQbiOa656i2ocTK+E OWh9e+axSGQIa69+REibJwOT1BtgTJv43RK8IYDPItn/nnDZxeQaHlBY7v3iDJzWTOgm RBrawgjPTSZHBlXZwGFHk18RenUvYbzagJw5pu2Bk3CdixSotkdu01uY4Rbbkr/u6nqV ihfxGQtfOw/Kr+cN7E0uBMAEalGX+aciY1W2EkgrbhGeBM+gDcurFHxLewIC3vFAoZWG ltGw== X-Gm-Message-State: AOAM533azAsbVpkaVW0UAL6j1zv0XunBfVcO6z1dSY5GNYLPPufe7zRa 8smLCKLg9Cr9PG8B7sKooxxLqRV2dEFBOyBs0VWS+F4a0nYuow== X-Google-Smtp-Source: ABdhPJz9Mo2/MO7gAuYgXRnKWeNq4VKEyp8aUsQJqXateltmL668zrgnOsbcqLwbzRrrYbJUF/xmamBMZAg4Hv21I9M= X-Received: by 2002:a02:cc26:0:b0:30f:ce14:5241 with SMTP id o6-20020a02cc26000000b0030fce145241mr3296004jap.94.1645733189755; Thu, 24 Feb 2022 12:06:29 -0800 (PST) MIME-Version: 1.0 References: <0075B437-024A-4D84-ABD7-92FE8DAFA59F@commercebyte.com> In-Reply-To: <0075B437-024A-4D84-ABD7-92FE8DAFA59F@commercebyte.com> From: Eric Rescorla Date: Thu, 24 Feb 2022 12:05:53 -0800 Message-ID: To: Jim Zubov Cc: IETF SecDispatch Content-Type: multipart/alternative; boundary="0000000000002bbbe905d8c91e66" Archived-At: Subject: Re: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 20:06:36 -0000 --0000000000002bbbe905d8c91e66 Content-Type: text/plain; charset="UTF-8" Document: draft-zubov-snif-04.txt OVERALL As I understand it the problem statement here is that you have a back-end IoT server which is not publicly addressable and you want to have a front-end proxy server which: 1. Assigns the back-end-server a hostname 2. Acquires publicly available WebPKI certificates on its behalf 3. Serves as a reverse proxy for the server at the TCP layer (and presumably eventually at the UDP layer). The problem of acquiring WebPKI certificates for non-publicly addressable devices is a pretty common one and applies to a number of enterprise use cases, not just WebPKI. However, it seems to me that your situation is different because you want the device to be accessible, it just isn't publicly addressable. This suggests to me that there is a simpler approach: - When a device first connects to the proxy, assign it a hostname and establish a credential (e.g., a random key) bound to the hostname (effectively #1 above) - Allow the device to connect to the proxy and authenticate with the credential and then route any TLS or HTTP connections to the hostname to that device (a generalization of #3). If you just do this, then you shouldn't need any other mechanism because the device will be able to fulfill the ordinary ACME HTTP Challenge (RFC 8555; S 8.3) and the ALPN challenge (RFC 8737) without any additional effort by the proxy. In particular, the proxy will not need to engage with ACME because the back-end server can do that. Second, I don't think you need to define a new proxy protocol. While MASQUE isn't currently specified for this kind of server application, it seems like a natural extension and MASQUE would handle all the transport mechanics for you, thus making life a lot simpler. DETAILED COMMENTS A number of the design choices here seem suboptimal. These would mostly go away if you adopted the strategy I propose above. However, I note them in case you do not do so. * If I am reading this protocol correctly, there is no way to change the private key of a server in a given name. If that's correct, it seems suboptimal. * It seems like you are establishing a new TCP connection to the device for each incoming TCP connection. That is not going to have great performance. I would instead mux all the data over a single connection (see MASQUE, supra). * It seems like you are having the relay connect to the device. That is going to be a problem if the device is behind a NAT or any kind of stateful inspection filter. Instead, I would have all connections be outgoing. * Requiring the Relay to validate the server's TLS certificate, as defined in S 4.2, makes the Relay much more complicated as it has to have a WebPKI stack in it. I also, I don't understand this text: Since each certificate issued by a CA remains on the certificate transparency public records, it is RECOMMENDED for SNIF CA Proxy to only issue Certificates with a wildcard CN. This way, the actual Connector's hostname (Section 3.2) will not be listed on the public records. Can you provide an example of what you mean here? If the Connectors are named a.example.com, b.example.com, and c.example.com, you obviously cannot issue any of them *.example.com. OTOH, if you have them have .a.example.com and .b.example.com, then how does it help to issue *.a.example.com? SECDISPATCH QUESTIONS I think the next steps here are to resolve what problem is being solved. In particular, if what I propose above will work, then this should go to MASQUE with a limited scope of defining incoming connections. If not, then I think we need to get clearer on why it won't. -Ekr On Tue, Feb 8, 2022 at 10:18 AM Jim Zubov wrote: > Please consider the following draft: > > https://datatracker.ietf.org/doc/draft-zubov-snif/ > > The document describes a set of protocols for publicly trusted serverless > TLS that can be used as an end-to-end IoT security solution. > > The solution had been tested in pre-production. The complete source code > is in the public domain - > > https://github.com/vesvault/snif > > Any feedback, suggestions, and recommendations of an IETF group adoption > are welcome. > > > Thank You - > > Jim Zubov > VESvault Corp > CTO / Co-founder > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000002bbbe905d8c91e66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Document: draft-zubov-snif-04.txt


OVERALL
As= I understand it the problem statement here is that you
have a back-end = IoT server which is not publicly addressable
and you want to have a fron= t-end proxy server which:

1. Assigns the back-end-server a hostname<= br>
2. Acquires publicly available WebPKI certificates on its
=C2=A0 = =C2=A0behalf

3. Serves as a reverse proxy for the server at the TCP<= br>=C2=A0 =C2=A0layer (and presumably eventually at the UDP layer).

= The problem of acquiring WebPKI certificates for non-publicly
addressabl= e devices is a pretty common one and applies to
a number of enterprise u= se cases, not just WebPKI.

However, it seems to me that your situati= on is different because you
want the device to be accessible, it just is= n't publicly
addressable. This suggests to me that there is a simple= r approach:

- When a device first connects to the proxy, assign it a=
=C2=A0 hostname and establish a credential (e.g., a random
=C2=A0 ke= y) bound to the hostname (effectively #1 above)

- Allow the device t= o connect to the proxy and authenticate with the
=C2=A0 credential and t= hen route any TLS or HTTP connections to the
=C2=A0 hostname to that dev= ice (a generalization of #3).

If you just do this, then you shouldn&= #39;t need any other mechanism
because the device will be able to fulfil= l the ordinary ACME HTTP
Challenge (RFC 8555; S 8.3) and the ALPN challe= nge (RFC 8737) without
any additional effort by the proxy. In particular= , the proxy will
not need to engage with ACME because the back-end serve= r can
do that.

Second, I don't think you need to define a new= proxy protocol. While
MASQUE isn't currently specified for this kin= d of server application,
it seems like a natural extension and MASQUE wo= uld handle all the
transport mechanics for you, thus making life a lot s= impler.


DETAILED COMMENTS
A number of the design choices here= seem suboptimal. These would
mostly go away if you adopted the strategy= I propose above. However,
I note them in case you do not do so.

= * If I am reading this protocol correctly, there is no way to
=C2=A0 cha= nge the private key of a server in a given name. If that's
=C2=A0 co= rrect, it seems suboptimal.

* It seems like you are establishing a n= ew TCP connection to
=C2=A0 the device for each incoming TCP connection.= That is not
=C2=A0 going to have great performance. I would instead mux= all
=C2=A0 the data over a single connection (see MASQUE, supra).
* It seems like you are having the relay connect to the device.
=C2=A0= That is going to be a problem if the device is behind a
=C2=A0 NAT or a= ny kind of stateful inspection filter. Instead,
=C2=A0 I would have all = connections be outgoing.

* Requiring the Relay to validate the serve= r's TLS certificate,
=C2=A0 as defined in S 4.2, makes the Relay muc= h more complicated
=C2=A0 as it has to have a WebPKI stack in it.
=C2= =A0
I also, I don't understand this text:

=C2=A0 =C2=A0Since= each certificate issued by a CA remains on the certificate
=C2=A0 =C2= =A0transparency public records, it is RECOMMENDED for SNIF CA Proxy to
= =C2=A0 =C2=A0only issue Certificates with a wildcard CN.=C2=A0 This way, th= e actual
=C2=A0 =C2=A0Connector's hostname (Section 3.2) will not be= listed on the public
=C2=A0 =C2=A0records.

Can you provide an ex= ample of what you mean here? If the Connectors
are named a.example.com, b.exa= mple.com, and c.example.com, you o= bviously
cannot issue any of them *.examp= le.com. OTOH, if you have them have
<something>.a.example.com and <something-else>.b.example.com, then
how does it help to issue = *.a.example.com?


SECDISPATC= H QUESTIONS
I think the next steps here are to resolve what problem is b= eing
solved. In particular, if what I propose above will work, then
t= his should go to MASQUE with a limited scope of defining incoming
connec= tions. If not, then I think we need to get clearer on why
it won't.<= br>
-Ekr











=C2=A0 =C2=A0 = =C2=A0 =C2=A0









On Tue, Feb 8, 2022 at 10= :18 AM Jim Zubov <ietf-lis= t@commercebyte.com> wrote:
Please consider the following draft:

<= a href=3D"https://datatracker.ietf.org/doc/draft-zubov-snif/" target=3D"_bl= ank">https://datatracker.ietf.org/doc/draft-zubov-snif/

The docu= ment describes a set of protocols for publicly trusted serverless TLS that = can be used as an end-to-end IoT security solution.

The solution had= been tested in pre-production. The complete source code is in the public d= omain -

https://github.com/vesvault/snif

Any feedback, suggestions, a= nd recommendations of an IETF group adoption are welcome.


Thank = You -

Jim Zubov
VESvault Corp
CTO / Co-founder

__= _____________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000002bbbe905d8c91e66-- From nobody Thu Feb 24 15:22:14 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F373A0C04 for ; Thu, 24 Feb 2022 15:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 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, URI_HEX=0.1] 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 cRZkuPg3ZCl6 for ; Thu, 24 Feb 2022 15:22:07 -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 00B6A3A0BDD for ; Thu, 24 Feb 2022 15:22:06 -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:CC:To:From:Date; bh=2qFJOjA5gQK+8CH4ubAnuSZWwACMDx9FPWJXaUBpyHk=; b=DJ9uLSpSDnE61djrGFogVr9vF7w0Q2n5JLa4hvwKSrsehu0K4rySBhuhJyqLf821UZACLJlWJgxm4Vl5VXqLErHCSucLV4UZ2acdgq5aZgeIL1wUT6JUwwxtRJ4dX0Cj4MbYqoCIuw8ZpIEfunxaP+bByJALMuktnA9po36XwJo=; Received: from [47.204.174.73] (port=49458 helo=[127.0.0.1]) by ocean1.commercebyte.com with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1nNNQy-0000v1-RN; Thu, 24 Feb 2022 18:22:05 -0500 Received: from [206.81.2.95]:7120 (helo=[127.0.0.1]) by [192.168.254.152]:45142 (localhost) with VESmail ESMTP Proxy 1.59 (encrypt=FALSE mode=FALLBACK); Thu, 24 Feb 2022 18:22:04 -0500 Date: Thu, 24 Feb 2022 18:21:54 -0500 From: Jim Zubov To: secdispatch@ietf.org, Eric Rescorla , Jim Zubov CC: IETF SecDispatch User-Agent: K-9 Mail for Android In-Reply-To: References: <0075B437-024A-4D84-ABD7-92FE8DAFA59F@commercebyte.com> Message-ID: <5A22A937-DCEF-407C-A244-6A84247DFB74@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: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 23:22:12 -0000 Thank You for the feedback Eric, My comments are below - On February 24, 2022 3:05:53 PM EST, Eric Rescorla wrote: >Document: draft-zubov-snif-04=2Etxt > > >OVERALL >As I understand it the problem statement here is that you >have a back-end IoT server which is not publicly addressable >and you want to have a front-end proxy server which: > >1=2E Assigns the back-end-server a hostname > >2=2E Acquires publicly available WebPKI certificates on its > behalf > >3=2E Serves as a reverse proxy for the server at the TCP > layer (and presumably eventually at the UDP layer)=2E A clarification on #3 - the SNIF relay relays the traffic on a TCP+TLS soc= ket (in theory also extendable to UDP+DTLS) based on the SNI record in the = client's handshake=2E From the client's point of view, the SNIF relay respo= nds like a regular TLS server, while all the traffic is actually being rela= yed from/to the SNIF connector on the device=2E > >The problem of acquiring WebPKI certificates for non-publicly >addressable devices is a pretty common one and applies to >a number of enterprise use cases, not just WebPKI=2E > >However, it seems to me that your situation is different because you >want the device to be accessible, it just isn't publicly >addressable=2E This suggests to me that there is a simpler approach: > >- When a device first connects to the proxy, assign it a > hostname and establish a credential (e=2Eg=2E, a random > key) bound to the hostname (effectively #1 above) > >- Allow the device to connect to the proxy and authenticate with the > credential and then route any TLS or HTTP connections to the > hostname to that device (a generalization of #3)=2E I think this approach misses the most important point of SNIF - end-to-end= =2E The SNIF relay doesn't have access to any private keys in principle, th= us it acts as a dumb TLS relay without being able to access the payload=2E > >If you just do this, then you shouldn't need any other mechanism >because the device will be able to fulfill the ordinary ACME HTTP >Challenge (RFC 8555; S 8=2E3) and the ALPN challenge (RFC 8737) without >any additional effort by the proxy=2E In particular, the proxy will >not need to engage with ACME because the back-end server can >do that=2E ALPN involves communications to the target hostname using a self-signed ce= rtificate=2E SNIF relay is designed to not allow any self-signed, or otherw= ise not publicly trusted, certificates, it makes security audit a whole lot= easier=2E Therefore, a trusted certificate needs to be negotiated through = the CA proxy (or by other means) before being able to accept any relayed co= nnections to the hostname=2E > >Second, I don't think you need to define a new proxy protocol=2E While >MASQUE isn't currently specified for this kind of server application, >it seems like a natural extension and MASQUE would handle all the >transport mechanics for you, thus making life a lot simpler=2E The reason I use a separate TCP socket for each connection is to simplify = the implementation of SNIF connector in conjunction with a server process o= n the IoT device=2E Using snif-srv, the connector opens a TCP socket, sends= a SNIF ACCEPT message in plain text, and immediately hands the socket off = to the process which will start TLS negotiation as a server peer, just like= a regular server would do after accepting the socket=2E It's possible to d= esign the control and multiple service connections to be multiplexed over Q= UIC, and use a software demux, and possibly fifos, on the connector side to= interact with the server processes, but I believe separate TCPs is a clean= er answer in a resource constrained IoT environment=2E=20 > > >DETAILED COMMENTS >A number of the design choices here seem suboptimal=2E These would >mostly go away if you adopted the strategy I propose above=2E However, >I note them in case you do not do so=2E > >* If I am reading this protocol correctly, there is no way to > change the private key of a server in a given name=2E If that's > correct, it seems suboptimal=2E The private key is regenerated when you hard reset the device, along with = allocating a new CN=2E The former CN gets permanently retired=2E The rule i= s - 1 CN =3D=3D 1 private key=2E It's for the security audit purpose - if y= ou ever find certs with same or overlapping CNs but different public keys -= the CA proxy is permanently compromised and cannot be trusted anymore=2E > >* It seems like you are establishing a new TCP connection to > the device for each incoming TCP connection=2E That is not > going to have great performance=2E I would instead mux all > the data over a single connection (see MASQUE, supra)=2E See comments above regarding multiplexing=2E > >* It seems like you are having the relay connect to the device=2E > That is going to be a problem if the device is behind a > NAT or any kind of stateful inspection filter=2E Instead, > I would have all connections be outgoing=2E > No=2E All connections are outgoing from the device=2E Works fine with NAT = and (reasonable) firewalls, I have a pre-production instance that I'm actua= lly using to send this email=2E >* Requiring the Relay to validate the server's TLS certificate, > as defined in S 4=2E2, makes the Relay much more complicated > as it has to have a WebPKI stack in it=2E > The relay runs on a server, Linux usually=2E It's not a problem to validat= e a certificate on a Linux server, you have PKI roots in any standard insta= llation=2E >I also, I don't understand this text: > > Since each certificate issued by a CA remains on the certificate > transparency public records, it is RECOMMENDED for SNIF CA Proxy to > only issue Certificates with a wildcard CN=2E This way, the actual > Connector's hostname (Section 3=2E2) will not be listed on the public > records=2E > >Can you provide an example of what you mean here? If the Connectors >are named a=2Eexample=2Ecom, b=2Eexample=2Ecom, and c=2Eexample=2Ecom, yo= u obviously >cannot issue any of them *=2Eexample=2Ecom=2E OTOH, if you have them have >=2Ea=2Eexample=2Ecom and =2Eb=2Eexample=2Ecom,= then >how does it help to issue *=2Ea=2Eexample=2Ecom? A real example: CN =3D *=2Esnif-054e2fa720a6-7d8cf7d2=2Esnif=2Exyz Hostname =3D rf205699c9be3=2Esnif-054e2fa720a6-7d8cf7d2=2Esnif=2Exyz The CN is listed on public transparency logs, the hostname is not=2E It's = an extra step to safeguard the hostname from DoS attempts=2E > > >SECDISPATCH QUESTIONS >I think the next steps here are to resolve what problem is being >solved=2E In particular, if what I propose above will work, then >this should go to MASQUE with a limited scope of defining incoming >connections=2E If not, then I think we need to get clearer on why >it won't=2E > >-Ekr I still doubt the relevance of MASQUE, see comments above=2E Any further comments are welcome=2E > > > > > > > > > > > > > > > > > > > > > >On Tue, Feb 8, 2022 at 10:18 AM Jim Zubov >wrote: > >> Please consider the following draft: >> >> https://datatracker=2Eietf=2Eorg/doc/draft-zubov-snif/ >> >> The document describes a set of protocols for publicly trusted serverle= ss >> TLS that can be used as an end-to-end IoT security solution=2E >> >> The solution had been tested in pre-production=2E The complete source c= ode >> is in the public domain - >> >> https://github=2Ecom/vesvault/snif >> >> Any feedback, suggestions, and recommendations of an IETF group adoptio= n >> are welcome=2E >> >> >> Thank You - >> >> Jim Zubov >> VESvault Corp >> CTO / Co-founder >> >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/secdispatch >> From nobody Thu Feb 24 16:11:09 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC3B3A0D39 for ; Thu, 24 Feb 2022 16:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.203 X-Spam-Level: X-Spam-Status: No, score=0.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.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 d3pZKkYWpqNI for ; Thu, 24 Feb 2022 16:11:02 -0800 (PST) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 47FE23A0CA8 for ; Thu, 24 Feb 2022 16:11:02 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id c14so3092644ilm.4 for ; Thu, 24 Feb 2022 16:11:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vXEzEk1Xyq95xMGQ+/MonlCG3BkafqlIEC6hVsCWE3U=; b=KhZCwRn5iXF9ab5VvgGdkjhCUA847ua4fDWclHV6DQsX0AMlx6VvX/cfv+tHe8q74B AAyKi1v6Qe8afbowkyTTpVgQEhqsZBXTlP9lmOtc8+hJQjsVwBdu/w2qL2KaRq7xZfwy ELQOzFv/gmlMwkv30OX7fdQ2eApom9m1XRMm/qvk2I1B42W3NGoHSDshv7iOguTR9jyN 04Q/rC2J8kfhK/WRNHXB2N7QkiPT5azObBDUhTilAd0Zjn7a3FZZtWT2MaUx2DmV7ZKx Vxsdb9pB+yL6A/ASjmTJOehd/NT6TqckC9F9ZLrlGoTfp4SnGgnlutthEFTUGAXr3Vp/ RkZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vXEzEk1Xyq95xMGQ+/MonlCG3BkafqlIEC6hVsCWE3U=; b=z1fmfvypTXnzK4aOjRrmHhJUrr8Tfb8YMNSxSlYhUKTHBCnWTak2RJuaOjApHGIk7S wagRfzQAVe6eipVc2db6pqF0biS2jUjix9W0KwO85YlmIIv5SEUUKmlBz0NiFuyylZvV UT1qv2tDvTYuimXL/UCFTnb1oEBUwFOwIpsfI6FYD6aaO+2uhi7zQpeF0us2FbJkd+8R OtlQuoo60S0Abtlu1GNLpL+kmDHu/kvu1n4aqLeyHakhdTJ/vaGMXC151GBEPMe0gUea npU5ruFuFB5xWSvwph7iiHptHtDD3CSCvv6nVjz2/6KRRMM9r50Z2DW6cdd/ydxEhNn4 I+Jg== X-Gm-Message-State: AOAM533JiXoXK4WbDqgj6NMvSZ1lnveQpHuSeljQoVKdpZ7XpCIyfKM+ 0wcUvvvutWSF6M+lW47W7PGzJMiteyHKXJMJjVhWVxS+Hug= X-Google-Smtp-Source: ABdhPJykeZEhcGZJswmgwQ48+hvAxRl/SDPEUgww3F4EDD84NEFIAOmjTJpnxRbUddbQxlu7yvfwDY51xNwGvQnVLeI= X-Received: by 2002:a05:6e02:cc7:b0:2be:c410:8078 with SMTP id c7-20020a056e020cc700b002bec4108078mr4315035ilj.60.1645747861423; Thu, 24 Feb 2022 16:11:01 -0800 (PST) MIME-Version: 1.0 References: <0075B437-024A-4D84-ABD7-92FE8DAFA59F@commercebyte.com> <5A22A937-DCEF-407C-A244-6A84247DFB74@commercebyte.com> In-Reply-To: <5A22A937-DCEF-407C-A244-6A84247DFB74@commercebyte.com> From: Eric Rescorla Date: Thu, 24 Feb 2022 16:10:25 -0800 Message-ID: To: Jim Zubov Cc: IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000ab9d0605d8cc880e" Archived-At: Subject: Re: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2022 00:11:07 -0000 --000000000000ab9d0605d8cc880e Content-Type: text/plain; charset="UTF-8" On Thu, Feb 24, 2022 at 3:22 PM Jim Zubov wrote: > Thank You for the feedback Eric, > My comments are below - > > On February 24, 2022 3:05:53 PM EST, Eric Rescorla wrote: > >Document: draft-zubov-snif-04.txt > > > > > >OVERALL > >As I understand it the problem statement here is that you > >have a back-end IoT server which is not publicly addressable > >and you want to have a front-end proxy server which: > > > >1. Assigns the back-end-server a hostname > > > >2. Acquires publicly available WebPKI certificates on its > > behalf > > > >3. Serves as a reverse proxy for the server at the TCP > > layer (and presumably eventually at the UDP layer). > > A clarification on #3 - the SNIF relay relays the traffic on a TCP+TLS > socket (in theory also extendable to UDP+DTLS) based on the SNI record in > the client's handshake. From the client's point of view, the SNIF relay > responds like a regular TLS server, while all the traffic is actually being > relayed from/to the SNIF connector on the device. > Yes, I understand this. That's why I said "at the TCP layer"/ > > > >The problem of acquiring WebPKI certificates for non-publicly > >addressable devices is a pretty common one and applies to > >a number of enterprise use cases, not just WebPKI. > > > >However, it seems to me that your situation is different because you > >want the device to be accessible, it just isn't publicly > >addressable. This suggests to me that there is a simpler approach: > > > >- When a device first connects to the proxy, assign it a > > hostname and establish a credential (e.g., a random > > key) bound to the hostname (effectively #1 above) > > > >- Allow the device to connect to the proxy and authenticate with the > > credential and then route any TLS or HTTP connections to the > > hostname to that device (a generalization of #3). > > I think this approach misses the most important point of SNIF - > end-to-end. The SNIF relay doesn't have access to any private keys in > principle, thus it acts as a dumb TLS relay without being able to access > the payload. > What I am proposing also has this property. - For TLS, the proxy behaves as in your document, switching on SNI (though not validating the certificate) and forwarding the encrypted data. - For HTTP, the proxy behaves much the same way but switches on the Host: header. Therefore it is end-to-end for any encrypted traffic. >If you just do this, then you shouldn't need any other mechanism > >because the device will be able to fulfill the ordinary ACME HTTP > >Challenge (RFC 8555; S 8.3) and the ALPN challenge (RFC 8737) without > >any additional effort by the proxy. In particular, the proxy will > >not need to engage with ACME because the back-end server can > >do that. > > ALPN involves communications to the target hostname using a self-signed > certificate. SNIF relay is designed to not allow any self-signed, or > otherwise not publicly trusted, certificates, it makes security audit a > whole lot easier. Therefore, a trusted certificate needs to be negotiated > through the CA proxy (or by other means) before being able to accept any > relayed connections to the hostname. > I understand that this is part of your design, but I don't see that it provides much security value. Because the proxy assigns the hostnames, it already knows which IoT device is associated with which hostname, so it can use that information directly without having to examine the server's certificate. Regardless, you could use the HTTP ACME Challenge without allowing self-signed certs. >Second, I don't think you need to define a new proxy protocol. While > >MASQUE isn't currently specified for this kind of server application, > >it seems like a natural extension and MASQUE would handle all the > >transport mechanics for you, thus making life a lot simpler. > > The reason I use a separate TCP socket for each connection is to simplify > the implementation of SNIF connector in conjunction with a server process > on the IoT device. Using snif-srv, the connector opens a TCP socket, sends > a SNIF ACCEPT message in plain text, and immediately hands the socket off > to the process which will start TLS negotiation as a server peer, just like > a regular server would do after accepting the socket. It's possible to > design the control and multiple service connections to be multiplexed over > QUIC, and use a software demux, and possibly fifos, on the connector side > to interact with the server processes, but I believe separate TCPs is a > cleaner answer in a resource constrained IoT environment. > Hmm... It's not clear to me why you think that this uses fewer resources. Can you explain why you think that? > >DETAILED COMMENTS > >A number of the design choices here seem suboptimal. These would > >mostly go away if you adopted the strategy I propose above. However, > >I note them in case you do not do so. > > > >* If I am reading this protocol correctly, there is no way to > > change the private key of a server in a given name. If that's > > correct, it seems suboptimal. > > The private key is regenerated when you hard reset the device, along with > allocating a new CN. The former CN gets permanently retired. The rule is - > 1 CN == 1 private key. It's for the security audit purpose - if you ever > find certs with same or overlapping CNs but different public keys - the CA > proxy is permanently compromised and cannot be trusted anymore. > This seems like an unfortunate set of properties, for several reasons: 1. You then need to disseminate new domain names if you ever want to change your key. 2. It means you can't have two keys for the same server name, so (for instance) you can't easily change from RSA to ECDSA. Of course you could have "a.b.example.com" and "c.b.example.com" and issue two certificates with "*.b.example.com" but now you are back to the same problem of two keys with one name. Incidentally, it's not clear to me that this inference about the CA proxy is correct. We know that it is possible under certain conditions to use network-level attacks to get certificates misissued. In this case, you could have two certificates for one name with no malfeasance by the proxy. > > >* It seems like you are establishing a new TCP connection to > > the device for each incoming TCP connection. That is not > > going to have great performance. I would instead mux all > > the data over a single connection (see MASQUE, supra). > > See comments above regarding multiplexing. > I don't really agree, but I don't think we can defer this point. >* It seems like you are having the relay connect to the device. > > That is going to be a problem if the device is behind a > > NAT or any kind of stateful inspection filter. Instead, > > I would have all connections be outgoing. > > > > No. All connections are outgoing from the device. Works fine with NAT and > (reasonable) firewalls, I have a pre-production instance that I'm actually > using to send this email. > OK. This was not clear to me. > >* Requiring the Relay to validate the server's TLS certificate, > > as defined in S 4.2, makes the Relay much more complicated > > as it has to have a WebPKI stack in it. > > > > The relay runs on a server, Linux usually. It's not a problem to validate > a certificate on a Linux server, you have PKI roots in any standard > installation. > It's certainly more work to validate than not. For instance, how do you handle revocation? >I also, I don't understand this text: > > > > Since each certificate issued by a CA remains on the certificate > > transparency public records, it is RECOMMENDED for SNIF CA Proxy to > > only issue Certificates with a wildcard CN. This way, the actual > > Connector's hostname (Section 3.2) will not be listed on the public > > records. > > > >Can you provide an example of what you mean here? If the Connectors > >are named a.example.com, b.example.com, and c.example.com, you obviously > >cannot issue any of them *.example.com. OTOH, if you have them have > >.a.example.com and .b.example.com, then > >how does it help to issue *.a.example.com? > > A real example: > CN = *.snif-054e2fa720a6-7d8cf7d2.snif.xyz > Hostname = rf205699c9be3.snif-054e2fa720a6-7d8cf7d2.snif.xyz > > The CN is listed on public transparency logs, the hostname is not. It's an > extra step to safeguard the hostname from DoS attempts. > Thanks for the explanation. -Ekr --000000000000ab9d0605d8cc880e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 24, 2022 at 3:22 PM Jim Z= ubov <ietf-list@commerceby= te.com> wrote:
Thank You for the feedback Eric,
My comments are below -

On February 24, 2022 3:05:53 PM EST, Eric Rescorla <ekr@rtfm.com> wrote:
>Document: draft-zubov-snif-04.txt
>
>
>OVERALL
>As I understand it the problem statement here is that you
>have a back-end IoT server which is not publicly addressable
>and you want to have a front-end proxy server which:
>
>1. Assigns the back-end-server a hostname
>
>2. Acquires publicly available WebPKI certificates on its
>=C2=A0 =C2=A0behalf
>
>3. Serves as a reverse proxy for the server at the TCP
>=C2=A0 =C2=A0layer (and presumably eventually at the UDP layer).

A clarification on #3 - the SNIF relay relays the traffic on a TCP+TLS sock= et (in theory also extendable to UDP+DTLS) based on the SNI record in the c= lient's handshake. From the client's point of view, the SNIF relay = responds like a regular TLS server, while all the traffic is actually being= relayed from/to the SNIF connector on the device.
Yes, I understand this. That's why I said "at the TCP = layer"/

=C2=A0
>
>The problem of acquiring WebPKI certificates for non-publicly
>addressable devices is a pretty common one and applies to
>a number of enterprise use cases, not just WebPKI.
>
>However, it seems to me that your situation is different because you >want the device to be accessible, it just isn't publicly
>addressable. This suggests to me that there is a simpler approach:
>
>- When a device first connects to the proxy, assign it a
>=C2=A0 hostname and establish a credential (e.g., a random
>=C2=A0 key) bound to the hostname (effectively #1 above)
>
>- Allow the device to connect to the proxy and authenticate with the >=C2=A0 credential and then route any TLS or HTTP connections to the
>=C2=A0 hostname to that device (a generalization of #3).

I think this approach misses the most important point of SNIF - end-to-end.= The SNIF relay doesn't have access to any private keys in principle, t= hus it acts as a dumb TLS relay without being able to access the payload.

What I am proposing also has this proper= ty.

- For TLS, the proxy behaves as in your d= ocument, switching on SNI (though not validating the certificate) and forwa= rding the encrypted data.
- For HTTP, the proxy behaves much = the same way but switches on the Host: header.

The= refore it is end-to-end for any encrypted traffic.


>If you just do this, then you shouldn't need any other mechanism >because the device will be able to fulfill the ordinary ACME HTTP
>Challenge (RFC 8555; S 8.3) and the ALPN challenge (RFC 8737) without >any additional effort by the proxy. In particular, the proxy will
>not need to engage with ACME because the back-end server can
>do that.

ALPN involves communications to the target hostname using a self-signed cer= tificate. SNIF relay is designed to not allow any self-signed, or otherwise= not publicly trusted, certificates, it makes security audit a whole lot ea= sier. Therefore, a trusted certificate needs to be negotiated through the C= A proxy (or by other means) before being able to accept any relayed connect= ions to the hostname.

I understand that= this is part of your design, but I don't see that it provides much sec= urity value. Because the proxy assigns the hostnames, it already knows whic= h IoT device is associated with which hostname, so it can use that informat= ion directly without having to examine the server's certificate. Regard= less, you could use the HTTP ACME Challenge without allowing self-signed ce= rts.



>Second, I don't think you need to define a new proxy protocol. Whil= e
>MASQUE isn't currently specified for this kind of server applicatio= n,
>it seems like a natural extension and MASQUE would handle all the
>transport mechanics for you, thus making life a lot simpler.

The reason I use a separate TCP socket for each connection is to simplify t= he implementation of SNIF connector in conjunction with a server process on= the IoT device. Using snif-srv, the connector opens a TCP socket, sends a = SNIF ACCEPT message in plain text, and immediately hands the socket off to = the process which will start TLS negotiation as a server peer, just like a = regular server would do after accepting the socket. It's possible to de= sign the control and multiple service connections to be multiplexed over QU= IC, and use a software demux, and possibly fifos, on the connector side to = interact with the server processes, but I believe separate TCPs is a cleane= r answer in a resource constrained IoT environment.
<= br>
Hmm... It's not clear to me why you think that this uses = fewer resources.=C2=A0 Can you explain why you think that?

=C2=A0
>DETAILED COMMENTS
>A number of the design choices here seem suboptimal. These would
>mostly go away if you adopted the strategy I propose above. However, >I note them in case you do not do so.
>
>* If I am reading this protocol correctly, there is no way to
>=C2=A0 change the private key of a server in a given name. If that'= s
>=C2=A0 correct, it seems suboptimal.

The private key is regenerated when you hard reset the device, along with a= llocating a new CN. The former CN gets permanently retired. The rule is - 1= CN =3D=3D 1 private key. It's for the security audit purpose - if you = ever find certs with same or overlapping CNs but different public keys - th= e CA proxy is permanently compromised and cannot be trusted anymore.

This seems like an unfortunate set of propert= ies, for several reasons:

1. You then need to diss= eminate new domain names if you ever want to change your key.
2. = It means you can't have two keys for the same server name, so (for inst= ance) you can't easily change from RSA to ECDSA.

Of course you could have "a.b.ex= ample.com" and "c.b.exampl= e.com" and issue two certificates with "*.b.example.com" but now you are back to the same prob= lem of two keys with one name.

Incidentally, = it's not clear to me that this inference about the CA proxy is correct.= We know that it is possible under certain conditions to use network-level = attacks to get certificates misissued. In this case, you could have two cer= tificates for one name with no malfeasance by the proxy.

=

>
>* It seems like you are establishing a new TCP connection to
>=C2=A0 the device for each incoming TCP connection. That is not
>=C2=A0 going to have great performance. I would instead mux all
>=C2=A0 the data over a single connection (see MASQUE, supra).

See comments above regarding multiplexing.

<= div>I don't really agree, but I don't think we can defer this point= .


>* It seems like you are having the relay connect to the device.
>=C2=A0 That is going to be a problem if the device is behind a
>=C2=A0 NAT or any kind of stateful inspection filter. Instead,
>=C2=A0 I would have all connections be outgoing.
>

No. All connections are outgoing from the device. Works fine with NAT and (= reasonable) firewalls, I have a pre-production instance that I'm actual= ly using to send this email.

OK. This w= as not clear to me.

=C2=A0
>* Requiring the Relay to validate the server's TLS certificate,
>=C2=A0 as defined in S 4.2, makes the Relay much more complicated
>=C2=A0 as it has to have a WebPKI stack in it.
>

The relay runs on a server, Linux usually. It's not a problem to valida= te a certificate on a Linux server, you have PKI roots in any standard inst= allation.

It's certainly more work = to validate than not. For instance, how do you handle revocation?

>I also, I don't understand this text:
>
>=C2=A0 =C2=A0Since each certificate issued by a CA remains on the certi= ficate
>=C2=A0 =C2=A0transparency public records, it is RECOMMENDED for SNIF CA= Proxy to
>=C2=A0 =C2=A0only issue Certificates with a wildcard CN.=C2=A0 This way= , the actual
>=C2=A0 =C2=A0Connector's hostname (Section 3.2) will not be listed = on the public
>=C2=A0 =C2=A0records.
>
>Can you provide an example of what you mean here? If the Connectors
>are named a.example.com, b.example.com, and c.example.com, you obviously >cannot issue any of them *.example.com. OTOH, if you have them have
><something>.a.example.com and <something-else>.b.example.com,= then
>how does it help to issue *.a.example.com?

A real example:
CN =3D *.snif-054e2fa720a6-7d8cf7d2.snif.xyz
Hostname =3D rf205699c9be3.snif-054e2fa720a6= -7d8cf7d2.snif.xyz

The CN is listed on public transparency logs, the hostname is not. It's= an extra step to safeguard the hostname from DoS attempts.

Thanks for the explanation.

-= Ekr


--000000000000ab9d0605d8cc880e-- From nobody Thu Feb 24 19:23:08 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0213A1190 for ; Thu, 24 Feb 2022 19:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] 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 1iG4TsoChvRe for ; Thu, 24 Feb 2022 19:22:55 -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 E62173A1241 for ; Thu, 24 Feb 2022 19:22:38 -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:CC:To:From:Date; bh=dYxk4NhHboikdYSTFpX2Sb0gEq290aQX0BpWOTYJSd4=; b=kAyvVdTjrHHRWeKZSihxpmn/5/hdMGgMX81Izlk+jApsnoGVPovwGc56DRQqKIKX40K/o7ia2fGC9GCWTliqHrcpUSUKICuQU1Xl32o40IUJYUZuREKMn7E1Ki220HTJws9d4vBWgBK/RGGzFTGEiFDuaCmz8sEHAOde/oQYasQ=; Received: from [47.204.174.73] (port=40648 helo=[127.0.0.1]) by ocean1.commercebyte.com with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1nNRBj-0004sV-Ry; Thu, 24 Feb 2022 22:22:36 -0500 Received: from [206.81.2.95]:7120 (helo=[127.0.0.1]) by [192.168.254.152]:49334 (localhost) with VESmail ESMTP Proxy 1.59 (encrypt=FALSE mode=FALLBACK); Thu, 24 Feb 2022 22:22:35 -0500 Date: Thu, 24 Feb 2022 22:22:23 -0500 From: Jim Zubov To: Eric Rescorla , Jim Zubov CC: IETF SecDispatch User-Agent: K-9 Mail for Android In-Reply-To: References: <0075B437-024A-4D84-ABD7-92FE8DAFA59F@commercebyte.com> <5A22A937-DCEF-407C-A244-6A84247DFB74@commercebyte.com> Message-ID: <69A8786D-1992-4B7E-BB3A-FF9C0F576B54@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: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2022 03:23:05 -0000 On February 24, 2022 7:10:25 PM EST, Eric Rescorla wrote: >On Thu, Feb 24, 2022 at 3:22 PM Jim Zubov >wrote: > >> Thank You for the feedback Eric, >> My comments are below - >> >> On February 24, 2022 3:05:53 PM EST, Eric Rescorla wro= te: >> >Document: draft-zubov-snif-04=2Etxt >> > >> > >> >OVERALL >> >As I understand it the problem statement here is that you >> >have a back-end IoT server which is not publicly addressable >> >and you want to have a front-end proxy server which: >> > >> >1=2E Assigns the back-end-server a hostname >> > >> >2=2E Acquires publicly available WebPKI certificates on its >> > behalf >> > >> >3=2E Serves as a reverse proxy for the server at the TCP >> > layer (and presumably eventually at the UDP layer)=2E >> >> A clarification on #3 - the SNIF relay relays the traffic on a TCP+TLS >> socket (in theory also extendable to UDP+DTLS) based on the SNI record = in >> the client's handshake=2E From the client's point of view, the SNIF rel= ay >> responds like a regular TLS server, while all the traffic is actually b= eing >> relayed from/to the SNIF connector on the device=2E >> > >Yes, I understand this=2E That's why I said "at the TCP layer"/ > > > >> > >> >The problem of acquiring WebPKI certificates for non-publicly >> >addressable devices is a pretty common one and applies to >> >a number of enterprise use cases, not just WebPKI=2E >> > >> >However, it seems to me that your situation is different because you >> >want the device to be accessible, it just isn't publicly >> >addressable=2E This suggests to me that there is a simpler approach: >> > >> >- When a device first connects to the proxy, assign it a >> > hostname and establish a credential (e=2Eg=2E, a random >> > key) bound to the hostname (effectively #1 above) >> > >> >- Allow the device to connect to the proxy and authenticate with the >> > credential and then route any TLS or HTTP connections to the >> > hostname to that device (a generalization of #3)=2E >> >> I think this approach misses the most important point of SNIF - >> end-to-end=2E The SNIF relay doesn't have access to any private keys in >> principle, thus it acts as a dumb TLS relay without being able to acces= s >> the payload=2E >> > >What I am proposing also has this property=2E > >- For TLS, the proxy behaves as in your document, switching on SNI (thoug= h >not validating the certificate) and forwarding the encrypted data=2E >- For HTTP, the proxy behaves much the same way but switches on the Host: >header=2E > >Therefore it is end-to-end for any encrypted traffic=2E Basically, everything boils down to 2 questions - 1=2E who has access to the private key, 2=2E who interacts with the CA to issue the cert When the solution is end-to-end - the answer to (1) is always - only the d= evice itself=2E Let's review (2) assuming the CA speaks ACME=2E There are 3 common challen= ge types - HTTP, DNS and ALPN=2E HTTP: Need to either relay plain HTTP from/to the device, or the proxy to = serve HTTP=2E=20 DNS: Need to either relay DNS from/to the device, or the proxy to serve DN= S=2E ALPN: Need to either relay TLS to a device with a self-signed cert, authen= ticated by means other than the cert, or the proxy to route specific hostna= me to TLS with a self-signed cert hosted by the proxy itself=2E I follow simple security rules in SNIF design which I believe are reasonab= le - the control connection MUST present a valid certificate that matches t= he hostname, and the service connection MUST be TLS with the same certifica= te=2E According to these rules, plain HTTP is out, self-signed cert is out,= relayed DNS would involve some new protocol layer=2E I believe the answer converges on the proxy serving the challenge, either = HTTP or DNS=2E And the way to submit a CSR is to generate it on the device = and pass it to the proxy, so the proxy initiates and completes ACME challen= ge without involving the device in this process=2E The proxy receives and c= aches the trusted cert once it's issued, and the device downloads it=2E Sim= ilarly, the renewals are handled by the proxy using the previously cached C= SR=2E As an additional benefit of such design, the proxy may switch between CAs,= or use any applicable protocols, whether ACME or something else, without a= ny modification to the SNIF connector on the device=2E And, I don't specify relaying plain HTTP through SNIF - it's possible in t= heory based on the Host header, but it's apriori not end-to-end, not much u= seful it today's world, and using it for ACME challenge involves designing = additional mechanisms and violating the paradigms, as I mentioned earlier= =2E > > >>If you just do this, then you shouldn't need any other mechanism >> >because the device will be able to fulfill the ordinary ACME HTTP >> >Challenge (RFC 8555; S 8=2E3) and the ALPN challenge (RFC 8737) withou= t >> >any additional effort by the proxy=2E In particular, the proxy will >> >not need to engage with ACME because the back-end server can >> >do that=2E >> >> ALPN involves communications to the target hostname using a self-signed >> certificate=2E SNIF relay is designed to not allow any self-signed, or >> otherwise not publicly trusted, certificates, it makes security audit a >> whole lot easier=2E Therefore, a trusted certificate needs to be negoti= ated >> through the CA proxy (or by other means) before being able to accept an= y >> relayed connections to the hostname=2E >> > >I understand that this is part of your design, but I don't see that it >provides much security value=2E Because the proxy assigns the hostnames, = it >already knows which IoT device is associated with which hostname, so it c= an >use that information directly without having to examine the server's >certificate=2E Regardless, you could use the HTTP ACME Challenge without >allowing self-signed certs=2E Yes, the proxy knows the hostname=2E But it doesn't have the private key, = thus cannot use the cert=2E And if it issues a duplicate cert - it's audita= ble through the transparency logs (more on it later)=2E As for the proxy knowing the identity of the IoT device - it depends on ho= w the initUrl and the cert issue authorization are implemented, I left it t= o the liberty of the implementor in the draft=2E > > > >>Second, I don't think you need to define a new proxy protocol=2E While >> >MASQUE isn't currently specified for this kind of server application, >> >it seems like a natural extension and MASQUE would handle all the >> >transport mechanics for you, thus making life a lot simpler=2E >> >> The reason I use a separate TCP socket for each connection is to simpli= fy >> the implementation of SNIF connector in conjunction with a server proce= ss >> on the IoT device=2E Using snif-srv, the connector opens a TCP socket, = sends >> a SNIF ACCEPT message in plain text, and immediately hands the socket o= ff >> to the process which will start TLS negotiation as a server peer, just = like >> a regular server would do after accepting the socket=2E It's possible t= o >> design the control and multiple service connections to be multiplexed o= ver >> QUIC, and use a software demux, and possibly fifos, on the connector si= de >> to interact with the server processes, but I believe separate TCPs is a >> cleaner answer in a resource constrained IoT environment=2E >> > >Hmm=2E=2E=2E It's not clear to me why you think that this uses fewer reso= urces=2E >Can you explain why you think that? Sure=2E TCP has been around for ~50 years, is implemented in every modern = OS, has been tested, refined and optimized for decades=2E QUIC, on the other side, is still one foot in a petri dish=2E No disrespec= t here, but a TCP socket is a standard OS call while QUIC needs libraries t= o be supported, and either more libraries to route it to a socket/fd like f= ifos, or more libraries to handle the stream outside of a normal socket by = a server process=2E I believe it makes sense to stick with a lightweight an= d reliable solution=2E The benefit of QUIC that I see is less stress on a N= AT router, but multiple TCP sockets work just fine in the wild, I've been t= esting SNIF for months now=2E > > > >> >DETAILED COMMENTS >> >A number of the design choices here seem suboptimal=2E These would >> >mostly go away if you adopted the strategy I propose above=2E However, >> >I note them in case you do not do so=2E >> > >> >* If I am reading this protocol correctly, there is no way to >> > change the private key of a server in a given name=2E If that's >> > correct, it seems suboptimal=2E >> >> The private key is regenerated when you hard reset the device, along wi= th >> allocating a new CN=2E The former CN gets permanently retired=2E The ru= le is - >> 1 CN =3D=3D 1 private key=2E It's for the security audit purpose - if y= ou ever >> find certs with same or overlapping CNs but different public keys - the= CA >> proxy is permanently compromised and cannot be trusted anymore=2E >> > >This seems like an unfortunate set of properties, for several reasons: > >1=2E You then need to disseminate new domain names if you ever want to ch= ange >your key=2E If the IoT device has an interactive browser - it's simple=2E If it doesn'= t - the onboarding is outlined in the security section, and is the topic of= my next draft in more details=2E >2=2E It means you can't have two keys for the same server name, so (for >instance) you can't easily change from RSA to ECDSA=2E If you want to experiment with algorithms - hard reset the device to rekey= it=2E I believe makes sense=2E And, a combo RSA+EC is always an option=2E > >Of course you could have "a=2Eb=2Eexample=2Ecom" and "c=2Eb=2Eexample=2Ec= om" and issue >two certificates with "*=2Eb=2Eexample=2Ecom" but now you are back to the= same >problem of two keys with one name=2E > >Incidentally, it's not clear to me that this inference about the CA proxy >is correct=2E We know that it is possible under certain conditions to use >network-level attacks to get certificates misissued=2E In this case, you >could have two certificates for one name with no malfeasance by the proxy= =2E When any duplicate CN is detected - raise an alert, investigate, revoke wr= ong certs, keep a record of the case=2E If any new duplicates are detected - wash, rinse, repeat=2E But if the proxy is compromised too often, whether for network reasons or = not - it's a lousy proxy that cannot be trusted, hope you agree=2E > > >> >> >* It seems like you are establishing a new TCP connection to >> > the device for each incoming TCP connection=2E That is not >> > going to have great performance=2E I would instead mux all >> > the data over a single connection (see MASQUE, supra)=2E >> >> See comments above regarding multiplexing=2E >> > >I don't really agree, but I don't think we can defer this point=2E > > >>* It seems like you are having the relay connect to the device=2E >> > That is going to be a problem if the device is behind a >> > NAT or any kind of stateful inspection filter=2E Instead, >> > I would have all connections be outgoing=2E >> > >> >> No=2E All connections are outgoing from the device=2E Works fine with N= AT and >> (reasonable) firewalls, I have a pre-production instance that I'm actua= lly >> using to send this email=2E >> > >OK=2E This was not clear to me=2E > > > >> >* Requiring the Relay to validate the server's TLS certificate, >> > as defined in S 4=2E2, makes the Relay much more complicated >> > as it has to have a WebPKI stack in it=2E >> > >> >> The relay runs on a server, Linux usually=2E It's not a problem to vali= date >> a certificate on a Linux server, you have PKI roots in any standard >> installation=2E >> > >It's certainly more work to validate than not=2E For instance, how do you >handle revocation? OCSP=2E To save resources, the SNIF relay may require connectors to staple= OCSP, and reject otherwise=2E > >>I also, I don't understand this text: >> > >> > Since each certificate issued by a CA remains on the certificate >> > transparency public records, it is RECOMMENDED for SNIF CA Proxy to >> > only issue Certificates with a wildcard CN=2E This way, the actual >> > Connector's hostname (Section 3=2E2) will not be listed on the publ= ic >> > records=2E >> > >> >Can you provide an example of what you mean here? If the Connectors >> >are named a=2Eexample=2Ecom, b=2Eexample=2Ecom, and c=2Eexample=2Ecom,= you obviously >> >cannot issue any of them *=2Eexample=2Ecom=2E OTOH, if you have them h= ave >> >=2Ea=2Eexample=2Ecom and =2Eb=2Eexample=2Ec= om, then >> >how does it help to issue *=2Ea=2Eexample=2Ecom? >> >> A real example: >> CN =3D *=2Esnif-054e2fa720a6-7d8cf7d2=2Esnif=2Exyz >> Hostname =3D rf205699c9be3=2Esnif-054e2fa720a6-7d8cf7d2=2Esnif=2Exyz >> >> The CN is listed on public transparency logs, the hostname is not=2E It= 's an >> extra step to safeguard the hostname from DoS attempts=2E >> > >Thanks for the explanation=2E > >-Ekr From nobody Thu Feb 24 19:58:41 2022 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DD93A116C for ; Thu, 24 Feb 2022 19:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.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 2jRJhGazyEAR for ; Thu, 24 Feb 2022 19:58:34 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 AB3BD3A0A51 for ; Thu, 24 Feb 2022 19:58:34 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id c14so3398096ilm.4 for ; Thu, 24 Feb 2022 19:58:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3Z7IzMOCnLEwcYNvxwJum7JBexoRNrJHBOGZU+vVzp0=; b=cMR7oeQZ/ceHnElAdNbCxmyY58PfmPUJLi6XeQOGCoHDWWJEt7RkCMv6mJzILtXCEW n0xf+b/0dSKqz5+/AYxxz6WURA+CapPJQDe38rnqtF5iZ+fE+/eEZIc0ivjLAKcqUQAU aVhOf0nbLRTXxcFzRqWJx5iPXKgtoNI3QwKL9uGfZLpZZEhXq23frJU92eC+aTEoGWpX mq9ih3wDHaQ/28/zJIEoGbqQf6THoKUVZfMI08iHmw4gn/vtyKRms6gOJYIZRTN42184 Fbp1qo9hGFUFW6DoIVxJiVjVn5camcrkW7k01c0nWwZKyyaUO8umtOnd0d0Kq/XbwEO8 hucw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3Z7IzMOCnLEwcYNvxwJum7JBexoRNrJHBOGZU+vVzp0=; b=M8IZiDZjOzaZwq8gvcC0gUPoracTL2CbBPuLv/rsQlZOjnefD5qY8pnCmooPabEGeC +1j3So/tzbU1HmCjk88jF0X6zm/vjwOr1x7fuwnYWadPH9iqNi4Ud9lExFDm8BSPQXOM Q9ZYZ78NzsSAF5iocqedcE4JqXiD2ivwETVBI/uXsX4P5awPKLbERLXCBWwpEnKJb4Ql 2hvRD0kHLtyrhimnr9ztKTgLUTiLqk0BWlaMq5hyS3X+I6WOHammFmwPUzYArKaItXef sdzzupG/9ukR2we7suvmqMttjrJygr3u+gWs/HWkIajfKEtGAfWBGAyNb8+MBiwxZJDy CcFA== X-Gm-Message-State: AOAM532gnJLpTp9Qj8jmZGBabk2h9PMpj2OjiHpMqnTlOIpgHZ2ZzMe2 +fPWf35US7MhaebLMTTFp/wpLzLbkHucEydcIrdBCOsRyFHcQA== X-Google-Smtp-Source: ABdhPJzfezHFsICyB98S+Ux9vnBDzMzeclkR6Kc3f4PsbZX1n603hcQyARN84Ut/aOYXI/bVTk1RGOinxlpIhYlRbEA= X-Received: by 2002:a05:6e02:b4c:b0:2be:aaec:271c with SMTP id f12-20020a056e020b4c00b002beaaec271cmr5045271ilu.219.1645761513727; Thu, 24 Feb 2022 19:58:33 -0800 (PST) MIME-Version: 1.0 References: <0075B437-024A-4D84-ABD7-92FE8DAFA59F@commercebyte.com> <5A22A937-DCEF-407C-A244-6A84247DFB74@commercebyte.com> <69A8786D-1992-4B7E-BB3A-FF9C0F576B54@commercebyte.com> In-Reply-To: <69A8786D-1992-4B7E-BB3A-FF9C0F576B54@commercebyte.com> From: Eric Rescorla Date: Thu, 24 Feb 2022 19:57:57 -0800 Message-ID: To: Jim Zubov Cc: IETF SecDispatch Content-Type: multipart/alternative; boundary="00000000000069404505d8cfb6e0" Archived-At: Subject: Re: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2022 03:58:40 -0000 --00000000000069404505d8cfb6e0 Content-Type: text/plain; charset="UTF-8" Hi Jim, I'm going to respond to this message, but I don't think we're saying much new here, so I'll probably stop after that. There will be plenty of time to discuss disposition during the SECDISPATCH meeting. On Thu, Feb 24, 2022 at 7:22 PM Jim Zubov wrote: > > > On February 24, 2022 7:10:25 PM EST, Eric Rescorla wrote: > >On Thu, Feb 24, 2022 at 3:22 PM Jim Zubov > >wrote: > > >What I am proposing also has this property. > > > >- For TLS, the proxy behaves as in your document, switching on SNI (though > >not validating the certificate) and forwarding the encrypted data. > >- For HTTP, the proxy behaves much the same way but switches on the Host: > >header. > > > >Therefore it is end-to-end for any encrypted traffic. > > Basically, everything boils down to 2 questions - > 1. who has access to the private key, > 2. who interacts with the CA to issue the cert > > When the solution is end-to-end - the answer to (1) is always - only the > device itself. > Let's review (2) assuming the CA speaks ACME. There are 3 common challenge > types - HTTP, DNS and ALPN. > HTTP: Need to either relay plain HTTP from/to the device, or the proxy to > serve HTTP. > DNS: Need to either relay DNS from/to the device, or the proxy to serve > DNS. > Or to have the proxy *configure* the DNS (which it will have to anyway, because it controls the zone) but we can ignore that for the moment, as I agree that we want to support non-DNS challenge types. ALPN: Need to either relay TLS to a device with a self-signed cert, > authenticated by means other than the cert, or the proxy to route specific > hostname to TLS with a self-signed cert hosted by the proxy itself. > I follow simple security rules in SNIF design which I believe are > reasonable - the control connection MUST present a valid certificate that > matches the hostname, and the service connection MUST be TLS with the same > certificate. According to these rules, plain HTTP is out, self-signed cert > is out, relayed DNS would involve some new protocol layer. > Yes but my point is that these rules are to some extent arbitrary and they result in a lot of complexity in the rest of the system. And if you relax them, then you are left with a simple proxy system that seems to have roughly the same security properties. So I think you need a stronger argument than that these rules are reasonable. Rather, you need to argue that they produce a better system, which I don't see you doing here. The only real benefit I see you list is: > As an additional benefit of such design, the proxy may switch between CAs, or use any applicable protocols, whether ACME or something else, without any modification to the SNIF connector on the device. It's not clear to me that this is an advantage. It seems to me one could just as easily argue it was a disadvantage because it makes it impossible for the device to select its own CA and ACME methods. > >>If you just do this, then you shouldn't need any other mechanism > >> >because the device will be able to fulfill the ordinary ACME HTTP > >> >Challenge (RFC 8555; S 8.3) and the ALPN challenge (RFC 8737) without > >> >any additional effort by the proxy. In particular, the proxy will > >> >not need to engage with ACME because the back-end server can > >> >do that. > >> > >> ALPN involves communications to the target hostname using a self-signed > >> certificate. SNIF relay is designed to not allow any self-signed, or > >> otherwise not publicly trusted, certificates, it makes security audit a > >> whole lot easier. Therefore, a trusted certificate needs to be > negotiated > >> through the CA proxy (or by other means) before being able to accept any > >> relayed connections to the hostname. > >> > > > >I understand that this is part of your design, but I don't see that it > >provides much security value. Because the proxy assigns the hostnames, it > >already knows which IoT device is associated with which hostname, so it > can > >use that information directly without having to examine the server's > >certificate. Regardless, you could use the HTTP ACME Challenge without > >allowing self-signed certs. > > Yes, the proxy knows the hostname. But it doesn't have the private key, > thus cannot use the cert. And if it issues a duplicate cert - it's > auditable through the transparency logs (more on it later). > As for the proxy knowing the identity of the IoT device - it depends on > how the initUrl and the cert issue authorization are implemented, I left it > to the liberty of the implementor in the draft. I think perhaps you're misunderstanding me. As far as I can tell, there are only two reasons for the proxy to look at the data coming to it at all: 1. To route to the right device via the SNI 2. To authenticate that the device it is routing to is the correct one authorized for that name (and hence associated with the SNI). My point is that (2) can be just as handily done by having the device authenticate to the proxy via some non-certificate mechanism: the proxy doesn't need to authenticate the device via the WebPKI because it knows a priori which device has which name. The consequence of that change is that the proxy need not do any TLS cert validation and can simply switch on SNI without looking at the rest of the handshake. >>Second, I don't think you need to define a new proxy protocol. While > >> >MASQUE isn't currently specified for this kind of server application, > >> >it seems like a natural extension and MASQUE would handle all the > >> >transport mechanics for you, thus making life a lot simpler. > >> > >> The reason I use a separate TCP socket for each connection is to > simplify > >> the implementation of SNIF connector in conjunction with a server > process > >> on the IoT device. Using snif-srv, the connector opens a TCP socket, > sends > >> a SNIF ACCEPT message in plain text, and immediately hands the socket > off > >> to the process which will start TLS negotiation as a server peer, just > like > >> a regular server would do after accepting the socket. It's possible to > >> design the control and multiple service connections to be multiplexed > over > >> QUIC, and use a software demux, and possibly fifos, on the connector > side > >> to interact with the server processes, but I believe separate TCPs is a > >> cleaner answer in a resource constrained IoT environment. > >> > > > >Hmm... It's not clear to me why you think that this uses fewer resources. > >Can you explain why you think that? > > Sure. TCP has been around for ~50 years, is implemented in every modern > OS, has been tested, refined and optimized for decades. > QUIC, on the other side, is still one foot in a petri dish. No disrespect > here, but a TCP socket is a standard OS call while QUIC needs libraries to > be supported, and either more libraries to route it to a socket/fd like > fifos, or more libraries to handle the stream outside of a normal socket by > a server process. I believe it makes sense to stick with a lightweight and > reliable solution. The benefit of QUIC that I see is less stress on a NAT > router, but multiple TCP sockets work just fine in the wild, I've been > testing SNIF for months now. > I would make two points here: 1. MASQUE is specified to work over H2, not just QUIC. H2 is very widely used, so I don't think there's much concern about stability. 2. The Internet is a complicated place and just because you are not seeing issues in your environment does not mean that there will not be issues in others. > >2. It means you can't have two keys for the same server name, so (for > >instance) you can't easily change from RSA to ECDSA. > > If you want to experiment with algorithms - hard reset the device to rekey > it. I believe makes sense. And, a combo RSA+EC is always an option. > This is inconsistent with essentially all modern TLS practice for upgrading, which is to have the server able to run multiple algorithm profiles and have the client and server negotiate an acceptable intersection. That seems like a big regression to take, and will create real interop issues during periods of transition, for instance, when some clients only support A and some support A+B. I'm not sure what you mean by "combo RSA + EC". It's true that you can run RSA with EC key establishment, but what I'm talking about is having both an RSA and an EC certificate. To the best of my knowledge it is not possible to get a WebPKI certificate with both algorithms and it's very unclear what the semantics of such a certificate would be. I'm going to stop here because I don't think the rest of this is that useful to try to nail down at this time. -Ekr --00000000000069404505d8cfb6e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jim,

I'm going to res= pond to this message, but I don't think we're saying much new
=
here, so I'll probably stop after that. There will be plenty of ti= me to discuss
disposition during the SECDISPATCH meeting.

On Thu, Feb 24, 2022 at 7:22 PM Jim Zubov <ietf-list@commercebyte.com> wrote:=


On February 24, 2022 7:10:25 PM EST, Eric Rescorla <ekr@rtfm.com> wrote:
>On Thu, Feb 24, 2022 at 3:22 PM Jim Zubov <ietf-list@commercebyte.com> >wrote:

>What I am proposing also has this property.
>
>- For TLS, the proxy behaves as in your document, switching on SNI (tho= ugh
>not validating the certificate) and forwarding the encrypted data.
>- For HTTP, the proxy behaves much the same way but switches on the Hos= t:
>header.
>
>Therefore it is end-to-end for any encrypted traffic.

Basically, everything boils down to 2 questions -
1. who has access to the private key,
2. who interacts with the CA to issue the cert

When the solution is end-to-end - the answer to (1) is always - only the de= vice itself.
Let's review (2) assuming the CA speaks ACME. There are 3 common challe= nge types - HTTP, DNS and ALPN.
HTTP: Need to either relay plain HTTP from/to the device, or the proxy to s= erve HTTP.
DNS: Need to either relay DNS from/to the device, or the proxy to serve DNS= .

Or to have the proxy *configure* the = DNS (which it will have to anyway, because it controls the zone) but we can= ignore that for the moment, as I agree that we want to support non-DNS cha= llenge types.


ALPN: Need to either relay TLS to a device with a self-signed cert, authent= icated by means other than the cert, or the proxy to route specific hostnam= e to TLS with a self-signed cert hosted by the proxy itself.
I follow simple security rules in SNIF design which I believe are reasonabl= e - the control connection MUST present a valid certificate that matches th= e hostname, and the service connection MUST be TLS with the same certificat= e. According to these rules, plain HTTP is out, self-signed cert is out, re= layed DNS would involve some new protocol layer.

<= /div>
Yes but my point is that these rules are to some extent arbitrary= and they result in a lot of complexity in the rest of the system. And if y= ou relax them, then you are left with a simple proxy system that seems to h= ave roughly the same security properties. So I think you need a stronger ar= gument than that these rules are reasonable. Rather, you need to argue that= they produce a better system, which I don't see you doing here. The on= ly real benefit I see you list is:

> As an addi= tional benefit of such design, the proxy may switch between=20 CAs, or use any applicable protocols, whether ACME or something else,=20 without any modification to the SNIF connector on the device.
It's not clear to me that this is an advantage. It seems to= me one could just as easily argue it was a disadvantage because it makes i= t impossible for the device to select its own CA and ACME methods.

=C2=A0
>>If you just do this, then you shouldn't need any other mechanis= m
>> >because the device will be able to fulfill the ordinary ACME H= TTP
>> >Challenge (RFC 8555; S 8.3) and the ALPN challenge (RFC 8737) = without
>> >any additional effort by the proxy. In particular, the proxy w= ill
>> >not need to engage with ACME because the back-end server can >> >do that.
>>
>> ALPN involves communications to the target hostname using a self-s= igned
>> certificate. SNIF relay is designed to not allow any self-signed, = or
>> otherwise not publicly trusted, certificates, it makes security au= dit a
>> whole lot easier. Therefore, a trusted certificate needs to be neg= otiated
>> through the CA proxy (or by other means) before being able to acce= pt any
>> relayed connections to the hostname.
>>
>
>I understand that this is part of your design, but I don't see that= it
>provides much security value. Because the proxy assigns the hostnames, = it
>already knows which IoT device is associated with which hostname, so it= can
>use that information directly without having to examine the server'= s
>certificate. Regardless, you could use the HTTP ACME Challenge without<= br> >allowing self-signed certs.

Yes, the proxy knows the hostname. But it doesn't have the private key,= thus cannot use the cert. And if it issues a duplicate cert - it's aud= itable through the transparency logs (more on it later).
As for the proxy knowing the identity of the IoT device - it depends on how= the initUrl and the cert issue authorization are implemented, I left it to= the liberty of the implementor in the draft.

I think perhaps you're misunderstanding me. As far as I can tell, th= ere are only two reasons for the proxy to look at the data coming to it at = all:

1. To route to the right device via the SNI
2. To authenticate that the device it is routing to is the correct= one authorized for that name (and hence associated with the SNI).

My point is that (2) can be just as handily done by having= the device authenticate to the proxy via some non-certificate mechanism: t= he proxy doesn't need to authenticate the device via the WebPKI because= it knows a priori which device has which name. The consequence of that cha= nge is that the proxy need not do any TLS cert validation and can simply sw= itch on SNI without looking at the rest of the handshake.

>>Second, I don't think you need to define a new proxy protocol. = While
>> >MASQUE isn't currently specified for this kind of server a= pplication,
>> >it seems like a natural extension and MASQUE would handle all = the
>> >transport mechanics for you, thus making life a lot simpler. >>
>> The reason I use a separate TCP socket for each connection is to s= implify
>> the implementation of SNIF connector in conjunction with a server = process
>> on the IoT device. Using snif-srv, the connector opens a TCP socke= t, sends
>> a SNIF ACCEPT message in plain text, and immediately hands the soc= ket off
>> to the process which will start TLS negotiation as a server peer, = just like
>> a regular server would do after accepting the socket. It's pos= sible to
>> design the control and multiple service connections to be multiple= xed over
>> QUIC, and use a software demux, and possibly fifos, on the connect= or side
>> to interact with the server processes, but I believe separate TCPs= is a
>> cleaner answer in a resource constrained IoT environment.
>>
>
>Hmm... It's not clear to me why you think that this uses fewer reso= urces.
>Can you explain why you think that?

Sure. TCP has been around for ~50 years, is implemented in every modern OS,= has been tested, refined and optimized for decades.
QUIC, on the other side, is still one foot in a petri dish. No disrespect h= ere, but a TCP socket is a standard OS call while QUIC needs libraries to b= e supported, and either more libraries to route it to a socket/fd like fifo= s, or more libraries to handle the stream outside of a normal socket by a s= erver process. I believe it makes sense to stick with a lightweight and rel= iable solution. The benefit of QUIC that I see is less stress on a NAT rout= er, but multiple TCP sockets work just fine in the wild, I've been test= ing SNIF for months now.

I would make t= wo points here:

1. MASQUE is specified to work ove= r H2, not just QUIC. H2 is very widely used, so I don't think there'= ;s much concern about stability.
2. The Internet is a complicated= place and just because you are not seeing issues in your environment does = not mean that there will not be issues in others.

= =C2=A0
>2. It means you can't have two keys for the same server name, so (f= or
>instance) you can't easily change from RSA to ECDSA.

If you want to experiment with algorithms - hard reset the device to rekey = it. I believe makes sense. And, a combo RSA+EC is always an option.

This is inconsistent with essentially all mode= rn TLS practice for upgrading,
which is to have the server able t= o run multiple algorithm profiles and
have the client and server = negotiate an acceptable intersection. That
seems like a big regre= ssion to take, and will create real interop issues
during periods= of transition, for instance, when some clients only
support A an= d some support A+B.

I'm not sure what you = mean by "combo RSA + EC". It's true that you
can ru= n RSA with EC key establishment, but what I'm talking about is
having both an RSA and an EC certificate. To the best of my knowledge
it is not possible to get a WebPKI certificate with both algorithms = and it's
very unclear what the semantics of such a certificat= e would be.

I'm going to stop here because I d= on't think the rest of this is that useful
to try to nail dow= n at this time.

-Ekr
--00000000000069404505d8cfb6e0-- From nobody Fri Feb 25 17:35:43 2022 Return-Path: X-Original-To: secdispatch@ietf.org Delivered-To: secdispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 458753A1097; Fri, 25 Feb 2022 17:29:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rdd@cert.org, secdispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164583895227.24617.1939040203283436909@ietfa.amsl.com> Date: Fri, 25 Feb 2022 17:29:12 -0800 Archived-At: Subject: [Secdispatch] secdispatch - Requested session has been scheduled for IETF 113 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2022 01:29:19 -0000 Dear Mohit Sethi, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. secdispatch Session 1 (2:00 requested) Tuesday, 22 March 2022, Afternoon Session II 1430-1630 Room Name: Grand Park Hall 3 size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/113/sessions/secdispatch.ics Request Information: --------------------------------------------------------- Working Group Name: Security Dispatch Area Name: Security Area Session Requester: Mohit Sethi Number of Sessions: 1 Length of Session(s): Number of Attendees: 200 Conflicts to Avoid: People who must be present: Benjamin Kaduk Kathleen Moriarty Mohit Sethi Paul Wouters Richard Barnes Roman Danyliw Resources Requested: Special Requests: Please avoid conflict with any Security related BoF. ---------------------------------------------------------