Re: [Danish] [EXT] RE: IoT Device Identification with TLSA via Danish

Jacques Latour <Jacques.Latour@cira.ca> Mon, 21 June 2021 14:50 UTC

Return-Path: <Jacques.Latour@cira.ca>
X-Original-To: danish@ietfa.amsl.com
Delivered-To: danish@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7125F3A0959 for <danish@ietfa.amsl.com>; Mon, 21 Jun 2021 07:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFBkK---r0Id for <danish@ietfa.amsl.com>; Mon, 21 Jun 2021 07:50:09 -0700 (PDT)
Received: from albina.zerospam.ca (albina.zerospam.ca [199.27.221.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2013A0906 for <danish@ietf.org>; Mon, 21 Jun 2021 07:50:08 -0700 (PDT)
X-ZEROSPAM_FILTERED: true
Received: from albina.zerospam.ca (localhost [127.0.0.1]) by albina.zerospam.ca (Postfix) with ESMTP id 4G7srb4SwyzyN4; Mon, 21 Jun 2021 10:50:07 -0400 (EDT)
Authentication-Results: albina.zerospam.ca (ip=192.228.22.11); spf=none smtp.helo=mx1.cira.ca; spf=pass smtp.mailfrom=Jacques.Latour@cira.ca; dkim=none; dmarc=none (action=none) reason="No DMARC policy found" header.from=cira.ca
Received: from 127.0.0.1 (127.0.0.1:12000) (original ip: 192.228.22.11) by albina.zerospam.ca (Themis) with ESMTP id zZfXJj2AiKWdJkvubS1; Mon, 21 Jun 2021 10:50:06 -0400
Received: from mx1.cira.ca (nat.crp.cira.ca [192.228.22.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by albina.zerospam.ca (Postfix) with ESMTPS id 4G7srZ11zgzyN7; Mon, 21 Jun 2021 10:50:06 -0400 (EDT)
Received: from CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) by CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.2242.10; Mon, 21 Jun 2021 10:50:05 -0400
Received: from CRP-EX16-02.CORP.CIRA.CA ([fe80::c50f:56f4:1f3c:b748]) by CRP-EX16-02.CORP.CIRA.CA ([fe80::c50f:56f4:1f3c:b748%14]) with mapi id 15.01.2242.010; Mon, 21 Jun 2021 10:50:05 -0400
From: Jacques Latour <Jacques.Latour@cira.ca>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "danish@ietf.org" <danish@ietf.org>
Thread-Topic: [EXT] RE: IoT Device Identification with TLSA via Danish
Thread-Index: AddhKvcSXHMYMAB6StqY1oKWkaM4dwD3nhkgAGhz3EA=
Date: Mon, 21 Jun 2021 14:50:05 +0000
Message-ID: <7847f2fef4474c2c8ab7ea1b06d2d39b@cira.ca>
References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> <DBBPR08MB5915F04A83054BBEB4F9FE7BFA0C9@DBBPR08MB5915.eurprd08.prod.outlook.com>
In-Reply-To: <DBBPR08MB5915F04A83054BBEB4F9FE7BFA0C9@DBBPR08MB5915.eurprd08.prod.outlook.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Enabled=true; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_SetDate=2021-06-21T14:50:04Z; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Method=Standard; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_Name=Confidential; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_SiteId=f349b30c-7550-4f17-88da-269417631f54; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_ActionId=024940c3-c741-41ca-8799-fc26e14044a4; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_ContentBits=2
x-originating-ip: [10.2.36.1]
Content-Type: multipart/alternative; boundary="_000_7847f2fef4474c2c8ab7ea1b06d2d39bciraca_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/danish/gwXnL46A174qipGsovTKqK0-r7c>
Subject: Re: [Danish] [EXT] RE: IoT Device Identification with TLSA via Danish
X-BeenThere: danish@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DANE AutheNtication for Iot Service Hardening <danish.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/danish>, <mailto:danish-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/danish/>
List-Post: <mailto:danish@ietf.org>
List-Help: <mailto:danish-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/danish>, <mailto:danish-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jun 2021 14:50:21 -0000

Hi Hannes,

Yes, in my presentation on very first slide I said "we presented the IoT Registry many times in the past at many venues", the IoT Registry for us is an identity management system for mobile GMSA IoT SAFE enabled IoT devices. It's the gateway between the mobile network operators and the cloud/ASPs.


  *   See https://github.com/CIRALabs/CIRA-Secure-IoT-Registry/blob/38c3128651fbfcf8a0b5bd40523cd7dc12a5bc70/CIRA%20-%202020-01-22%20ICS%20Symposium.pdf

In short, in the IoT Registry we track the identity of the IoT device (public key or certificate) to a unique eSIM ID via IoT SAFE.

In this context, I'm a big fan of making available in the DNS w/DNSSEC the individual IoT device identity via the proposed DANISH mechanisms.

Jacques





CLASSIFICATION:CONFIDENTIAL
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Sent: June 19, 2021 8:51 AM
To: Jacques Latour <Jacques.Latour@cira.ca>; danish@ietf.org
Subject: [EXT] RE: IoT Device Identification with TLSA via Danish

Hi Jacques,

Thanks for sharing your slides. Since the slides are not meant to be self-explanatory I have a question for you: What is an IoT registry for you?
(You mention the term on slide 2 and it seems to be core to your presentation.)

Ciao
Hannes

From: Danish <danish-bounces@ietf.org<mailto:danish-bounces@ietf.org>> On Behalf Of Jacques Latour
Sent: Monday, June 14, 2021 4:41 PM
To: danish@ietf.org<mailto:danish@ietf.org>
Subject: [Danish] IoT Device Identification with TLSA via Danish

Hi,

Today I presented at the ICANN DNSSEC workshop the potential results of DANISH working group which I think should include the entire scope having a mutual TLSA validated TLS session from an IoT device to a server.

https://github.com/CIRALabs/CIRA-Secure-IoT-Registry/blob/master/CIRA%20-%20Challenges%20in%20DNSSEC%20IoT%20Registry%20-%20ICANN%202021-6-14.pdf

In addition, I was thinking there should be a 4th TLSA certificate usage, type 0 or 4, for TLSA to show cert that are revoked, if we know for sure the certificate is revoked then it should be presented and queried/answered as such,  an authoritative answer signed with DNSSEC to say certificate is revoked, not to be trusted anymore.  NSEC says it does not exists, this usage would be very clear. This works for client identity, not sure for other TLSA use cases.

Jacques


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, 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. Thank you.