Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

"John Levine" <johnl@taugh.com> Wed, 17 October 2018 01:07 UTC

Return-Path: <johnl@iecc.com>
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 536D6130E6D for <tls@ietfa.amsl.com>; Tue, 16 Oct 2018 18:07:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.751
X-Spam-Level:
X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=hfCk+MQW; dkim=pass (1536-bit key) header.d=taugh.com header.b=IJsaimnv
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 fbXFjT_c6-oq for <tls@ietfa.amsl.com>; Tue, 16 Oct 2018 18:07:22 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 39242130DC5 for <tls@ietf.org>; Tue, 16 Oct 2018 18:07:22 -0700 (PDT)
Received: (qmail 9117 invoked from network); 17 Oct 2018 01:07:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2396.5bc68b48.k1810; bh=tzVaOMQ1SPuYEnQa+Z56wrEq/+ScXKSFrx1IiV62JKQ=; b=hfCk+MQWRY/T+vqng3WjK/FLr917v6pqRzvC3d6fcQDykpL8cu8rv1KiH9QInXfbSNat+kdgTvMyVWOXAcTEYNtmaYsi6NDHCaCurQtS4XHGeTllNnD+6m8W3DP5uwAs81YJHhQXfull5ECr8O87oxx224mRgF21PY7Mwdg166migfcD/CTQNeYwAsEbugzt74kkCie6DzleMGeaK5INpomBsarF4xSxSKpRa7vcaeBEEgAMWyYk4CB7Osnz2sAi
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2396.5bc68b48.k1810; bh=tzVaOMQ1SPuYEnQa+Z56wrEq/+ScXKSFrx1IiV62JKQ=; b=IJsaimnvFt6qANWlntcpuAY4LSRQTwCWA32/kWGzDCcb9J5mvjlTpbunn1s3dN1adHBDptzYi/kCdQhbb0NbRogJA0TW9Bbz+/B/r5S3BHFFhbOxcT4cKXF/O9VNs18Af0wVyMNnbrR/U1TTth+v6PzOEE8SZz2XW218xILp2+TxV0nl3zd7rp/fYE6mU76LJGIoQNUer0/X39BB+C+9qWRXJJP6iZPUk48zhKAZjTA5hxC/HNRMGh/cnuj7MsnV
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 17 Oct 2018 01:07:20 -0000
Received: by ary.qy (Postfix, from userid 501) id 3C81D2006F8412; Tue, 16 Oct 2018 21:07:19 -0400 (EDT)
Date: Tue, 16 Oct 2018 21:07:19 -0400
Message-Id: <20181017010720.3C81D2006F8412@ary.qy>
From: John Levine <johnl@taugh.com>
To: tls@ietf.org
In-Reply-To: <875zy1czbd.fsf@fifthhorseman.net>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_NXRI1AEJchPLTHJkNxpeirFTK4>
Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 17 Oct 2018 01:07:24 -0000

Hi from DNS land.

>pinning, but i won't go too far into the weeds here.  Just a quick
>summary of my understanding:
>
> * The existence of a pin only requires that the service operator
>   maintain the ability to respond to this extension in the future -- it
>   doesn't require specific keys, or even the use of DANE itself.  It is
>   not nearly as large a risk as HPKP's pins were.
>
> * Pinning fears are based on two scenarios: (a) footgun, where the
>   service operator makes a mistake, or (b) a malicious pin is set by an
>   adversary who has owned your domain.  (a) is overwhelmingly more
>   common, and is what we should focus on.  In the (a) scenario, the
>   admin has already deployed the extension, so there is no risk.  The
>   (b) scenario only matters if a service cannot deploy the extension as
>   intended, which is more of a chicken/egg problem of deployment and
>   implementation.  I don't think that's a huge risk but if we really
>   want to try to cover it, i think there are ways that we could
>   minimize it as well.

Something like "require DANE certs until time N" should be plenty.

Remember that you can also unpin by publishing a signed NXDOMAIN or
NODATA.  Since you need to have DNSSEC working to get the pin in the
first place, that doesn't seem unduly onerous.

If your system goes totally kerflooie and your DNS was signed
yesterday and for some reason you can't sign it today, you have a
problem, but that doesn't sound like a very likely problem.  It it
does happen, it's as likely as not an attack in which case you'd want
attempts to unpin to fail.

R's,
John