Re: [Uta] Ben Campbell's Yes on draft-ietf-uta-smtp-tlsrpt-18: (with COMMENT)

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 19 April 2018 14:41 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 DCFEF12741D; Thu, 19 Apr 2018 07:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 P68B4apAOn-K; Thu, 19 Apr 2018 07:41:52 -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 CD687126DFF; Thu, 19 Apr 2018 07:41:51 -0700 (PDT)
Received: from [192.168.1.161] (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 8872D7A3309; Thu, 19 Apr 2018 14:41:50 +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: <152413052909.28772.14702521603800222616.idtracker@ietfa.amsl.com>
Date: Thu, 19 Apr 2018 10:41:49 -0400
Cc: The IESG <iesg@ietf.org>, uta@ietf.org, uta-chairs@ietf.org, draft-ietf-uta-smtp-tlsrpt@ietf.org, valery@smyslov.net, Leif Johansson <leifj@sunet.se>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6CDB413D-9269-494B-870E-3E7F3D1EC29F@dukhovni.org>
References: <152413052909.28772.14702521603800222616.idtracker@ietfa.amsl.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/_TgTni5d2kAMgvARddGoRVIwY78>
Subject: Re: [Uta] Ben Campbell's Yes on draft-ietf-uta-smtp-tlsrpt-18: (with 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: Thu, 19 Apr 2018 14:41:54 -0000


> On Apr 19, 2018, at 5:35 AM, Ben Campbell <ben@nostrum.com> wrote:
> 
> §1.1, Policy Domain: The definition is partially circular. Please define what
> is meant by "domain". I assume that means domain in the DNS sense, but the word
> "domain" is commonly uses in other senses as well. Please be explicit.

Thanks, this is a good catch!  The policy domain does need a clear definition.

While it is the domain for which either a DANE or STS policy mandates secure
TLS delivery, and will be a DNS domain, a more precise definition is probably
helpful. 

In the case of STS it is usually the envelope recipient domain, but
may be the domain name of an explicitly configured "next-hop" gateway for email
delivery to the envelope recipient.

In the case of DANE, security policy is specified for each "MX Host'
separately, with the TLSA records obtained via the "TLSA base domain"
for that host.  And yet, it is *perhaps* not the intention here to
publish the reporting address separately for each MX host.  It is
more "economical" to publish it just once for the envelope recipient
domain or override next-domain just as with STS.

On the other hand, when email is hosted by a third-party,
obtaining the reporting address for the MX host is more
likely to get the report to the responsible party.

With either DANE or STS the most likely reason for policy
failure is operator error, and so there's some appeal to
notifying the the MX host provider (if "_smtp-tlsrpt.<mx-host>"
is found).  Perhaps with the envelope recipient domain or
locally configured next-hop domain as a fallback policy domain.

If, however, the failure results from a botched MiTM, with the
MX RRset modified by the attacker, then one would perhaps want
to notify the (email) destination domain, not the operators of
the fake MX host.  With DANE, the MX RRset is more likely to
be DNSSEC-validated, and so tamper-evident, but DANE may also
be apply to the DNSSEC-signed MX hosts of an "insecure" (unsigned)
domain.

Thus, I must admit to have overlooked some of the subtlety
involved in figuring out which "example.com" is the right
input to "_smtp-tlsrpt.example.com".  Don't know whether
the authors have thought this through more thoroughly.

It is likely that the present intent is to use the same
location for both DANE and STS, and for that to be
the envelope recipient domain or configured next-hop
if set, but I'd guess that use of the MX host domain as
a primary (or fallback) base for the "_smtp-tlsrpt" lookup
likely has not been considered.

-- 
	Viktor.