IETF Logo Mail Archive

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

Jacques Latour <Jacques.Latour@cira.ca> Wed, 16 June 2021 13:32 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 39FCB3A18A0 for <danish@ietfa.amsl.com>; Wed, 16 Jun 2021 06:32:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 T5CMsUbOJ2jJ for <danish@ietfa.amsl.com>; Wed, 16 Jun 2021 06:32:40 -0700 (PDT)
Received: from nestor.zerospam.ca (nestor.zerospam.ca [209.172.38.88]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECFD3A18A4 for <danish@ietf.org>; Wed, 16 Jun 2021 06:32:40 -0700 (PDT)
X-ZEROSPAM_FILTERED: true
Received: from nestor.zerospam.ca (localhost [127.0.0.1]) by nestor.zerospam.ca (Postfix) with ESMTP id 4G4mMV5kk8z8sXk for <danish@ietf.org>; Wed, 16 Jun 2021 09:32:38 -0400 (EDT)
Authentication-Results: nestor.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 nestor.zerospam.ca (Themis) with ESMTP id zPcM5SbRF4zXveQ7Ti8; Wed, 16 Jun 2021 09:32:37 -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 nestor.zerospam.ca (Postfix) with ESMTPS id 4G4mMT4GrQz8sX7 for <danish@ietf.org>; Wed, 16 Jun 2021 09:32:37 -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; Wed, 16 Jun 2021 09:32:36 -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; Wed, 16 Jun 2021 09:32:36 -0400
From: Jacques Latour <Jacques.Latour@cira.ca>
To: "danish@ietf.org" <danish@ietf.org>
Thread-Topic: [Danish] [EXT] Re: IoT Device Identification with TLSA via Danish
Thread-Index: AQHXYe5aH02gAzTO9UCMWeYXrUdSAqsWoBHQ
Date: Wed, 16 Jun 2021 13:32:36 +0000
Message-ID: <124285d6c067429daea7a44afe6fa65a@cira.ca>
References: <02cb8931e16c4ccaa6eed1b89c0a20b6@cira.ca> <YMd3Na0Fu+Z+eqzc@straasha.imrryr.org> <90e0d38f1a394b79987b5f1517cc157e@cira.ca> <YMixtv9+ifbdqScK@straasha.imrryr.org>
In-Reply-To: <YMixtv9+ifbdqScK@straasha.imrryr.org>
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-16T13:32:35Z; 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=2ff3c675-648e-4a92-a9a5-7599973b5d29; MSIP_Label_ee0e450f-d653-41c9-9b6c-2295bb19e3b2_ContentBits=2
x-originating-ip: [10.2.36.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/danish/PhLOYujZb92Kqm6wIfizhr9HGpY>
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: Wed, 16 Jun 2021 13:32:43 -0000

Viktor,

> Adding revocation records breaks the semantics.  

I'm with you here.

>And, as I pointed out, the revocation record is redundant.  Just publish "3 1 0" or
> "3 1 1" and you've renounced *all* other keys, by specifying only the valid key(s).

Two scenarios, first, if the IoT device has a new identity then we publish a new TLSA - done, old key are to be untrusted. This works. All good.

Second scenario for IoT device that can have their identity reprovisioned, if an IoT device is compromised/not to be trusted/not to be used for whatever reasons, a NSEC record does not represent that status, but could we put a 0 (?)  value 4th TLSA Certificate Association Data field, the presence of the TLSA would show it exists, the null cert value would show don't use, but it exists, so the logic on the server could be different to figure out what do to with that IoT device, instead of a nonexistence record.

Jack


CLASSIFICATION:CONFIDENTIAL

v2.23.0 | Report a Bug | By Email