Re: [Uta] Uta Digest, Vol 28, Issue 16
Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 24 March 2016 16:53 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 C7A9E12D5A5 for <uta@ietfa.amsl.com>; Thu, 24 Mar 2016 09:53:18 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 iqrJ5fwhWOkf for <uta@ietfa.amsl.com>; Thu, 24 Mar 2016 09:53:17 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFAC12D194 for <uta@ietf.org>; Thu, 24 Mar 2016 09:53:16 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id CA932282F4E for <uta@ietf.org>; Thu, 24 Mar 2016 16:53:15 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <mailman.354.1458836179.3382.uta@ietf.org>
Date: Thu, 24 Mar 2016 12:53:12 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <5B12C084-3EB4-4789-A12D-29B04C157AB8@dukhovni.org>
References: <mailman.354.1458836179.3382.uta@ietf.org>
To: uta@ietf.org
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/ohVHrsnMyrkkqnG-xaxDziRBLBg>
Subject: Re: [Uta] Uta Digest, Vol 28, Issue 16
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: uta@ietf.org
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, 24 Mar 2016 16:53:19 -0000
> On Mar 24, 2016, at 12:16 PM, uta-request@ietf.org wrote: > > In addition to the possible difficulty in migrating a domain off > a server (particularly in a multi-tenant config), we also felt > that introducing a new SMTP verb might be dramatically more complicated > than deploying in parallel, because at least the DNS/webpki reporting > can be added offline without changes to the core MTA. > > Was that not a concern in DEEP? Or simply unavoidable? Implementing a new SMTP verb is easier than parsing new DNS records or adding an HTTPS stack to a sending MTA. That said, an out-of-band protocol might possibly be supported via a mostly "generic" policy lookup interface that allows the sending MTA to fetch TLS policy for a delivery and report results, while in-band signalling might require somewhat more mechanism-specific code in the MTA. The key difficulty is of course doing policy revocation in-band, it is not obvious how to do that. If STS is defined more narrowly as a protocol for sending mail to just the domains "too large to implement DNSSEC" (such as those of the draft's authors), then the hosting issue goes away, and in-band signalling works. If STS is to cater to smaller hosted domains, then signalling that securely signalling that SMTP to one's domain is no longer secure becomes difficult without a parallel out of band secure channel. If STS-enabled SMTP servers were required to be able to disavow support for a no-longer hosted domain in-band via SMTP, that might work. The client would have to signal the domain to which it wants to deliver email before "MAIL FROM", and the server would respond with the policy for that domain, or an invalidation. This would mean that the cached data for a domain would include the most recently seen MX hosts (not just the wildcard patterns), and that when new MX hosts in DNS don't match any of the cached patterns, a connection is made the cached ones for the purpose of a policy revocation check. This sounds a bit tricky... Will the "losing" provider have proper incentives to make the appropriate configuration changes in a timely manner? -- Viktor.
- Re: [Uta] Uta Digest, Vol 28, Issue 16 Viktor Dukhovni
- Re: [Uta] Uta Digest, Vol 28, Issue 16 Daniel Margolis
- Re: [Uta] Uta Digest, Vol 28, Issue 16 Orit Levin (CELA)
- Re: [Uta] Uta Digest, Vol 28, Issue 16 Viktor Dukhovni
- Re: [Uta] Uta Digest, Vol 28, Issue 16 Neil Cook