Re: [Uta] MTA-STS-03 review
Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 26 March 2017 20:38 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 644C3128616 for <uta@ietfa.amsl.com>; Sun, 26 Mar 2017 13:38:10 -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] 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 CIXkEQ0ARuDm for <uta@ietfa.amsl.com>; Sun, 26 Mar 2017 13:38:08 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2731912773A for <uta@ietf.org>; Sun, 26 Mar 2017 13:38:08 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 158AD7A32F1 for <uta@ietf.org>; Sun, 26 Mar 2017 20:38:07 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CA+E3Fw14oF1Hy_0ogH8-+gd3p0A7bN1rUTGGiLxkfp==WB-ZYw@mail.gmail.com>
Date: Sun, 26 Mar 2017 16:38:05 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: uta@ietf.org
Message-Id: <264C672A-6AAA-42F2-A73D-2F6AE7A1AB29@dukhovni.org>
References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> <CANtKdUfOZYSr_SuGHdDHHgrF8J5VjEWwVw_7KC2xS5DrCKhu-w@mail.gmail.com> <CA+E3Fw14oF1Hy_0ogH8-+gd3p0A7bN1rUTGGiLxkfp==WB-ZYw@mail.gmail.com>
To: uta@ietf.org
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/AzhnUAxiYcpITSg2ct4cwMZobts>
Subject: Re: [Uta] MTA-STS-03 review
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 26 Mar 2017 20:38:10 -0000
> On Mar 26, 2017, at 3:56 PM, David Illsley <davidillsley@gmail.com> wrote: > >>> Here, as discussed on the list, serious consideration should be given >>> to changing the semantics from validating the MX hostname to specifying >>> the names allowed in the server's certificate. This simplifies MX processing >>> (which remains unmodified) and merely changes the conditions under which an >>> MX host is considered suitably authenticated per the policy. >>> >>> Which, for example, allows the MX hosts to share a single certificate >>> with the destination domain (and not the MX hostname) as its DNS SAN. >>> If the policy lists that (shared) name as what's expected in the certificate, >>> then authentication succeeds when the MX host's certificate matches one of >>> the allowed names. >> >> That's interesting. I think it's not actually that big a change--we just get rid of the MX host filtering and instead just apply the logic to validation. >> >> Downsides: >> >> 1. Misconfigurations _may_ be less obvious without connecting to >> the SMTP server. That is, today, you can spot some kinds of >> misconfigurations by merely looking at the DNS (so for example >> my test tool here http://sts.x.af0.net/ first looks at DNS, and >> only then tries SMTP connections). >> >> 2. As you say, it requires some changes to server certificate >> validation, but not much. >> >> I don't consider #1 compelling. So this seems fairly reasonable >> to me, but I will let others chime in. > > FWIW, I'm nervous about the idea of introducing non-standard > server cert validation. It's not that complex, but certainly > unexpected to people with experience deploying HTTPS. Well, TLS for MTA-to-MTA SMTP *is* very different from TLS for HTTPS. Reasoning by analogy with HTTPS often leads to incorrect conclusions. So, from my perspective, looking more obviously different from HTTPS is a feature. :-) > It also looks like some of the rationale is to enable reuse of > website keys/certs, No, not *reuse*, rather compatibility with pre-STS practice. Because MX records are untrusted absent DNSSEC, there is an existing practice to employ the recipient domain, rather than the MX hostname, as the DNS name in the certificate. This is one with "UCC" certificates. I'm one of the early instigators of this practice. I introduced it with Postfix "secure" TLS policy, and later recommended it to Microsoft for implementation in Exchange 2007. http://www.postfix.org/postconf.5.html#smtp_tls_security_level http://www.postfix.org/TLS_README.html#client_tls_limits https://technet.microsoft.com/en-us/library/bb266978(v=exchg.80).aspx So the idea is not "sharing", but compatibility with existing practice, as some domains may employ both STS and explicit TLS peering with business partners. The main motivation for the proposal is to get out of the way of MX host selection and constrain just certificate matching. > which while valid probably isn't desirable because of the risks of > reusing the same keys for multiple purposes/with multiple software > configurations (as was demonstrated in the DROWN paper > https://drownattack.com/ Ironic you mention DROWN: DROWN: Breaking TLS using SSLv2 Nimrod Aviram, Sebastian Schinzel, Juraj Somorovsky, Nadia Heninger, Maik Dankel, Jens Steube5, Luke Valenta, David Adrian, J. Alex Halderman, Viktor Dukhovni[7], Emilia Käsper, Shaanan Cohney, Susanne Engels, Christof Paar and Yuval Shavitt [7] Two Sigma/OpenSSL For the record, I do not recommend sharing a single certificate among multiple MX hosts, or between email and other services. In addition to DROWN, (which really helped drive SSLv2 support out of the ecosystem). The primary reason to avoid sharing certificates among MX hosts is to avoid a single point of failure. Operational errors in shared certificate/key rotation tend to break all the MX hosts at once. The operational issue dwarfs DROWN in its significance. -- Viktor.
- [Uta] MTA-STS-03 review Viktor Dukhovni
- Re: [Uta] MTA-STS-03 review Daniel Margolis
- Re: [Uta] MTA-STS-03 review Viktor Dukhovni
- Re: [Uta] MTA-STS-03 review Daniel Margolis
- Re: [Uta] MTA-STS-03 review Jeremy Harris
- Re: [Uta] MTA-STS-03 review Daniel Margolis
- Re: [Uta] MTA-STS-03 review David Illsley
- Re: [Uta] MTA-STS-03 review Viktor Dukhovni
- Re: [Uta] MTA-STS-03 review Alberto Bertogli
- Re: [Uta] MTA-STS-03 review Viktor Dukhovni
- Re: [Uta] MTA-STS-03 review Daniel Margolis
- Re: [Uta] MTA-STS-03 review Alberto Bertogli
- Re: [Uta] MTA-STS-03 review Viktor Dukhovni
- Re: [Uta] MTA-STS-03 review Daniel Margolis
- Re: [Uta] MTA-STS-03 review Viktor Dukhovni
- Re: [Uta] MTA-STS-03 review Daniel Margolis
- Re: [Uta] MTA-STS-03 review Viktor Dukhovni
- Re: [Uta] MTA-STS-03 review Daniel Margolis