Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-mta-sts-17: (with DISCUSS and COMMENT)
Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 07 May 2018 15:14 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 61ADD124B0A; Mon, 7 May 2018 08:14:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 kWn4RxKj9y-r; Mon, 7 May 2018 08:14:16 -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 CE6DF1201F2; Mon, 7 May 2018 08:14:15 -0700 (PDT)
Received: from [192.168.1.162] (straasha.imrryr.org [100.2.39.101]) (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 BC76F7A3309; Mon, 7 May 2018 15:14:14 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CA+S86mVYXJceY-0ZGMFPHOTgzaad81EupDxjW6iMOrScSJRidQ@mail.gmail.com>
Date: Mon, 07 May 2018 11:14:13 -0400
Cc: draft-ietf-uta-mta-sts@ietf.org, The IESG <iesg@ietf.org>, Leif Johansson <leifj@sunet.se>, uta-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <EB9C58FD-A34A-4BBE-A8B7-AF3E08E72A1C@dukhovni.org>
References: <152539648489.11713.7895583526344282774.idtracker@ietfa.amsl.com> <CANtKdUeK_HpOYsP-CfhF7m7-DYiSX39xTMLxqZw-1UQsn29xyQ@mail.gmail.com> <78C81C6B-1C5F-4361-A3B7-40D9012E406A@dukhovni.org> <CA+S86mWSNwzG0_y_d=yg8Nqf9gxFud+8TAYWHY3Uw6aqn_JKog@mail.gmail.com> <C5B103C6-4A18-4013-95DB-70C2C180871C@dukhovni.org> <969F2F35-BA59-403B-81EE-44AF57FA6BB0@dukhovni.org> <CA+S86mVYXJceY-0ZGMFPHOTgzaad81EupDxjW6iMOrScSJRidQ@mail.gmail.com>
To: uta@ietf.org
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/ue76_l8pCqpUWScnoa3U5pULTPs>
Subject: Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-mta-sts-17: (with DISCUSS and COMMENT)
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, 07 May 2018 15:14:18 -0000
> On May 7, 2018, at 4:15 AM, Daniel Margolis <dan@af0.net> wrote: > > Yes, that was exactly my point. That's why I was saying this is really an implementation detail (albeit one you'd want to call out); the only fundamental protocol question at issue is whether we should consider valid a policy that matches only the cert but not the hostname itself. Yes, it boils down to whether we're willing to support MX hosts with certificates that match something other than the MX host name as seen in the MX RRset. Operational practices would have to change to require the exact MX hostname. For example: tac-coburg.com. IN MX 10 mx-fhco-smart.rrze.uni-erlangen.de. mx-fhco-smart.rrze.uni-erlangen.de[131.188.11.23] name = mx-fhco-1.rrze.uni-erlangen.de name = mx-fhco-2.rrze.uni-erlangen.de name = mx-fhco-3.rrze.uni-erlangen.de name = mx-rz-1.rrze.uni-erlangen.de name = mx-rz-2.rrze.uni-erlangen.de name = mx-rz-3.rrze.uni-erlangen.de name = mx-rz.rrze.uni-erlangen.de name = mx-sub-1.rrze.uni-erlangen.de name = mx-sub-2.rrze.uni-erlangen.de name = mx-sub-3.rrze.uni-erlangen.de name = mx-uker-1.rrze.uni-erlangen.de name = mx-uker-2.rrze.uni-erlangen.de name = mx-uker-3.rrze.uni-erlangen.de depth = 0 Issuer CommonName = FAU-CA Issuer Organization = Universitaet Erlangen-Nuernberg notBefore = 2014-09-29T10:16:00Z notAfter = 2019-07-09T23:59:00Z Subject CommonName = mx-rz.rrze.uni-erlangen.de Subject Organization = Universitaet Erlangen-Nuernberg Out of 4238 MX hosts with working DANE TLSA records, 233 have certificates in which none of the names match the MX hostname. They could of course change their practices or not adopt MTA-STS, but they seem to have their reasons for the names used and can be unwilling to change. One Russian user whom I tried to convince to avoid aliases in the MX record quoted Lenin (to suggest that my perspective fails to take his circumstances into account): "Узок круг этих революционеров. Страшно далеки они от народа" Which translates roughly as "Narrow is the circle of these revolutionaries. They are too far removed from the people". :-) > * In "testing" mode one would still actually connect even to MX hosts > whose names don't match the cached policy. If the draft is updated to change the matching rules, this issue would need to be addressed, what should be the treatment of non-matching MX hostnames in "testing" mode? > * In "enforce" mode, one could at the last moment optimize-out connections > to hosts which are sure to fail authentication, because the MX hostname > does not match the "mx" list. This of course after loop eiimination, etc. Here, there's a very small, but non-zero risk of running into dynamic firewall rules by skipping a better priority MX host. Some domains have backup MX hosts whose primary purpose is to detect out-of-order connections from botnets and the like, and access to the primary is blocked when a client connects to the secondary first. The domain would of course need to be misconfigured to not list the primary in the MTA-STS policy. If we ever do a spec for in-band reporting of authentication failure, that would be another reason to make the connection anyway, and just signal that the MX host is failing to match policy, before moving on to the next MX host (or deferring the message). -- Viktor.
- [Uta] Eric Rescorla's Discuss on draft-ietf-uta-m… Eric Rescorla
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Eric Rescorla
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Alberto Bertogli
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Eric Rescorla
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Daniel Margolis
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Daniel Margolis
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Daniel Margolis
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Daniel Margolis
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Daniel Margolis
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Leif Johansson
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Leif Johansson
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Leif Johansson
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Daniel Margolis
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Alberto Bertogli
- Re: [Uta] Eric Rescorla's Discuss on draft-ietf-u… Daniel Margolis