IETF Logo Mail Archive

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

Aaron Zauner <azet@azet.org> Wed, 13 April 2016 08:35 UTC

Return-Path: <azet@azet.org>
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 016EE12DE71 for <uta@ietfa.amsl.com>; Wed, 13 Apr 2016 01:35:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org
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 6Di-oL8nVbH3 for <uta@ietfa.amsl.com>; Wed, 13 Apr 2016 01:35:13 -0700 (PDT)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B54AA12DC25 for <uta@ietf.org>; Wed, 13 Apr 2016 01:35:13 -0700 (PDT)
Received: by mail-pa0-x235.google.com with SMTP id ot11so29714211pab.1 for <uta@ietf.org>; Wed, 13 Apr 2016 01:35:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=DOgY0a+d3dl3e8CYpFRLSncvJXkxpI+glgjB41Jg8zk=; b=dsYQEzhDY2+WT8kVfcfIeM3GNembVbHzLNqqlNp7yJT7QaEtl3LPb6HdcZFi6kDvKm sX7yGc8o7FdY/HIFvUgd3vwOPLLzdOIOPkZlpRgKK8qh1l5xc30chKHrWjrHLTmSYDgj O5b+ZefuTMSzvFZPGausrnTgOvUmMzeDc/e/w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=DOgY0a+d3dl3e8CYpFRLSncvJXkxpI+glgjB41Jg8zk=; b=bumxvYyzO9vRC9W7du2sVp/BaoOsg1/WRjM+oclrmRw0zQVbymYlKbvIgbTfr7kSLl MUX0P0RpYVjaHsDZhd2BTHAFuiJBsWhWDKEqndnOO5MAHU2/0OeDCe9CMPz9qovEBtM7 8ZXL+igbpKbQzyxK0jxVh9Bd4296LQVwANRVDUxkfk1ZnVp2sRTAzQi86L5s5lf/ld7i DWuifCXENuG/hj9bfevG5oQXT01zy6duMopgsqd9jiOZ4DFeCOyy1QV4D7aorvq7pqlI NyDdxOMO4z+Z5EtfkBFiJ+kjcL2C4+89PdTqvu9WW68vh1GD0lZITxD8nk6jw5MHaqr4 BXUg==
X-Gm-Message-State: AOPr4FUhfL9oXmq8r5APJ1P1pEi2d/3KTffQkwAVCzKCCt2U8TyB7dYIl1N7o5Y7qaS6uA==
X-Received: by 10.66.146.39 with SMTP id sz7mr11326966pab.76.1460536513356; Wed, 13 Apr 2016 01:35:13 -0700 (PDT)
Received: from [192.168.0.128] (node-ke.pool-180-180.dynamic.totbb.net. [180.180.2.222]) by smtp.gmail.com with ESMTPSA id q20sm49076208pfi.63.2016.04.13.01.35.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Apr 2016 01:35:11 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_66B7CB75-1A3D-43C9-8C36-FD23195DB5E4"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.6b2
From: Aaron Zauner <azet@azet.org>
In-Reply-To: <CANtKdUf0kN5aOmX0-NsyQXz_+PRGfaXa37DFZoCX3FqdYh5CpA@mail.gmail.com>
Date: Wed, 13 Apr 2016 15:35:45 +0700
Message-Id: <B77A88B5-321F-4D98-BB40-9823D6EE10A5@azet.org>
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)
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/F3AplgPqnmEw0uAjdlxUGEu-1BI>
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:35:15 -0000

Hi,

> On 13 Apr 2016, at 14: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?
> 
> 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.

I understood this as: First check for DNSSEC/DANE if there're no records available try STS. But do not do both. Which is entirely reasonable given the added complexity and attack vector. You really do not want to validate via two to three different protocols/solutions.

Aaron

v2.23.0 | Report a Bug | By Email