Re: [Danish] [Iot-directorate] SCVP

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 16 February 2021 20:06 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 0CC943A1056 for <danish@ietfa.amsl.com>; Tue, 16 Feb 2021 12:06:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGdtWCzOXEEz for <danish@ietfa.amsl.com>; Tue, 16 Feb 2021 12:06:28 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 54FCF3A1052 for <danish@ietf.org>; Tue, 16 Feb 2021 12:06:28 -0800 (PST)
Received: from [192.168.1.177] (unknown [192.168.1.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 2E564B9AFD for <danish@ietf.org>; Tue, 16 Feb 2021 15:06:27 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <yblim6si03u.fsf@w7.hardakers.net>
Date: Tue, 16 Feb 2021 18:06:26 -0200
Content-Transfer-Encoding: 7bit
Reply-To: danish@ietf.org
Message-Id: <4DBD656B-ED85-47DB-9493-6B3CC8AC50A1@dukhovni.org>
References: <49163B0D-3952-4DE8-8915-6DC6D50F851C@vigilsec.com> <1182.1613430019@localhost> <yblim6si03u.fsf@w7.hardakers.net>
To: danish@ietf.org
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/danish/Y8UBkPTeFXkqpMzFGmcfpiruxzg>
Subject: Re: [Danish] [Iot-directorate] SCVP
X-BeenThere: danish@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Tue, 16 Feb 2021 20:06:30 -0000

> On Feb 16, 2021, at 12:00 PM, Wes Hardaker <wjhns1@hardakers.net> wrote:
> 
> I think that's a great point.  DANE is likely far less energy intensive
> than full PKI -- but you probably need data to prove it (number of CPU
> instructions needed or something for full validation via both
> certificate verification approaches)

DANE-EE(3) requires just a check of the hash of the EE cert, there's no
need for chain validation.  Validation of the associated DNS records
can be amortised by caching, but is otherwise potentially costly if
performed afresh each time.

For DANE on an energy constrained device I'd probably look for a secure
channel (DoH, DoT, or some day QUIC) to a trusted iterative resolver that
can return validated DANE records to the application without the need to
perform any validation locally.  The DANE records can then be cached and
used multiple times up to the returned TTL.  If these are DANE-EE(3) or
similar, then indeed there may be a savings in the cost of signature
verification, because there are no issuer signatures to check.

If on the other extreme DANE is used to pin a "root CA" a few levels
up the issuer stack, then DANE and PKIX are much the same, with
DANE perhaps slightly costlier because the DNS data needs to be
refreshed more often than would a locally configured root CAs.

-- 
	Viktor.