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
- [Uta] Comments on draft-ietf-uta-mta-sts-03 Federico Santandrea - Diennea
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Viktor Dukhovni
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Daniel Margolis
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Jim Fenton
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Viktor Dukhovni
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Daniel Margolis
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Federico Santandrea
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Federico Santandrea
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Daniel Margolis
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Daniel Margolis
- Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 Viktor Dukhovni