Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 19 April 2018 03:34 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12DD120713 for <tls@ietfa.amsl.com>; Wed, 18 Apr 2018 20:34:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 T1ERhIVJKTAn for <tls@ietfa.amsl.com>; Wed, 18 Apr 2018 20:34:18 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E5B127369 for <tls@ietf.org>; Wed, 18 Apr 2018 20:34:17 -0700 (PDT)
Received: from [192.168.1.161] (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 mournblade.imrryr.org (Postfix) with ESMTPSA id 068EA7A3309 for <tls@ietf.org>; Thu, 19 Apr 2018 03:34:17 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <1524108318840.45277@cs.auckland.ac.nz>
Date: Wed, 18 Apr 2018 23:34:14 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <C03B033D-34E5-4CDF-9BC8-BAD7B7A2DBF3@dukhovni.org>
References: <CAOgPGoAhzEtxpW5mzmkf2kv3AcugNy0dAzhvpaqrTSuMSqWqfw@mail.gmail.com> <CAOgPGoCbHzuAZra5+i647gtLbR9ZV0-nEE+A7K6e8cUMNjNYtA@mail.gmail.com> <alpine.LRH.2.21.1804181640480.29344@bofh.nohats.ca> <CAL02cgSQbvyXuekd7x_g0DHcxYmfsydKXGDs6EQwuX5ScPYucQ@mail.gmail.com> <81405A7A-B7DC-45B1-8F7C-B96D3FD121AE@dukhovni.org> <CAL02cgQAA6ktnkPwaCKsrzi9tYrs3ELcW6KG=UfM43iO5smdEA@mail.gmail.com> <BBFCA54E-3059-48A8-AB5C-60F1BACA3F3A@dukhovni.org> <CAL02cgRNeX93g0VhSrdAs8bX5nxC9HxyK_9n-wKzZQo=pynNhw@mail.gmail.com> <20180418210615.GF25259@localhost> <1524108318840.45277@cs.auckland.ac.nz>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/413pugU37mp3R-vt_wdIpG4HjPE>
Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Apr 2018 03:34:20 -0000


> On Apr 18, 2018, at 11:25 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> 
>> That's just silly.  Really, 7.5 years (relative, not absolute) measured in
>> hours is plenty good enough, and more than outlives current device
>> obsolescence.  This isn't subject to Moore's law or anything like it.
> 
> I don't know what devices you work with, but for the ones where my code is
> used ten years is the baseline life expectancy, going out to 15-20 years for
> longer-life ones (I still have to deal with SSH bugs from the late 1990s,
> because the lifetime of the equipment that's used in is 20 years and counting.
> I think I've finally managed to get away from having to do SSLv3 within the
> last year or two).
> 
> OTOH I doubt any of these devices will do pinning, they just bake in the certs
> at manufacture/provisioning, so I'm fine with any kind of lifetime.  Just
> wanted to point out, yet again, that the entire world doesn't live in a "we
> can patch the entire deployed base in 24 hours" situation.

Indeed, but if pinning were desired, all the device would have to do is call the mother ship at least twice per decade, it can then work for multiple decades.

I agree for many devices that don't wander the web in search of the latest cute kitten photos, and just "call home", a single fixed cert is a more plausible security model than either WebPKI or DANE.

-- 
	Viktor.