IETF Logo Mail Archive

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

Neil Cook <neil.cook@noware.co.uk> Wed, 13 April 2016 09:59 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 7807112DBEE for <uta@ietfa.amsl.com>; Wed, 13 Apr 2016 02:59:10 -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 k32NN5wHmxmy for <uta@ietfa.amsl.com>; Wed, 13 Apr 2016 02:59:08 -0700 (PDT)
Received: from mail.noware.co.uk (mail.noware.co.uk [192.241.243.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7AD12D582 for <uta@ietf.org>; Wed, 13 Apr 2016 02:59:08 -0700 (PDT)
Received: from neil-cook-mbp.home (unknown [86.153.224.89]) by mail.noware.co.uk (Postfix) with ESMTPSA id 130B01C2B59; Wed, 13 Apr 2016 09:59:06 +0000 (UTC)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_9E91058D-DBF9-43E3-A8D1-7D12FF5F56A3"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail 2.6b2
From: Neil Cook <neil.cook@noware.co.uk>
In-Reply-To: <CANtKdUcvhE+xxXtrRFgS0gcEE=8qLyPea5BpdLkv2DYmt9BHww@mail.gmail.com>
Date: Wed, 13 Apr 2016 10:59:06 +0100
Message-Id: <A41EBA6F-D988-491B-A436-C7D3EE2018C1@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> <5249C8ED-CACD-4765-909E-CB8EB218BF10@noware.co.uk> <CANtKdUctfEKuQAscMkt_A5wcA84Z4y3L4KvcsxVd2Qb0NRBtgw@mail.gmail.com> <96AFF4DD-A934-4C92-A72E-AF729CE053D7@noware.co.uk> <CANtKdUcvhE+xxXtrRFgS0gcEE=8qLyPea5BpdLkv2DYmt9BHww@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=D2AyyhpcAAAA:8 a=-u1ENcOADcrXOuLihYMA:9 a=SKojxcxMFLIuxdvK:21 a=F5yx9e_sw32XssCw:21 a=QEXdDO2ut3YA:10:nop_charset_2 a=U4bUSx9Sv8vJMbumdgYA:9 a=qoPlM4c5uArNB27M:21 a=Hb1Nkaq-KW3K0ujM:21 a=zqMG_dBFTKWcTdBD:21 a=_W_S_7VecoQA:10:nop_html a=o6HtvRefxuz0P7z49vEA:9
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/Si_wWJ0ZtlVrArUJaOiI5o12iIM>
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 09:59:10 -0000

> On 13 Apr 2016, at 10:38, Daniel Margolis <dmargolis@google.com> wrote:
> 
> 
> On Wed, Apr 13, 2016 at 11:34 AM, Neil Cook <neil.cook@noware.co.uk <mailto:neil.cook@noware.co.uk>> wrote:
> Well, both need to work independently as you say below. But I might still have an STS policy (using a different, CA-signed cert) where I have a self-signed cert for DANE, because I want to support clients who only support one or the other. Forcing clients to validate both doesn’t seem to be a good idea.
> 
> I don't really understand how you would do this, though. Wouldn't this necessitate having different MX records (some of which have matching TLSA records and serve self-signed certs but aren't included in the STS policy, and some of which are in the STS policy and have CA-signed certs) and counting on sending MTAs falling back to the subset of (from their perspective) valid MXs?
> 
> I'm just trying to understand the setup here a bit better.

Yeah, that would suck. I didn’t think enough about how you would make this work practically.

However this does bring up a good point - if I want to support STS *and* DANE as a receiver, and have a homogeneous MX/MTA setup, i.e. not something like the above, I would have to support the common subset of both specifications, at least as far as MTA configuration is concerned, e.g. no self-signed certs. That is a consequence we haven’t discussed before.

Neil

v2.23.0 | Report a Bug | By Email