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

Jim Fenton <fenton@bluepopcorn.net> Mon, 27 March 2017 15:06 UTC

Return-Path: <fenton@bluepopcorn.net>
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 0E023127286 for <uta@ietfa.amsl.com>; Mon, 27 Mar 2017 08:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net
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 VVtsqFCxUmNe for <uta@ietfa.amsl.com>; Mon, 27 Mar 2017 08:05:59 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86221128854 for <uta@ietf.org>; Mon, 27 Mar 2017 08:05:59 -0700 (PDT)
Received: from dhcp-8607.meeting.ietf.org (dhcp-8607.meeting.ietf.org [31.133.134.7]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v2RF5uau002433 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <uta@ietf.org>; Mon, 27 Mar 2017 08:05:58 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1490627159; bh=CpTuYaKKc538i6RtWku4QePl7au2408AtGTHM7eNrAM=; h=Subject:To:References:From:Date:In-Reply-To; b=b8xDmjSpm/fggbiPwvUHE92aIzoh1eOJmwxIQhVnmMUkDx6mFl+ggUs9j4uxAPRiW PPchel7DLZlT3K60s80yZzfiANcesIqhwhZdph0HOmMbITQa9H4cjTCFc3c+SFrH4d cRxeHhZzSqzGVHurJM+bgvpMubT5v1b2+fw4loKM=
To: uta@ietf.org
References: <d42e535b43f14fc68b9b3e22cdff2e51@EXC01-Arezzo.diennea.lan> <BF2CE255-261C-4006-B8C9-9D9518EF258F@dukhovni.org>
From: Jim Fenton <fenton@bluepopcorn.net>
Message-ID: <909c4e01-3701-ae7a-2406-f3aa4dfeefe8@bluepopcorn.net>
Date: Mon, 27 Mar 2017 08:05:55 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <BF2CE255-261C-4006-B8C9-9D9518EF258F@dukhovni.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/xfs78__G4g2ZxNAXNyl0uq47FA4>
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:06:01 -0000

On 3/27/17 1:21 AM, Viktor Dukhovni wrote:
>> On Mar 27, 2017, at 4:08 AM, Federico Santandrea - Diennea <federico.santandrea@diennea.com> wrote:
>>
>>
>> Let's suppose the sending MTA finds the MTA-STS TXT record, which states
>> the receiving domain has an MTA-STS policy. The draft says "To discover
>> if a recipient domain implements MTA-STS, a sender need only resolve a
>> single TXT record". But what happens when the sending MTA can't fetch
>> the actual policy via HTTPS?
> Keep it simple.  It is just as easy to block access to the TXT record as
> to block access to the HTTPS site.  The TXT record is just an efficiency
> aid, so that MTAs don't have to attempt costly HTTPS connections (that
> typically time out) to domains with no STS records.
>
Actually, it's easier to block access to the TXT record, because it's
obvious in the clear that it's an MTA-STS TXT record, and an MITM that
is actively interfering with STARTTLS would likely be able to block
retrieval of the TXT record. In contrast, it's probably harder to block
the HTTPS site without potentially causing collateral damage.

The TXT record is more than an efficiency aid if clocking 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.

-Jim