Re: [dane] New version of tls-dnssec-chain draft (-02)

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 11 December 2015 16:50 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE241B2D0E for <dane@ietfa.amsl.com>; Fri, 11 Dec 2015 08:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 UGkytLHQcAi5 for <dane@ietfa.amsl.com>; Fri, 11 Dec 2015 08:50:57 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3EC1B2B69 for <dane@ietf.org>; Fri, 11 Dec 2015 08:50:57 -0800 (PST)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 3926B284809; Fri, 11 Dec 2015 16:50:56 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAHPuVdUkH7L5FgNnxPWNczRfN3noGp5V5zE9CYGR-u-AQr8fLw@mail.gmail.com>
Date: Fri, 11 Dec 2015 11:50:55 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <C7203B45-D8D8-46DF-8CC0-3D1EC0801747@dukhovni.org>
References: <CAHPuVdXgCHb4UfXi3smFOsQxN8nRSzd2c17xr_TOF=snSBHVJg@mail.gmail.com> <20151109045334.GU18315@mournblade.imrryr.org> <CAHPuVdU4dVYrcw93arL3_274WQDd+yUK7oCfdZEy8MiQFVTT7Q@mail.gmail.com> <20151128070913.GJ18315@mournblade.imrryr.org> <CAHPuVdUh9rW=TT-+pjLha753VTUqc3Yjgz10dK9Xapxm3wtOCg@mail.gmail.com> <23F61F03-764D-4138-9FEF-3A99820C0278@dukhovni.org> <CAHPuVdUkH7L5FgNnxPWNczRfN3noGp5V5zE9CYGR-u-AQr8fLw@mail.gmail.com>
To: Shumon Huque <shuque@gmail.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/J5vXi2TxbPmV4Wq3D5hIVgu6UbI>
Cc: "<dane@ietf.org>" <dane@ietf.org>
Subject: Re: [dane] New version of tls-dnssec-chain draft (-02)
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Dec 2015 16:50:59 -0000

> On Dec 11, 2015, at 12:10 AM, Shumon Huque <shuque@gmail.com> wrote:
> 
>> Doing incorrect validation of DNSSEC wildcards is not a good idea.
>> These are defaults, that are quite deliberately inapplicable in
>> the presence of real records.  If a user has a specific TLSA
>> record for port 443, and a different wildcard covering other ports,
>> attackers MUST NOT be able to substitute the wildcard TLSA RRset
>> for the more specific one for port 443.  Do not confuse these
>> with the X.509 wildcards.
> 
> I wasn't confusing anything, rather considering ways to avoid the presence of NSEC records in the chain, as a possible simplification. Presumably the server operator knows what records are in their zone and can judge the risks for themselves, but I know it isn't ideal. Another option, also not ideal, would be to exclude wildcard TLSA records from using this mechanism.

The server operator may not always be at liberty to ensure that the
TLSA RRset is free of wildcards.  This might apply for example in
intramural corporate deployments of services running on a multiple
and perhaps variable ports on a given host.

-- 
	Viktor.