Re: [Uta] "webby" STS and DANE/DNSSEC co-existence
Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 13 April 2016 19:03 UTC
Return-Path: <ietf-dane@dukhovni.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 C1A4212D732 for <uta@ietfa.amsl.com>; Wed, 13 Apr 2016 12:03:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 ZUUrlF3JrZAO for <uta@ietfa.amsl.com>; Wed, 13 Apr 2016 12:03:47 -0700 (PDT)
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 0ABDB12D658 for <uta@ietf.org>; Wed, 13 Apr 2016 12:03:46 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E56EF284DEF; Wed, 13 Apr 2016 19:03:45 +0000 (UTC)
Date: Wed, 13 Apr 2016 19:03:45 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: uta@ietf.org
Message-ID: <20160413190345.GE26423@mournblade.imrryr.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> <5249C8ED-CACD-4765-909E-CB8EB218BF10@noware.co.uk> <CANtKdUctfEKuQAscMkt_A5wcA84Z4y3L4KvcsxVd2Qb0NRBtgw@mail.gmail.com> <96AFF4DD-A934-4C92-A72E-AF729CE053D7@noware.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <96AFF4DD-A934-4C92-A72E-AF729CE053D7@noware.co.uk>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/Oskl9FmuCck8oKfUykuYi0-o0To>
Subject: Re: [Uta] "webby" STS and DANE/DNSSEC co-existence
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: uta@ietf.org
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 19:03:49 -0000
On Wed, Apr 13, 2016 at 10:34:20AM +0100, Neil Cook wrote: > > Yes, but if you have a self-signed cert, you aren't going to have an > > STS policy, so that's a different scenario than what we're discussing, no? [ Response to up-thread comment ] If a domain publishes both DANE and STS policy indeed both need to be correct. Which to use when both are published is perhaps just local policy, but some guidance may be appropriate. In particular because opportunistic authentication (please read RFC7435, and then sections 1.3 and 3.1 of RFC7672) can be viewed a policy of receiving system that the sending system is playing along with, fragile policies are best avoided, lest senders throw in the towel and disable SMTP transport security, because it is more trouble than it is worth. Now of DANE and STS have their separate pain points: * DANE: Cert rotation can be tricky, users may need to update DNS before replacing their certs. Some will botch this from time to time. However, with "3 X X" TLSA records certificate expiration and hostname matching are not relevant, so authentication works even with "expired" certs or certs that don't match the MX hostname, or for chains that lack otherwise required intermediate CA certs. * STS: Users will forget to renew certificates, and name checks need to work, and the CA needs to be trusted by the sender. Missing intermediate certs (often not added when renewing certs) are also a frequent problem. Certificate transparency may also enter the picture at some point, and provide more ways for WebPKI authentication to fail (missing SCTs in stapled OCSP, unsupported log servers, ...). If we require *both* to work, there are just too many ways to lose. The sender typically is willing to send in the clear, and is doing TLS because *some* traffic deserves better and to thwart pervasive monitoring. Setting the bar too high is often counterproductive. So my view is that for SMTP DANE is by far the more natural of the two transport security mechanisms, and that STS is essentially a medium-term work-around for the complexity of cost-justifying DNSSEC in the face of internal organizational politics at the large providers. In that light, the more natural mechanism is used when available, and the work-around is a secondary strategy. > 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. This can't work. An MTA will present the same certificate chain to STS and DANE clients alike. -- Viktor.
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Jim Fenton
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Viktor Dukhovni
- [Uta] "webby" STS and DANE/DNSSEC co-existence Stephen Farrell
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Mark Risher
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Neil Cook
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Daniel Margolis
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Viktor Dukhovni
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Daniel Margolis
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Aaron Zauner
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Neil Cook
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Daniel Margolis
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Neil Cook
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Daniel Margolis
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Neil Cook
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Chris Newman
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Viktor Dukhovni
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Viktor Dukhovni
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Binu Ramakrishnan
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Viktor Dukhovni
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Viktor Dukhovni
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Daniel Margolis
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Aaron Zauner
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Aaron Zauner
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Jim Fenton
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Aaron Zauner
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Aaron Zauner
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Eric Rescorla
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Jim Fenton
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Chris Newman
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Jim Fenton
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Viktor Dukhovni
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Chris Newman
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence =JeffH
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Stephen Farrell
- Re: [Uta] "webby" STS and DANE/DNSSEC co-existence Leif Johansson