IETF Logo Mail Archive

Re: [Uta] Comments on draft-ietf-uta-mta-sts-03

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 27 March 2017 15:17 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 8A73D1297BE for <uta@ietfa.amsl.com>; Mon, 27 Mar 2017 08:17:44 -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, 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 yB7up2MBjfL4 for <uta@ietfa.amsl.com>; Mon, 27 Mar 2017 08:17: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 7AFC21297AB for <uta@ietf.org>; Mon, 27 Mar 2017 08:17:34 -0700 (PDT)
Received: from [172.31.30.48] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (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 9CE607A32F1 for <uta@ietf.org>; Mon, 27 Mar 2017 15:17:33 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <909c4e01-3701-ae7a-2406-f3aa4dfeefe8@bluepopcorn.net>
Date: Mon, 27 Mar 2017 11:17:32 -0400
Content-Transfer-Encoding: 7bit
Reply-To: uta@ietf.org
Message-Id: <FA3784DC-3BA0-452D-9AB2-8FF7D7AB5AC8@dukhovni.org>
References: <d42e535b43f14fc68b9b3e22cdff2e51@EXC01-Arezzo.diennea.lan> <BF2CE255-261C-4006-B8C9-9D9518EF258F@dukhovni.org> <909c4e01-3701-ae7a-2406-f3aa4dfeefe8@bluepopcorn.net>
To: uta@ietf.org
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/gDu7N-uVKZtlArcXYgdyfoeDdYs>
Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03
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, 27 Mar 2017 15:17:45 -0000

> On Mar 27, 2017, at 11:05 AM, Jim Fenton <fenton@bluepopcorn.net> wrote:
> 
> The TXT record is more than an efficiency aid if cloaking it causes the
> policy not to be discovered at all. OTOH, if it is used just to discover
> policy updates, we wouldn't have that problem. But that would increase
> the traffic load on the HTTPS server considerably.

The phrase "the HTTPS server" hides an important assumption, namely
that there is an HTTPS server in the first place.  For the majority
of domains there will (for some time) be no STS policies, and no
secure way to discover whether there should be a server or not.

Publishing an STS policy is not a requirement for SMTP, so STS
discovery is opportunistic, and for lack of DNSSEC vulnerable
to downgrades.

The cacheable TXT record is an efficient mechanism for signalling
when to try to load a (new?) policy.

If we did not want to signal expedited updates by changing the id,
the signal could be just the existence of an A record for some
"reserved" hostname in the domain, but that also runs into the issue
that reserved hostnames are not a good idea or popular at the IETF.

-- 
-- 
	Viktor.

v2.23.0 | Report a Bug | By Email