From nobody Thu Dec 23 16:28:57 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866463A0CF8; Thu, 23 Dec 2021 16:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aX750VbFJun3; Thu, 23 Dec 2021 16:28:33 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345FF3A0CF9; Thu, 23 Dec 2021 16:28:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6294D38E17; Thu, 23 Dec 2021 19:33:12 -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 0fVKxvrYD-73; Thu, 23 Dec 2021 19:33:11 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2EBE038E16; Thu, 23 Dec 2021 19:33:11 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1640305991; bh=FglzMtuao+aQa+jxH8XFa+mnJO2GiBWfSSnVYFOXO/o=; h=From:To:CC:Subject:In-Reply-To:References:Date:From; b=1AsYtDG/8AMgNj3ZMy2N1duENRvpx1HyVO/JE6j2mRcgPoA4R0BQdFhICNcAtEE/2 PvjZPZPzg32HJKt9Hgtwm6ep+yR0XCogFs1BMda0V1QOL+gBwG8h4KsI5fT0u5TJ7c F4OGU+FFk4j2KB9bXd5He1iiGv/LVDyZnZhPmTC9EBmQRNx4TATLMyB74nRhNN84Ph einnVb6zAoNAc/ArgVxKcxuYwPUlqZXrcCwUOT4176UU0Ll/MchSP9cY/p7jSjChBU ATLqqyESE2UHKqg2DumWM5g3yIs+wZsvzHXgbf7bON3ujWTHzwpBYifLtUW8OUC9LE IGfgjFaZyibtg== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DC8F2A3; Thu, 23 Dec 2021 19:28:28 -0500 (EST) From: Michael Richardson To: Ash Wilson , "iotops\@ietf.org" CC: dance@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Iotops] Secure browsing local web resources X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2021 00:28:39 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable sorry to pull an email thread out from a month ago. Ash Wilson wrote: > We had a brief discussion at IETF 110 in the DANISH BoF (which has ev= olved > into the DANCE WG) about how DNS-SD/mDNS might work to tie link-local > identities to DANE DNS records. This would give you the ability to ha= ve a > universal server identifier/public key in DNS which the IoT TLS server > could claim and prove to a client device. The downside here is that D= ANE is > not currently browser-supported, though it is supported in various TLS > libraries. Leaving aside the implementation challenges (we can't even get LL-IPv6 into= browsers...) What exactly would you put into the certificate here? How would the tie-in work? I'm not actually sure I think we need DANE. If one put ethernet addresses into the certificate, and one did traditional SLAAC to derive L3 Link-Local addresses (for the device) from that, then it would trivially (with current APIs) link getpeername(2) to what the browser sees in the certificate. There would be privacy implications doing this that would require RCM to fu= lly solve. How would DANE help? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmHFFCwACgkQgItw+93Q 3WVwbgf/bPi7P1sk4LwjTi1jGMsuXIEFNuCGq2KffBDKFoskrqgG7JUhZC7CzDnL EiRD6H9sj5wyNiQRjKJ97bBUwly0KpqUIbtuqo+8CTWeCiKKBR8s+aZ9IXkMyymd VL7oWFlHRFfPxVQS/N7blhvNfzgEejuMKwS4DoQ18ivLb2hBLynxtgmcVIei9ZY9 g+/TuumXh+Qw4G03RYu028ve4jcz4ZY43s3Gf4r7NX3PPUp+JuiPoSWpnuZOXg+Q uDMQGLXsJSuO7fZvK8OYBq/ffdoNWhXBGLtJtTHbceUBWNaZrf3oNY4yfkJ09Avz OOeEJcWZxFR/GpIYUGmILA1JJoJE3g== =zPRS -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 24 02:41:20 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40BA3A077D for ; Fri, 24 Dec 2021 02:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=nqminds-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 pKCpgF1zYvNt for ; Fri, 24 Dec 2021 02:41:13 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 BA18B3A0780 for ; Fri, 24 Dec 2021 02:41:13 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id o7so8570894ioo.9 for ; Fri, 24 Dec 2021 02:41:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nqminds-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p+pjQyVg7UhK2k9Pfgr6NY0hyYx7NCD/URjJWSlDWoY=; b=UzWgJihRfCtYUaE3t2HWxz2HzoVmmncO899fyb5357+g53b9imlabqsNaCMNKDaYbA OAhmYveBT1hPfXzye5vBvM3hoSk42kIcul0kHfDWxpZFo5kfxpVKlSuPvVLX9lwc2Smw FYzvbRiDBlcotyYRTxFWXtfi90qyhF4kXUrjFufuRpgg1llCZ9m2TofYqLWTvP+7tl4A y5Aotuy0bjxgZW4jG47k9f1qXOWKfoT4tyIzUL8OUWe7K9SgLcA9MRUSZ2Phlgbs4LtI zABhk6+/bjrPjEy4cApC8oY5EKcE3tOhl1WqBD8YW1jQxn0Ean3s3GWiDJK2LFp4jBEF 9inQ== 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=p+pjQyVg7UhK2k9Pfgr6NY0hyYx7NCD/URjJWSlDWoY=; b=dV2vJmq//dieTDocIL5eKLlvndM2s44okeFm68cm3rL1kFGkdPPRgNKoNZQzKjsqoB LE/g20niSIDX94WpFodJP2/DIrrJjko6WDDdHpOp7q9BeP2twsEHRMwnqh42XpHzNAHe ycLRRuMUsmFUzaa1gkK9fFe2JUxsPIdrqnhzRtyxvWUfnqZXQHId4c/u1A6oLY+fE1xQ 7a0HN3152mMAEpgDOvWsWwd/AE9VXyJ+4918+OLBcQFPO7NTyqSA472fZvjhLsYMkSpq ltqOsd9xyn3SOVfBT65ZZ/RDmPrUplvdU4j5CUFCROlv8FxDOkMYTqisvGPq8QDFMT/b Mrlg== X-Gm-Message-State: AOAM532vGmoch0jIbz4vMd9b14bY+L+r6zeGLVCYHGaGtlTTpcv4oiCq uUm7EKNZV28hEbOum5MgifhTExjtznTHny2xdNt8yWDIsWd8ppcP X-Google-Smtp-Source: ABdhPJxhAZ+hPXTk9tq/K0k/rdV713+mQws0a8ldr+zgIdIVROVs62VfdUzyZMlBw9DQFOXW8aPWJVCbPKOUb90Iyj4= X-Received: by 2002:a05:6638:14:: with SMTP id z20mr3105370jao.76.1640342471656; Fri, 24 Dec 2021 02:41:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nick Allott Date: Fri, 24 Dec 2021 10:41:00 +0000 Message-ID: To: Esko Dijk Cc: "iotops@ietf.org" Content-Type: multipart/alternative; boundary="000000000000555a2505d3e1fe28" Archived-At: Subject: Re: [Iotops] Secure browsing local web resources X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2021 10:41:19 -0000 --000000000000555a2505d3e1fe28 Content-Type: text/plain; charset="UTF-8" Following up on my earlier commitment to share drafts on the potential solution space. (Apologies for delay: approvals took some time, plus just had a dose of virus) https://manysecured.org/drafts/specs/ManySecured-SUIB/problem-overview On the above link please find the current draft documents that have been worked on within the IOTSF/ManySecured community. I must emphasise that this is work in progress. The intent of these documents is to - better explain/communicate the technical aspects of the problem - explore what a solution might look like and the qualities it needs to possess - move forward some technical solutions We still believe this to be a problem of utmost importance: it is the de facto standard method of provisioning/configuring home IOT devices and it is inherently insecure. Following on from the conversations at the IOTOPS meeting, if there are any known solutions to the problem, it would be good to know. And/or any mitigating mechanisms to reduce the exposure. We suspect, the only real way so of solving this issue, is to create a new class of browser, which has well defined semantics for securely negotiating TLS sessions on local internet connection. But to do this at scale and reliably, we need a different model for the provisioning of local certificates, and new set of browser guidelines to define how the browser interacts with the local certificate ecosystem. (ie it seems clear the current CA/Browser guidelines are not designed for this use case). But this is still a partially formed conjecture at this stage. The source markdown documents are available on this public repo: https://github.com/TechWorksHub/ManySecured-WGs/tree/main/ManySecured-SUIB (linked to in the the HTML documents) What do people think? Cheers Nick On Mon, 22 Nov 2021 at 10:30, Esko Dijk wrote: > Hi Nick, > > Agree with the problem as stated in your email and slides. (The latter > explore some interesting solutions.) > A solution in IETF scope may be some class of "IoT" server certificate > that is trusted only in link-local scope, also by browsers. (Trusted enough > to allow the user to view the page.) > This could be an IDevID-type certificate. > > For enhanced security the browser could even be instructed in some way (QR > code? 4-letter code?) to temporarily trust all IDevID certificates from > vendor X for the duration of the browser tab being open. > > regards > Esko > > IoTconsultancy.nl | Email/Teams: esko.dijk@iotconsultancy.nl > > > > -----Original Message----- > From: Iotops On Behalf Of Nick Allott > Sent: Friday, November 19, 2021 15:47 > To: iotops@ietf.org > Subject: [Iotops] Secure browsing local web resources > > Thanks for the opportunity to present last week. Pleased it generated some > discussion! [1]. The slides [2] I note neglected to include the reference > to the CA/Brower forum[3] guidelines (7.1.4.2.1) which help understand the > problem. > > Accessing local web base resources locally and securely, we think is an > important problem to address. The IETF community is better placed than > most/all to qualify and refine this requirement and help develop and > evaluate the potential solutions. > > These are the active questions we have, which it would be useful to get > confirmed (or refuted) > > 1. There is a problem: there is a clearly defined issue. > a) Bootstrapping a TLS connection between a browser and a local web > resource (IOT or not) on local internet (reserved IP address/Private Use) > is hard to do > b) Given (a) sniffing administrative passwords for local resource (e.g. > IOT), an otherwise intercepting traffic is relatively easy to do and > therefore a serious internal threat > > 2. It's a pervasive problem: the problem currently manifests itself on > many/most consumer routers and many/most IOT devices that connect via Wifi > and/or cabled IP. > > 3. There is no known best practice for practically and securely > authenticating local web clients against, local IP based IOT devices > > We would be delighted in ether outcome: either agreement in the statements > above, or a clear refutation of any of the issues. > > We hope to publicise the internal document outlining a potential solution > space next week. We are just cleaning the docs and making ready for > comment. I will follow up with the links asap, which assuming there is > agreement an issue exists - may help plant some seeds on how it can be > addressed > > > But in the interim, there are further comments/discussion that help > calibrate the problem, that would be great. > > Also reminder, public facing paper on the problem [4] > > [1] https://jabber.ietf.org/jabber/logs/iotops/2021-11-12.html > [2] > https://datatracker.ietf.org/doc/slides-112-iotops-suib-browsing-local-web > -resources-in-a-secure-usable-manner-iot-device-configuration-as-a-special > -case/ > > [3] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.0.pdf > [4] > https://manysecured.net/wp-content/uploads/2021/03/MS-Secure-Intranet-Brow > ser-WG.pdf > > > Nick Allott > nquiringminds > > -- > Iotops mailing list > Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops > --000000000000555a2505d3e1fe28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Following up on my earlier commitment to share drafts on the pot= ential solution space. (Apologies for delay: approvals took some time, plus= just had a dose of virus)=C2=A0

https://manysecured.org/drafts/= specs/ManySecured-SUIB/problem-overview

On the above link please= find the current draft documents that have been worked on within the IOTSF= /ManySecured community.

I must emphasise that this is work in progress. = The intent of these documents is to=C2=A0

=C2=A0- better explain/communi= cate the technical=C2=A0aspects of the problem
=C2=A0- explore what a soluti= on might look like and the qualities=C2=A0it needs to possess
=C2=A0- move f= orward some technical solutions

We still believe=C2=A0this to be a probl= em=C2=A0of utmost=C2=A0importance: it is the de facto=C2=A0standard method = of provisioning/configuring=C2=A0home IOT devices and it is inherently=C2= =A0insecure.=C2=A0

Following on from the conversations at the IOTOPS mee= ting, if there are any known solutions to the problem, it would=C2=A0be goo= d to know. And/or any mitigating mechanisms=C2=A0to reduce the exposure.
We suspect, the only real way so of solving this issue, is to create a new= class of browser, which has well defined semantics for securely negotiatin= g TLS sessions on local internet connection.=C2=A0
But to do this at scale a= nd reliably, we need a different model for the provisioning of local certif= icates, and new set of browser guidelines to define how the browser interac= ts with the local certificate ecosystem.
(ie it seems clear the current CA/B= rowser guidelines are not designed for this use case). But this is still a = partially formed conjecture at this stage.=C2=A0

The source markdown doc= uments are available on this public repo:=C2=A0https://github.c= om/TechWorksHub/ManySecured-WGs/tree/main/ManySecured-SUIB (linked to i= n the the HTML documents)=C2=A0

What do people think?

Cheers

Nick= =C2=A0







On Mon, 22 Nov 2021 at 10:30, Esko Dijk= <esko.dijk@iotconsultanc= y.nl> wrote:
Hi Nick,

Agree with the problem as stated in your email and slides. (The latter expl= ore some interesting solutions.)
A solution in IETF scope may be some class of "IoT" server certif= icate that is trusted only in link-local scope, also by browsers. (Trusted = enough to allow the user to view the page.)
This could be an IDevID-type certificate.

For enhanced security the browser could even be instructed in some way (QR = code? 4-letter code?) to temporarily trust all IDevID certificates from ven= dor X for the duration of the browser tab being open.

regards
Esko

IoTconsultancy.nl=C2=A0 |=C2=A0 Email/Teams: esko.dijk@iotconsultancy.nl



-----Original Message-----
From: Iotops <iotops-bounces@ietf.org> On Behalf Of Nick Allott
Sent: Friday, November 19, 2021 15:47
To: iotops@ietf.org
Subject: [Iotops] Secure browsing local web resources

Thanks for the opportunity to present last week. Pleased it generated some<= br> discussion! [1]. The slides [2] I note neglected to include the reference to the CA/Brower forum[3] guidelines (7.1.4.2.1) which help understand the<= br> problem.

Accessing local web base resources locally and securely, we think is an
important problem to address. The IETF community is better placed than
most/all to qualify and refine this requirement and help develop and
evaluate the potential solutions.

These are the active questions we have, which it would be useful to get
confirmed (or refuted)

1. There is a problem: there is a clearly defined issue.
a) Bootstrapping a TLS connection between a browser and a local web
resource (IOT or not) on local internet (reserved IP address/Private Use) is hard to do
b) Given (a) sniffing administrative passwords for local resource (e.g.
IOT), an otherwise intercepting traffic is relatively easy to do and
therefore a serious internal threat

2. It's a pervasive problem: the problem currently manifests itself on<= br> many/most consumer routers and many/most IOT devices that connect via Wifi<= br> and/or cabled IP.

3. There is no known best practice for practically and securely
authenticating local web clients against, local IP based IOT devices

We would be delighted in ether outcome: either agreement in the statements<= br> above, or a clear refutation of any of the issues.

We hope to publicise the internal document outlining a potential solution space next week. We are just cleaning the docs and making ready for
comment. I will follow up with the links asap, which assuming there is
agreement an issue exists - may help plant some seeds on how it can be
addressed


But in the interim, there are further comments/discussion that help
calibrate the problem, that would be great.

Also reminder, public facing paper on the problem [4]

[1] https://jabber.ietf.org/jabber/logs/io= tops/2021-11-12.html
[2]
https://datatracker.i= etf.org/doc/slides-112-iotops-suib-browsing-local-web
-resources-in-a-secure-usable-manner-iot-device-configuration-as-a-special<= br> -case/
[3] https://cabforum.org/wp-con= tent/uploads/CA-Browser-Forum-BR-1.8.0.pdf
[4]
https://manysecu= red.net/wp-content/uploads/2021/03/MS-Secure-Intranet-Brow
ser-WG.pdf

Nick Allott
nquiringminds

--
Iotops mailing list
Iotops@ietf.org https://www.ietf.org/mailman/listinfo/iotops
--000000000000555a2505d3e1fe28-- From nobody Fri Dec 24 09:50:03 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AAD3A0E76 for ; Fri, 24 Dec 2021 09:50:01 -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 (2048-bit key) header.d=valimail.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 UP0roXHNOIP2 for ; Fri, 24 Dec 2021 09:49:56 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 217EC3A0E74 for ; Fri, 24 Dec 2021 09:49:55 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id z9so8129869qtj.9 for ; Fri, 24 Dec 2021 09:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AG0poXPd8tamixw5MlvymC7MTj9M4tS3um6NFU5GtIg=; b=ENT8QR0aoMua/iHY0jGsyd4wB9XeCSfm8G0dqlSSJc/6D4ZLuAhzoll9SV6WE2Klra QsC4dSZ1/lOB4aB7LCKwv4mQBBM/cRzUouL23TZUI4uVZa0l94meDcXv3pmoAy+DYB6T uOumOnA4WgfQ+Jvtkf+C4sRFV1YpwEZKV/VozZeqXzn3JU7++Osi01s6Raz+YC/2lI9C d9UYWvOlfo2obfSPe0DcND4+lQi8VM49S+KimoHDelxpPi6HVwTZgW0RfV/8Ae43/h0R Lw2TxIfDm+m6z35nH8zmcxJDr2XaJ/YthH8JGYrdLaaUOzixJnBTN3+AYOw5jfRauRE2 flGg== 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=AG0poXPd8tamixw5MlvymC7MTj9M4tS3um6NFU5GtIg=; b=3d53Kl//av8pezR5iHKYgl58GIkrG5ZVr12gZhMIT7/ctthNhCwhnaEkmcJw8VxQXX xDfBuTVOGGNmFG7W0y+Ba+eEQ+M9LwE3/KJVowJ3mQ0XjOcI8y7kypehetUZ0vfeq+a/ RPWBGrBffHdtP6n9HiXHCLj0jnAnmpGQVIfDut1SKtXRnegEez5sfBRLwZJ9EhSqVBLZ pjpDSAJ3FU07q+gt/Md5sofUS8fo/jJ2z1gRBufzAYJN7fZfjK1gVaQ1BJkQds5fpejo DhZYkripQE9e2LUEmTGuOdksX4ykWqR2dymsJ5xWVZf3RCEVbzdPT5VishZPIDb6YRYz JUwQ== X-Gm-Message-State: AOAM530ysMtOLzSN20ozZfdUMSXvwHMwCz8UYzFMQp/y0Zfikss14QSA Jl2E6XNyH4mnEkBw+Ggr50qq1ZyQ6wFGGuBiY8qqCQ== X-Google-Smtp-Source: ABdhPJx25TbNkk++NulCp3YSycO/oVYi5zOj9dL2qXhUWChiTDMbgtwu9poDw5MUGDFA9aZoTCzQP2X0wBE/6BW4KrY= X-Received: by 2002:a05:622a:394:: with SMTP id j20mr3040193qtx.578.1640368194417; Fri, 24 Dec 2021 09:49:54 -0800 (PST) MIME-Version: 1.0 References: <10960.1640305708@localhost> In-Reply-To: <10960.1640305708@localhost> From: Ash Wilson Date: Fri, 24 Dec 2021 09:49:43 -0800 Message-ID: To: Michael Richardson Cc: Ash Wilson , "iotops@ietf.org" , dance@ietf.org Content-Type: multipart/alternative; boundary="000000000000878bb605d3e7fb14" Archived-At: Subject: Re: [Iotops] [Dance] Secure browsing local web resources X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2021 17:50:01 -0000 --000000000000878bb605d3e7fb14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Michael, For a device with DANE ID a1b2c3._device.mfr.example, with an HTTPS service= : mDNS Announce: The device announces its own IP at ${HASH}.local where ${HASH} is a truncated hash of the DANE ID (using an approach like https://datatracker.ietf.org/doc/html/rfc8162#section-3, but hashing the entire DANE ID) IP address resolution: If there are no A or AAAA DNS records for a1b2c3._device.mfr.example, the client device uses ${HASH}.local for IP address lookup. It may be worthwhile to signal via a TXT (or some other) record at a1b2c3._device.mfr.example that the device is expected to announce using this pattern over mDNS. Only use mDNS for IP lookup if the responsible organization (domain owner) indicates such behavior is expected, and if there is no conflicting SRV record configured. Establishing a connection: Client software establishes a TLS session with the device using the IP address from mDNS, the DANE ID for SNI, and verifies the presented server certificate against the TLSA record at a1b2c3._device.mfr.example. It's worth noting that https://datatracker.ietf.org/doc/html/rfc7673#section-4.1 describes what might be an easier and more flexible way to convey the mDNS name, using an SRV record, instead of computing the ${HASH}.local identifier within the client software. On Thu, Dec 23, 2021 at 4:28 PM Michael Richardson wrote: > > sorry to pull an email thread out from a month ago. > > Ash Wilson wrote: > > We had a brief discussion at IETF 110 in the DANISH BoF (which has > evolved > > into the DANCE WG) about how DNS-SD/mDNS might work to tie link-loc= al > > identities to DANE DNS records. This would give you the ability to > have a > > universal server identifier/public key in DNS which the IoT TLS > server > > could claim and prove to a client device. The downside here is that > DANE is > > not currently browser-supported, though it is supported in various > TLS > > libraries. > > Leaving aside the implementation challenges (we can't even get LL-IPv6 > into browsers...) > > What exactly would you put into the certificate here? > How would the tie-in work? I'm not actually sure I think we need DANE. > > If one put ethernet addresses into the certificate, and one did tradition= al > SLAAC to derive L3 Link-Local addresses (for the device) from that, then = it > would trivially (with current APIs) link getpeername(2) to what the brows= er > sees in the certificate. > > There would be privacy implications doing this that would require RCM to > fully > solve. > > How would DANE help? > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > -- > Dance mailing list > Dance@ietf.org > https://www.ietf.org/mailman/listinfo/dance > --=20 *Ash Wilson * | Technical Director *e:* ash.wilson@valimail.com This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000878bb605d3e7fb14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michael,

For a device with DANE ID a= 1b2c3._device.mfr.example, with an HTTPS service:

= =C2=A0 mDNS Announce:
=C2=A0 =C2=A0 =C2=A0 The device announces i= ts own IP at ${HASH}.local where ${HASH} is a truncated hash of the DANE ID= (using an approach like https://datatracker.ietf.org/doc/html/rfc8162#section-3, but hashing the entire DANE ID)



It's worth noting th= at=C2=A0https://datatracker.ietf.org/doc/html/rfc7673#section-4.1 describes = what might be an easier and more flexible way to convey the mDNS name, usin= g an SRV record, instead of computing the ${HASH}.local identifier within t= he client software.


On Thu, Dec 23, 2021 at 4:28 PM Mic= hael Richardson <mcr+ietf@san= delman.ca> wrote:

sorry to pull an email thread out from a month ago.

Ash Wilson <ash.wilson=3D40valimail.com@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 > We had a brief discussion at IETF 110 in the DANISH BoF = (which has evolved
=C2=A0 =C2=A0 > into the DANCE WG) about how DNS-SD/mDNS might work to t= ie link-local
=C2=A0 =C2=A0 > identities to DANE DNS records. This would give you the = ability to have a
=C2=A0 =C2=A0 > universal server identifier/public key in DNS which the = IoT TLS server
=C2=A0 =C2=A0 > could claim and prove to a client device. The downside h= ere is that DANE is
=C2=A0 =C2=A0 > not currently browser-supported, though it is supported = in various TLS
=C2=A0 =C2=A0 > libraries.

Leaving aside the implementation challenges (we can't even get LL-IPv6 = into browsers...)

What exactly would you put into the certificate here?
How would the tie-in work?=C2=A0 I'm not actually sure I think we need = DANE.

If one put ethernet addresses into the certificate, and one did traditional=
SLAAC to derive L3 Link-Local addresses (for the device) from that, then it=
would trivially (with current APIs) link getpeername(2) to what the browser=
sees in the certificate.

There would be privacy implications doing this that would require RCM to fu= lly
solve.

How would DANE help?

--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide




--
Dance mailing list
Dance@ietf.org
https://www.ietf.org/mailman/listinfo/dance


--

Ash Wilson | Technical Director
e: <= a href=3D"mailto:ash.wilson@valimail.com" target=3D"_blank">ash.wilson@vali= mail.com

This email and all data transmitted with= it contains confidential and/or proprietary information intended solely fo= r the use of individual(s) authorized to receive it. If you are not an inte= nded and authorized recipient you are hereby notified of any use, disclosur= e, copying or distribution of the information included in this transmission= is prohibited and may be unlawful. Please immediately notify the sender by= replying to this email and then delete it from your system.<= /p>

--000000000000878bb605d3e7fb14-- From nobody Fri Dec 24 13:19:51 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0623A1105; Fri, 24 Dec 2021 13:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02rZXTb8EhBB; Fri, 24 Dec 2021 13:19:46 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688FD3A0840; Fri, 24 Dec 2021 13:19:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8188D38B6A; Fri, 24 Dec 2021 16:24:28 -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 xv6bzIVVZhtb; Fri, 24 Dec 2021 16:24:26 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D73D238B69; Fri, 24 Dec 2021 16:24:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1640381066; bh=G6uookN4NwW4WgE+iwMc8XPAysNZdsOvR/DZSdpD7oc=; h=From:To:Subject:In-Reply-To:References:Date:From; b=7iaN24gcpfBzlFdb464SyDxdnLg2T/AaTj3/XC2McYTeJFiTsEGYDEGMYvBjo2DOb slEJNPaLGqWZi4rS+T7rHy40K2i4a82vasaehb9EkYeoeIoS7L+wZyJp9tEOqVJE1h WBYjXIHPEHgtCQHZfNMR5qHU/Cuh3YRNxD8/erUFhUe7fDO4P/lQDOVP6LlYXTN+4z GUBjPfrBcEyoJgD0P8PZH1Z9b1eZwoey7efQ7Zd/WlBKJcg2m067uhbVxmUo9ler7k t/CsumxHLZ6Hs5C87KJd1kn0+IZEgynauc114kwBNnoEAnQr367rS0X76W4g1csMzj qeBUAO+qU03cQ== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4686A48F; Fri, 24 Dec 2021 16:19:41 -0500 (EST) From: Michael Richardson To: Ash Wilson , "iotops\@ietf.org" , dance@ietf.org In-Reply-To: References: <10960.1640305708@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Iotops] [Dance] Secure browsing local web resources X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2021 21:19:50 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ash Wilson wrote: > For a device with DANE ID a1b2c3._device.mfr.example, with an HTTPS > service: ... > mDNS Announce: > The device announces its own IP at ${HASH}.local where ${HASH} is a > truncated hash of the DANE ID (using an approach like > https://datatracker.ietf.org/doc/html/rfc8162#section-3, but hashing = the > entire DANE ID) > IP address resolution: > If there are no A or AAAA DNS records for a1b2c3._device.mfr.example, > the client device uses ${HASH}.local for IP address lookup. My reading of RFC6763 suggests that the lookup for ${HASH}.local could retu= rn a SRV record specifying where to connect, and the reference could be a FQDN ("a1b2c3._device.mfr.example"), and there could be a AAAA (A) RR returned as additional data. I investigated trying to configure this, but no software= I found could comprehend it without a lot of rework. > Establishing a connection: > Client software establishes a TLS session with the device using the > IP address from mDNS, the DANE ID for SNI, and verifies the presented > server certificate against the TLSA record at a1b2c3._device.mfr.exam= ple. So, I think that you've just described an entirely new RFC6125 mechanism. This is where I think that we get into trouble. I'm not I see what DANE contributes anything here. Wouldn't everything be the same if the server certificate was transmitted inband? If the client knows to map the ${HASH}.local to a1b2c3._device.mfr.example, then aren't w= e done? > It's worth noting that > https://datatracker.ietf.org/doc/html/rfc7673#section-4.1 describes w= hat > might be an easier and more flexible way to convey the mDNS name, usi= ng an > SRV record, instead of computing the ${HASH}.local identifier within = the > client software. I wonder if I'm describing the same thing above. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmHGOW0ACgkQgItw+93Q 3WVpzAf+PggEyPXuEpO3GXdw7tB1llRi+qTqQlt8698ZgGYzWeuSD61LSD/iPCEx 6ssmgJCfgNO/ZQrhLZqKlD3N3Rdab1Kw2MhV4Cdbb2HIUuzkI1ItswT5gSjPgjU+ hcIgenTtNPwosjAW5dqVnsl5dPB+VVpV8Ejq3gc1IS+MPFoba1rdARZxaidNiK3n hCul6pVdYi8yVrcRqJWCJKU8nE0hTaUuQ/nDhul1ESQINLQwNsBAmD1qkN0Cebqp xsVksZsEzGmG4XiHv9w/YDkGAAkeyQRVUcW/IpWtzmUNGbqAi0aNWpcgVHXby9mP RL6tagO3MwlHXpbBzLwJvxVDX4xC7Q== =k8A6 -----END PGP SIGNATURE----- --=-=-=--