Re: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-19.txt

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 02 May 2018 18:04 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 4F56E12D963 for <uta@ietfa.amsl.com>; Wed, 2 May 2018 11:04:41 -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 L8bVRvH0RRXJ for <uta@ietfa.amsl.com>; Wed, 2 May 2018 11:04:38 -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 BFF8A12D960 for <uta@ietf.org>; Wed, 2 May 2018 11:04:38 -0700 (PDT)
Received: from [10.200.0.109] (unknown [8.2.105.17]) (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 6E1707A3309 for <uta@ietf.org>; Wed, 2 May 2018 18:04:37 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <152528006604.11163.2648195212177840063@ietfa.amsl.com>
Date: Wed, 02 May 2018 14:04:35 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: uta@ietf.org
Message-Id: <CA6FBD95-7F28-4567-90DA-02E7743E6478@dukhovni.org>
References: <152528006604.11163.2648195212177840063@ietfa.amsl.com>
To: uta@ietf.org
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/R6CPf0plV2iSUtnV-SNUIph95Vs>
Subject: Re: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-19.txt
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: Wed, 02 May 2018 18:04:41 -0000


> On May 2, 2018, at 12:54 PM, internet-drafts@ietf.org wrote:
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-tlsrpt-19

Two observations triggered by reading the diff:

1.1 Terminology:

The definition of MTA-STS describes the MTA promising STARTTLS,
specifying the valid presented identities, ..., but the DANE
definition just mentions "constraints", which is neither comparably
complete nor correct:


OLD: [compare with MTA-STS policy]

   o  DANE Policy: A mechanism by which administrators can specify
      constraints to be used to validate certificates presented by an
      MTA.  DANE is defined in [RFC6698] and [RFC7672].

NEW:

   o  DANE Policy: A mechanism by which administrators can use DNSSEC
      to commit an MTA to support STARTTLS and to publish criteria to
      be used to validate its presented certificates.  DANE for SMTP
      is defined in [RFC7672], with the base specification in [RFC6698]
      (updated in [RFC7671].

The definition of "Policy Domain" is not complete, it is *not* always
the envelope recipient domain.  Indeed for MTA-STS it may be a "smarthost"
gateway en-route to the destination domain.  And for DANE the policy
domain is the "TLSA base domain" associated with the remote SMTP server.
Typically this is the hostname of the receiving SMTP server, or its
full CNAME expansion as described in RFC7672.


OLD:

   o  Policy Domain: The domain against which an MTA-STS or DANE Policy
      is defined.  This should be the same as the recipient envelope
      domain [RFC5321], such as if the message were going to
      "alice@example.com', the policy domain would be "example.com".

NEW:

   o  Policy Domain: The domain against which an MTA-STS or DANE Policy
      is defined.  For MTA-STS this is typically the same as the envelope
      recipient domain [RFC5321], but when mail is routed to a "smarthost"
      gateway by local policy, the "smarthost" domain name is used instead.
      For DANE the Policy Domain is the "TLSA base domain" of the receiving
      SMTP server as described in [RFC7672] (Section 2.2.3) and [RFC6698]
      (Section 3).

The text in Section does not make it clear to what name the prefix "_smtp._tls"
should be prepended.  I think this would be the "Policy Domain" above.  This
should be explicit.  With DANE since policy is per-MX-host and different
parties may operate different MX hosts, it is natural to align the reporting
address with the operator's domain (by looking under the TLSA base domain
for both "_25._tcp" TLSA records and "_smtp._tls" report policy).

-- 
	Viktor.