Re: [Uta] MTA-STS-03 review
Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 03 April 2017 19:35 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 2F7121294C7 for <uta@ietfa.amsl.com>; Mon, 3 Apr 2017 12:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MARKETING_PARTNERS=0.001] autolearn=no 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 EODHvC0jW0AJ for <uta@ietfa.amsl.com>; Mon, 3 Apr 2017 12:35:32 -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 4DCDA127419 for <uta@ietf.org>; Mon, 3 Apr 2017 12:35:32 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 19DD27A330D; Mon, 3 Apr 2017 19:35:31 +0000 (UTC)
Date: Mon, 03 Apr 2017 19:35:31 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: uta@ietf.org
Message-ID: <20170403193531.GO25754@mournblade.imrryr.org>
Reply-To: uta@ietf.org
References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> <CANtKdUfOZYSr_SuGHdDHHgrF8J5VjEWwVw_7KC2xS5DrCKhu-w@mail.gmail.com> <20170326205218.GN11426@blitiri.com.ar> <92500952-2A50-4508-8686-03CDBF72485D@dukhovni.org> <CANtKdUfL+RT05KSqj5i4YeoRa=gHywNosou2VPF6acPDpRhG0g@mail.gmail.com> <20170330105556.GR11426@blitiri.com.ar>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20170330105556.GR11426@blitiri.com.ar>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/Oqetq9gXhpA2oXOEKP1el0o2glk>
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: Mon, 03 Apr 2017 19:35:34 -0000
On Thu, Mar 30, 2017 at 11:55:56AM +0100, Alberto Bertogli wrote: > > 2. It seems (and I suspect this was part of Viktor's motivation) to match > > nicely with https://tools.ietf.org/html/rfc7672#section-3.2.2, which if I > > read it correctly leaves the door open to a certificate matching the > > nexthop domain rather than the MX hostname; by requiring MX hostname > > matches in STS we would break that behavior. > > Yes, my reading from that reference is that the nexthop domain can be > used to match as well. > > > I think #2 is a pretty compelling point. > > It is definitely a point, but I'm not sure it's that compelling (sorry > Viktor!). > > There's, AFAIK, no very clear and well defined way to do certificate > matching for MTA-to-MTA TLS connections, and this RFC is a chance to fix > that. Well, the prior practice, since at least 2007 in Exchange, and 2005 in Postfix, is to match the destination domain, rather than the MX hostname (which obtained from DNS MX lookup was not secure). This is used for bilaterally coordinated "secure-channel" TLS "tunnels" between partner sites. > Differring from that, and adding complexity to how SMTP does TLS > validation based on a particular section of RFC 7672 which, as far as I > know (and please correct me if I'm wrong) is not widely deployed and > hasn't got nearly as much production exposure, seems to me to be risky, > and is IMHO not worth it. Well, RFC7672 did not create this feature from thin air. The reason it appears in RFC7672 is to support existing practice. It is true that non-opportunistic TLS was not especially common in SMTP (due to lack of scalability), but it was used. A site that has the destination domain in the certificate can support both DANE and secure-channel mandatory TLS. > Bringing SMTP certificate validation in line with how HTTPS Analogies between HTTPS and TLS for SMTP are often misleading if not outright damaging. So having differences is somewhat of a feature. > Note, in case it's not clear, that I'm not advocating for the removal of > the MX list from the policy, but to keep it as in the current draft > (i.e. use it as a filter mechanism, and then do TLS validation on the > resulting MX name). > > All this said, I don't want to drag my point along or interfere with the > normal flow of things. I much appreciate your thoughtful replies, and if > you don't find my arguments convicing, I understand :) That, unfortunately, means modifying the complex MX host selection code in the MTA, which up till now has been quite separate from TLS authentication. I would really like to avoid touching the MX processing loop, and implement TLS policy strictly in the TLS handshake layer. -- 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