IETF Logo Mail Archive

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 30 October 2017 16:10 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695B76644 for <dns-privacy@ietfa.amsl.com>; Mon, 30 Oct 2017 09:10:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 YeMibDgLCoYq for <dns-privacy@ietfa.amsl.com>; Mon, 30 Oct 2017 09:10:50 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFD04E09 for <dns-privacy@ietf.org>; Mon, 30 Oct 2017 08:59:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4BACEBE4C; Mon, 30 Oct 2017 15:59:24 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYcsF48aUrVx; Mon, 30 Oct 2017 15:59:23 +0000 (GMT)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D17F5BE47; Mon, 30 Oct 2017 15:59:22 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1509379163; bh=AkoxNt8LZ7502M+yHM6LkKHkgh4RXFNaX4VIG+P5uzQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=xMhwUdvKI02gSZ8FbUCiQWcWQpSSCB2CLygF48Km9KjlPAamAaqJMI0OEy9dsJ9jS 7Nho0hPT4p0UD859K8ftyJnIpZwZjFPZZNchKN5Yg2GdMEZEn7BkIpdnY9KDfumvFm 3m9ScAsIdyFbGoVC3tXLi0qovv+u6Y4cify9Co1s=
To: Paul Hoffman <paul.hoffman@vpnc.org>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: dns-privacy@ietf.org
References: <878tfwey8w.fsf@fifthhorseman.net> <73F186C6-1F35-40B0-8C36-D4F011D11344@sinodun.com> <871slkd66k.fsf@fifthhorseman.net> <1B2537D5-DFD7-407A-A84E-925C85EF9268@vpnc.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <ac8f15bf-73fb-6728-e846-293c4da5bfaa@cs.tcd.ie>
Date: Mon, 30 Oct 2017 15:59:21 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <1B2537D5-DFD7-407A-A84E-925C85EF9268@vpnc.org>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="1kJlNxjM4EchkoFWefegtM4pkf2X9kRW0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/iAwNlwWRIS2d1V6A6x6nVB43v-Q>
Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Oct 2017 16:10:53 -0000

Hiya,

On 30/10/17 15:42, Paul Hoffman wrote:
> Having this document say, in essence, "you don't get opportunistic
> encryption unless you add a DNSSEC validation stack" feels like a
> regression to the original goals of this WG.

I'm not sure that having a stack is such a barrier in reality.
Requiring that some DNSSEC signatures validate in order to win
the opportunistic game is the problem I think.

I'd personally be fine with a "MUST try DNSSEC" statement, though
that could be argued to be OTT, given the probability of success,
but as DKG and you (and I) agree, it's the failure mode that needs
fixing in the draft.

S.

v2.23.0 | Report a Bug | By Email