IETF Logo Mail Archive

Re: [Uta] "webby" STS and DANE/DNSSEC co-existence

Neil Cook <neil.cook@noware.co.uk> Wed, 13 April 2016 08:40 UTC

Return-Path: <neil.cook@noware.co.uk>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35D212DCEA for <uta@ietfa.amsl.com>; Wed, 13 Apr 2016 01:40:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.895
X-Spam-Level:
X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996] 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 lePh7HAuUGji for <uta@ietfa.amsl.com>; Wed, 13 Apr 2016 01:40:48 -0700 (PDT)
Received: from mail.noware.co.uk (mail.noware.co.uk [192.241.243.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8222812DAE4 for <uta@ietf.org>; Wed, 13 Apr 2016 01:40:48 -0700 (PDT)
Received: from neil-cook-mbp.home (unknown [86.153.224.89]) by mail.noware.co.uk (Postfix) with ESMTPSA id AE0BA1C2A9D; Wed, 13 Apr 2016 08:40:46 +0000 (UTC)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_9E262AD2-213B-4A5D-A540-E2A7148E7F7B"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail 2.6b2
From: Neil Cook <neil.cook@noware.co.uk>
In-Reply-To: <CANtKdUf0kN5aOmX0-NsyQXz_+PRGfaXa37DFZoCX3FqdYh5CpA@mail.gmail.com>
Date: Wed, 13 Apr 2016 09:40:45 +0100
Message-Id: <5249C8ED-CACD-4765-909E-CB8EB218BF10@noware.co.uk>
References: <570C0CD2.9030401@cs.tcd.ie> <20160411212128.GA26423@mournblade.imrryr.org> <CANtKdUekXNkVvsfq0UjCiaaPVBgoVGfrfnYUrdoOf0EegXMuPg@mail.gmail.com> <20160413014304.GB26423@mournblade.imrryr.org> <CANtKdUf0kN5aOmX0-NsyQXz_+PRGfaXa37DFZoCX3FqdYh5CpA@mail.gmail.com>
To: Daniel Margolis <dmargolis@google.com>
X-Mailer: Apple Mail (2.3112)
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.1 cv=TdMYtHgh c=1 sm=1 tr=0 a=xfdXm1iLTETJF5zWIHVl8g==:117 a=xfdXm1iLTETJF5zWIHVl8g==:17 a=L9H7d07YOLsA:10:nop_no_from_header a=9cW_t1CCXrUA:10:nop_no_to_header a=s5jvgZ67dGcA:10:nop_no_subject_header a=1XWaLZrsAAAA:8 a=lyf1682xAAAA:8 a=48vgC7mUAAAA:8 a=yflVpddrNOIfUZswHnMA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=AnQPWLKY8RGxl9MyBFAA:9 a=YozZwymvE84Rr6Lu:21 a=_W_S_7VecoQA:10:nop_html a=FdW6SKLwP66qnElS_IsA:9
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/fYH1HrfclaYrd4G2pdjSAB0rX90>
Cc: uta@ietf.org
Subject: Re: [Uta] "webby" STS and DANE/DNSSEC co-existence
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2016 08:40:51 -0000

> On 13 Apr 2016, at 08:48, Daniel Margolis <dmargolis@google.com> wrote:
> 
> What's the complexity you're worried about? Is it mainly that there's another switch to flip incorrectly (i.e. inadvertent misconfiguration, at a greater risk due to the presence of more configurations) or the risk of malicious DoS?
> 

Checking both is not a good idea. DANE support scenarios like self-signed certs, which STS does not.

> I think Stephen laid out the trade-offs fairly well. I can see the argument for telling recipients that if they already publish a DANE record they're probably fine and shouldn't really need an STS policy as well. But a "must" seems less helpful to me here; senders who have some external limitation that prevents them from implementing DNSSEC then must not implement STS? I'd be worried that some larger deployments might have trouble with that.
> 

We’re only talking about what precedence to use for senders who support both, not saying that recipients must support both. If sender who supports both DANE/DNSSEC and STS encounters a TLSA record it MUST honour that, and not use STS. If a sender supporting both only sees one or the other, then it’s fine. Senders which only support one or the other are also fine.

Neil

> On Wed, Apr 13, 2016 at 3:43 AM, Viktor Dukhovni <ietf-dane@dukhovni.org <mailto:ietf-dane@dukhovni.org>> wrote:
> On Tue, Apr 12, 2016 at 06:52:31PM +0200, Daniel Margolis wrote:
> 
> > I'm not sure if I'm being stupid here, but what does it mean for STS to be
> > "trumped" by DANE (or the reverse)? Do you mean that if the recipient
> > domain/MX has both STS and DANE you will *only* validate the DANE policy?
> 
> Correct.  Trying to enforce both is too complex, and needlessly
> increases the risk of delivery problems.
> 
> > If we instead said that senders who validate STS must honor STS and senders
> > who validate DANE must honor DANE, is there a conflict?
> 
> That language is either tautological, or unreasonable, if intended
> to imply that systems capable of both must be willing to apply both
> concurrently.
> 
> > I would presume that if there is either a DANE failure or an STS failure
> > senders who validate both will treat it as a failure. Introducing a concept
> > of priority strikes me as unnecessary. What am I missing?
> 
> I have no plans to support concurrent evaluation of potentially
> conflicting policies.  DANE is more robust than STS, given a DANE
> policy I see no reason to also consider STS policy.
> 
> Of course an administrator will be able to choose which policy
> applies to a given nexthop, but not enforcement of both.
> 
> --
>         Viktor.
> 
> _______________________________________________
> Uta mailing list
> Uta@ietf.org <mailto:Uta@ietf.org>
> https://www.ietf.org/mailman/listinfo/uta <https://www.ietf.org/mailman/listinfo/uta>
> 
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta

v2.23.0 | Report a Bug | By Email