From nobody Tue Aug 1 02:10:28 2017 Return-Path: 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 B83C9132C79 for ; Tue, 1 Aug 2017 02:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 ER-7jkO5mlhM for ; Tue, 1 Aug 2017 02:10:26 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 7B920132C64 for ; Tue, 1 Aug 2017 02:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1501578625; d=isode.com; s=june2016; i=@isode.com; bh=zOjOuh7Sxz7VbP3yIh4RhALEDEa2w5AU9peLPehp4jU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=h/XqjvQcQd67zyjh8v47AN2pizry+Edl3AmmCO1o3cyJrZqVEbPODYS77jcZjVebUzivlW W7iCwjqGjxQFL8PEBI0Qkv9DUdLSjAK8im59bYJtMoeyYUc/oKnpl/4UiwbtkoglDEwRHh ncj4SuiLMsIH3aB6f8AUsJar5UcV9JM=; Received: from [192.168.0.6] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 1 Aug 2017 10:10:25 +0100 From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> Date: Tue, 1 Aug 2017 10:11:25 +0100 Cc: uta@ietf.org Message-Id: <24B2EFA1-457B-4C4D-8AFF-7B42D89F48D4@isode.com> References: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> To: Jim Fenton MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 09:10:28 -0000 Jim, I would like to disagree: > On 1 Aug 2017, at 00:02, Jim Fenton wrote: >=20 > Section 5.3, I don't think it's a good idea to define and require new > message header fields for this. This means that some of the > general-purpose libraries for sending email messages can't be used. Do you mean that a general purpose library is unable to add arbitrary header= fields? This doesn't seem to qualify as "general purpose". > A better approach IMO would be to suggest the use of separate email > addresses (e.g., reports@example.org or reports+client1@example.org for > a service provider) in order to distinguish reports from other traffic. This is already possible. Best Regards, Alexey From nobody Tue Aug 1 02:11:54 2017 Return-Path: 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 A3B6F132C1E for ; Tue, 1 Aug 2017 02:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 Gf3m29w8sJaQ for ; Tue, 1 Aug 2017 02:11:51 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 25641132C72 for ; Tue, 1 Aug 2017 02:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1501578710; d=isode.com; s=june2016; i=@isode.com; bh=1MO4CTk4V4rhUxVpnuymUk8/0Vze/3ifb+0dRAQllvE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=wDRDgxOj83+qFsddWoeQ/UDtaueB78xiQvHPrFyTNmXuo0HQh0984kRje1UpJInVxnp2j3 FRykn9V+t3H75lY29DZKh9DGsEjRQ074gJ/4p+5NQMkcz07KCy4/B8QfVqIJMoJrQKmlCB WTl7TcfHMJtZWo0nHFp6YvFS5PAMPRs=; Received: from [192.168.0.6] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 1 Aug 2017 10:11:50 +0100 From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> Date: Tue, 1 Aug 2017 10:12:50 +0100 Cc: uta@ietf.org Message-Id: References: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> To: Jim Fenton MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 09:11:53 -0000 > On 1 Aug 2017, at 00:02, Jim Fenton wrote: > > As the document notes, the reference for MTA-STS needs to be added. If > it is a normative reference, this document will be held up until that is > published. I think it is Informative. From nobody Tue Aug 1 02:13:10 2017 Return-Path: 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 7B361132C7F for ; Tue, 1 Aug 2017 02:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 KsDqb2RylDoV for ; Tue, 1 Aug 2017 02:13:07 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 971EF132C7B for ; Tue, 1 Aug 2017 02:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1501578786; d=isode.com; s=june2016; i=@isode.com; bh=aX+7/C2jVI5ohyrNIByy7N4aNOysa/zqUja8937GgM0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=NLLZ8E06G4RRWakZlsno9ALb542i25S9LAUBZHghG2AVlYepOkLGCXr3l3h5ncMV9R8jcN ELOKhaBsWmcbqqLWVAIBmFlpc0Y7sIutmr912UXAgLmUeYWTunpHlClcf69xRYI0zZgAQL VFPixLu9ZrSJI9e4YEbi5stXv/LdDY0=; Received: from [192.168.0.6] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 1 Aug 2017 10:13:06 +0100 From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> Date: Tue, 1 Aug 2017 10:14:06 +0100 Cc: uta@ietf.org Message-Id: <88E227F7-E6BB-4946-A265-787C96BDA5EC@isode.com> References: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> To: Jim Fenton MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 09:13:08 -0000 > On 1 Aug 2017, at 00:02, Jim Fenton wrote: > > Section 7, additional consideration: The "untrusted content" > consideration talks about malicious code, but attackers could also send > counterfeit reports that look real in an effort to confuse the report > recipient. Should valid DKIM signatures from the reporting domain be > required on TLSRPT messages? +1 From nobody Tue Aug 1 11:21:38 2017 Return-Path: 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 057EE1321E7 for ; Tue, 1 Aug 2017 11:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Wyrhk0oalR18 for ; Tue, 1 Aug 2017 11:21:34 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96ABD131C3C for ; Tue, 1 Aug 2017 11:21:34 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id g13so11386793ioj.5 for ; Tue, 01 Aug 2017 11:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ImfH1DdSq31s5FPgwgQOJrQdLk3MCeuuAj1T0ZHzeEY=; b=XkY/CTr5XKApi+BlkU71FtPsVxm2QUY6+h8riRmctmDaPEl4fvgRKK/DQ7MWfX9QNC Qjc+viwbK2G/tz364sCcIE4tWv4+TDB9kcfmTS7BphNEPCUVTwxKZBtum+8K1ucEOMrF +OubV5nIL7zjMsQog137ULXIf6DJNaxSz8B5HagEeT4ZTpbQ5Ll8RIqCqnHzU+JoD9OQ ncIn39LllggK5NXO3r+Mr4NMm8d+o0KXnIr3MDnfF8KfsqP4KxdZK3FTquJs0FA0fdYN ftWRue14SGGG/WRFjhwhzCLQHEK0eEl/y5lQd4wCLm75t9Xt5id6xmAab2RwF5YBGTgk pwbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ImfH1DdSq31s5FPgwgQOJrQdLk3MCeuuAj1T0ZHzeEY=; b=eJcjl6BWTn4EaeiMU1RiQTGiahESgzdFnUOaYx0Vgd5pzseSnF+bq4LOMUoMVCQpBI Xe73h6Eb00D2zvGJMk86V4mnqJBJK81biVWfkJpGyBpf4xLyP7H6zWb5aR5YVR+WQHV3 Bi83hzc1bQeF3+NZmQazIhUMHiJ+yr3PgSgWx9Izc4iy5cLyaJCX5TKp3UdPxFts4OeC XQxMDmHGQBFnWLUo/g/5KJwL/6aqRoVG7/wRxZOeZJHXOESZ6LsFb6JoyYzS+ETmXFcO H66gma/UBki0SEM5qLlcU7zF/4Th1RnjAlUvnRfOPsyZx2wEc24+oaP0xUnZj9OK06KU oLWQ== X-Gm-Message-State: AIVw111n7yBDH8sehMZWBG8ghDrKjTduTK5fsDKtEUYw3fLhG78GHAL6 /sZSPHmf49vsQflkJoSr2vyhGeO8j6gdu6M= X-Received: by 10.107.59.69 with SMTP id i66mr23344350ioa.202.1501611693587; Tue, 01 Aug 2017 11:21:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.159 with HTTP; Tue, 1 Aug 2017 11:21:32 -0700 (PDT) In-Reply-To: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> References: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> From: Daniel Margolis Date: Tue, 1 Aug 2017 14:21:32 -0400 Message-ID: To: Jim Fenton Cc: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114f7de49dc2270555b53746" Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 18:21:37 -0000 --001a114f7de49dc2270555b53746 Content-Type: multipart/alternative; boundary="001a114f7de496c35f0555b537c8" --001a114f7de496c35f0555b537c8 Content-Type: text/plain; charset="UTF-8" Hey, Jim. Few points: On Mon, Jul 31, 2017 at 7:02 PM, Jim Fenton wrote: > > > Section 4.3.2.1, dnssec-invalid: In this case, would the TLSRPT policy > be found? > Heh. It's a good point. But a sender can of course choose not to validate DNSSEC for the destination domain when looking up the TLSRPT record (and potentially MX records used for TLSRPT delivery). It seems unlikely to be the common case--misconfiguring your DS record or signing keys (as opposed to your TLSA records) is quite likely to result in mail never being delivered because MX records effectively fail to resolve--but it's hypothetically possible for a sender to still send TLSRPT reports from a client whose resolver does not validate, and we leave that possibility open by having this error type. > Section 7, Reports as DDoS: The discussion revolves around the fact > that, unlike DMARC, there isn't a third party involved in a DMARC report > so it isn't necessary to validate delegation. I'm not sure this > completely alleviates the DDoS risk, though: it's equally possible for > malicious second parties to overload the receiver with reports, or for > malicious parties to look around for TLSRPT policies with mailto: > addresses and just spam them. It's certainly possible that merely running a mail service opens you up to a DoS. But TLSRPT with mailto: endpoints doesn't (I would contend) exacerbate the risk, in that we assume anyone running a mailto: endpoint for TLSRPT is probably already running a mail service. The point of that paragraph is really to explain why DMARC's misdirected-reports attack doesn't apply; without that attack, the only concern is the generic case of "you're running a mail server and might get unwanted mail." Which is true, but isn't new attack surface induced by TLSRPT. > Also, the suggestion of sending the messages daily for > 0000-2400 UTC (section 4.1) does not scale well, and may be a DDoS in > itself. > I think your point is that while it may make sense to send daily reports, they should not necessarily be *synchronized*--i.e. the mail covering the period 00:00 - 24:00 should not be sent at 24:00. That's a fair point and maybe worth being called out, I agree. > > Section 7, additional consideration: The "untrusted content" > consideration talks about malicious code, but attackers could also send > counterfeit reports that look real in an effort to confuse the report > recipient. Should valid DKIM signatures from the reporting domain be > required on TLSRPT messages? > > Detailed comments and nits: > > 1.1 last bullet: initiating the delivery -> initiating the transmission > > 3. in tlsrpt-uri: [@!RFC3986] -> [RFC3986] > What is the "numeric portion" that is referred to here? > > 4. bullet 2a "neither a TLSA nor MTA-STS policy" -> "neither a DANE nor > MTA-STS policy" > > 5.1 "The filename is typically constructed": Is that a MAY? SHOULD? > DMARC uses this wording, but it's informational. > Following the ABNF, "json.gz": The IANA considerations section > lists this is .gz. And the MUST here is confusing, is this only if the > filename is 'typically constructed' or always? > > 5.3 The [RFC5322].Subject field for individual report submissions: There > isn't an "individual" report defined here. Looks like this is left over > from DMARC. > > 5.4 should use the media type -> SHOULD use the media type > > 5.5 should be on a logarithmic scale -> SHOULD be on a logarithmic scale > (do MTAs typically do this, or is it calling for something special?) > > Sections 8 and 9 should be renumbered as appendices, and marked as > informative examples. > > -Jim > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a114f7de496c35f0555b537c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey, Jim. Few points:

<= div class=3D"gmail_quote">On Mon, Jul 31, 2017 at 7:02 PM, Jim Fenton <fenton@bluepopcorn.net> wrote:


Section 4.3.2.1, dnssec-invalid: In this case, would the TLSRPT policy
be found?

Heh. It's a good point. B= ut a sender can of course choose not to validate DNSSEC for the destination= domain when looking up the TLSRPT record (and potentially MX records used = for TLSRPT delivery). It seems unlikely to be the common case--misconfiguri= ng your DS record or signing keys (as opposed to your TLSA records) is quit= e likely to result in mail never being delivered because MX records effecti= vely fail to resolve--but it's hypothetically possible for a sender to = still send TLSRPT reports from a client whose resolver does not validate, a= nd we leave that possibility open by having this error type.
=C2= =A0
Section 7, Reports as DDoS: The dis= cussion revolves around the fact
that, unlike DMARC, there isn't a third party involved in a DMARC repor= t
so it isn't necessary to validate delegation. I'm not sure this
completely alleviates the DDoS risk, though: it's equally possible for<= br> malicious second parties to overload the receiver with reports, or for
malicious parties to look around for TLSRPT policies with mailto:
addresses and just spam them.

It's cert= ainly possible that merely running a mail service opens you up to a DoS. Bu= t TLSRPT with mailto: endpoints doesn't (I would contend) exacerbate th= e risk, in that we assume anyone running a mailto: endpoint for TLSRPT is p= robably already running a mail service. The point of that paragraph is real= ly to explain why DMARC's misdirected-reports attack doesn't apply;= without that attack, the only concern is the generic case of "you'= ;re running a mail server and might get unwanted mail." Which is true,= but isn't new attack surface induced by TLSRPT.=C2=A0
=C2=A0=
=C2=A0
Also, the suggestion = of sending the messages daily for
0000-2400 UTC (section 4.1) does not scale well, and may be a DDoS in
itself.

I think your point is that whil= e it may make sense to send daily reports, they should not necessarily be <= i>synchronized--i.e. the mail covering the period 00:00 - 24:00 should = not be sent at 24:00. That's a fair point and maybe worth being called = out, I agree.=C2=A0
=C2=A0

Section 7, additional consideration: The "untrusted content"
consideration talks about malicious code, but attackers could also send
counterfeit reports that look real in an effort to confuse the report
recipient. Should valid DKIM signatures from the reporting domain be
required on TLSRPT messages?

Detailed comments and nits:

1.1 last bullet: initiating the delivery -> initiating the transmission<= br>
3. in tlsrpt-uri: [@!RFC3986] -> [RFC3986]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 What is the "numeric portion" that is= referred to here?

4. bullet 2a "neither a TLSA nor MTA-STS policy" -> "neit= her a DANE nor
MTA-STS policy"

5.1 "The filename is typically constructed": Is that a MAY? SHOUL= D?
DMARC uses this wording, but it's informational.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Following the ABNF, "json.gz": The IA= NA considerations section
lists this is .gz. And the MUST here is confusing, is this only if the
filename is 'typically constructed' or always?

5.3 The [RFC5322].Subject field for individual report submissions: There isn't an "individual" report defined here. Looks like this is= left over
from DMARC.

5.4 should use the media type -> SHOULD use the media type

5.5 should be on a logarithmic scale -> SHOULD be on a logarithmic scale=
(do MTAs typically do this, or is it calling for something special?)

Sections 8 and 9 should be renumbered as appendices, and marked as
informative examples.

-Jim

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--001a114f7de496c35f0555b537c8-- --001a114f7de49dc2270555b53746 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMK8x525biWylzaTdKMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTE4NDIxNVoXDTE3MTAx ODE4NDIxNVowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwhqodpCO7YNSzRIz9ahzJEd2Fmnm1g9pYE2GUs5S8c6Jh JLiZkF4+kTvQVptWmuoWxWqgeIJcqZKozIYoNl06ecCUcCSo/61I+QeD061Vfl9SemzDYrK9IJ5i fsx9sXOD+c20D4Lef7F0wC9azTDs36EwgEDBcLKUef5/Y/n3TDPth8kllj0cKBitt1MC2Il95W7a MyESYucDAH7gSG/dIOGNUaIh+vLLMtRvDQVRfveOum2uUf52bF3rywDJ32dvPCDVsRJHWuhBUfaP shyNiw4d/NzDjMdc504m+GABUpF9r8203gWdhHMxPyeDIzeV7wujWEZ19c0jOcFwdpupAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFB8LoXS3E+322ae/sSMWqyi4zefEMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCeAGD8kMXY iuahwdAzZ8iUfQSAM9M8Q1JPN+jXR6gcJXagqqdjHep1KcrhYx4xvhAUurzdH0AtzjdHuS1OKOj4 OYaMUtjuSYQ6SfFdpkM6K/Ih9IklpIV4BynT4/8D6WROz5f+sQGMf22geoCWbRUsBZv7GgMIWg+1 w6F7FiSFR7NKTBRZS4y/SHv0LCtC12JHyyVQrbxrjXy2tIcrhKC0DhToxe4s9aIA/kauGUSGXyLa U55gCBKpReCTtn1b4aQIwJp9aj0wDzfqs88hyIkWKDUMW7VP+Wdk9y6qUpKwbSN9pIu3m3UmjZC7 6923PlCyPXBkAIcLrTExf7wVn9lpMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDL9ZVihQP3VtiE w2F/vTvuYUbZVzKL73c4yNpN0jiwPjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MDExODIxMzRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAfoKIIwYJTOOg/EiTS8BX6eFO2IJaG5CB 8GJKf+PTxiMdZyqlE/ycD1y3AvUt0/8w02iu81+ffH79nEEjx6AYdlxQ139gFNvDtgme7MuIDT6W ptPRUt6THyqbrzzRayTgOUM5nKA1mrDRD2Zjd/QEqoQ4DowEHkksEXik//gbMZomI8zEtRmHTepY jFlU0uezn+HQQyKCAm2/UsvnGn1hI3nhXkCYqPY2eCiqgVp2v4a1BdONW5S+E9b4qCd3/GRBDLMw kpS0IQAXLb5s2CqCguCWvYNBrXmSQH0rl3LS36iyo3pmkOJbhsSlJnj8LLDSEmW5uP1y1B8pCrHa E09bfQ== --001a114f7de49dc2270555b53746-- From nobody Tue Aug 1 11:41:16 2017 Return-Path: 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 0C9A1131C3C for ; Tue, 1 Aug 2017 11:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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] 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 RJDEpDihD3Dp for ; Tue, 1 Aug 2017 11:41:13 -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 D00A7131C2C for ; Tue, 1 Aug 2017 11:41:13 -0700 (PDT) Received: from splunge.local (c-24-4-226-141.hsd1.ca.comcast.net [24.4.226.141]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v71IfB1i013699 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 1 Aug 2017 11:41:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1501612873; bh=gk4VOWuaEOd1QYkEqdv9ywwMngTt2Y5XQjCSD8PzIMM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=E1ka8Omt15lmJF4xvv2LohipcKe5OhvCWSuuv7q9dUjON2ZBdfTGd0n95Jlf4SX4H gyg4HxuLYV9r2/1eEWkBVy9X9+NO9aT4ado/7rwc3eGK43qFsyB5a3Rgee+yuSOCmN EmB+wYFTdvvZU0rwN3wHegg8uIC5CqkIDsL0yPdU= To: Alexey Melnikov Cc: uta@ietf.org References: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> <24B2EFA1-457B-4C4D-8AFF-7B42D89F48D4@isode.com> From: Jim Fenton Message-ID: Date: Tue, 1 Aug 2017 11:41:05 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <24B2EFA1-457B-4C4D-8AFF-7B42D89F48D4@isode.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 18:41:15 -0000 On 8/1/17 2:11 AM, Alexey Melnikov wrote: > Jim, > I would like to disagree: > >> On 1 Aug 2017, at 00:02, Jim Fenton wrote: >> >> Section 5.3, I don't think it's a good idea to define and require new >> message header fields for this. This means that some of the >> general-purpose libraries for sending email messages can't be used. > Do you mean that a general purpose library is unable to add arbitrary h= eader fields? This doesn't seem to qualify as "general purpose". "General purpose" was the wrong phrase. My suspicion was that higher-level libraries for easily sending an email message from a program wouldn't necessarily support adding arbitrary email header fields. But I did a bit more research, and the ones I have found do allow addition of arbitrary header fields. > >> A better approach IMO would be to suggest the use of separate email >> addresses (e.g., reports@example.org or reports+client1@example.org fo= r >> a service provider) in order to distinguish reports from other traffic= =2E > This is already possible. Yes, and for this reason the requirement to add new message header fields seems gratuitous. I expect reports will be separated by destination address rather than using IMAP filters, the latter being given as the motivation for the new header fields. -Jim From nobody Tue Aug 1 12:36:10 2017 Return-Path: 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 20DE41322E7 for ; Tue, 1 Aug 2017 12:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com 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 h_k35SjAJbEQ for ; Tue, 1 Aug 2017 12:36:06 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C205113215C for ; Tue, 1 Aug 2017 12:36:04 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id t128so11299883lff.2 for ; Tue, 01 Aug 2017 12:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=5GmmzbYubLYtn8trlVmHhdTOzY6b6T0Y1N57JLqffMQ=; b=acUNdaNlWpdj0nmOgbcpuotxkiudFD3bxnTEx6tcUgA6Ixkja3QsPsxk01lwevwhyb UpA0arG8h5M6vQBooA4EktNc6SuUCYKd3sIENA4WkSAK50nt+07qnU92y8U+1ha945YU b2cJy6NUKCcWD5FCpdlpyV/6mNktQHcDA46uAFWXui4Zdgg6jNG1BwsoCgGGc+Rl1h3k WipytZEXhvoqVetxa+wan2wxn/4fkAbO4/LVDLRzTDd+0rE7wZeoyhsJMjy/1tivyln7 ahlWb0f8uICoNdMWyxJb39u+itLFO2uJTPJVr+1C27YfOJygOgP+U1W7nReXiplH0cYf fThg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5GmmzbYubLYtn8trlVmHhdTOzY6b6T0Y1N57JLqffMQ=; b=QWZjoT2A4TVPO4ntYg7Bv42vy3P1ANdmoEBfpZccx498YsfEdiIl0BLk1c9ENxt1AF WlBYW8jJiX2N01YvWcyr/ZRjykbGXKI2yl+Z9/QoLaHVSnzfYn42e9WVrSqpTNqs44fu MxTcPnifx5tJ28jHzWuO5y/JrvCkIAmu01/aubXdIR5QN0bYHngqFlF+SAFqsD+rN4Fq FvPZ83qr53d4VDLXa7wPCqG4iz42P98icZYAYKVcheI/dn4Ai1+1I6U0TQR7Gmm8mrw5 dSo+5Mx0jjLKfKI3ZDFNxXG+qsZNfJpvPSxqUuL8LqpiHKq4u0CCH+Doa5ccmplUQ/6v /uBw== X-Gm-Message-State: AIVw113E+Mvn+L2eNx68JfB2XGDxTgPtUG7Bizqmly70IUVuoFUmRYbR K+ZtKmlS0xKz4nEJ06U9zQ== X-Received: by 10.25.195.16 with SMTP id t16mr7397004lff.186.1501616162888; Tue, 01 Aug 2017 12:36:02 -0700 (PDT) Received: from [192.168.1.72] (81-230-12-165-no206.tbcn.telia.com. [81.230.12.165]) by smtp.gmail.com with ESMTPSA id w15sm5029982ljd.57.2017.08.01.12.36.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 12:36:02 -0700 (PDT) To: uta@ietf.org References: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> From: Leif Johansson Message-ID: <5e4b55fd-82d0-8944-2e31-80758b9f0544@sunet.se> Date: Tue, 1 Aug 2017 21:36:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 19:36:09 -0000 On 2017-08-01 20:21, Daniel Margolis wrote: > Hey, Jim. Few points: Jim - if you can suggest text on any of your non-nit issues that might make it easier to zero in on a final version of this. Cheers Leif > > On Mon, Jul 31, 2017 at 7:02 PM, Jim Fenton > wrote: > > > > Section 4.3.2.1, dnssec-invalid: In this case, would the TLSRPT policy > be found? > > > Heh. It's a good point. But a sender can of course choose not to > validate DNSSEC for the destination domain when looking up the TLSRPT > record (and potentially MX records used for TLSRPT delivery). It seems > unlikely to be the common case--misconfiguring your DS record or signing > keys (as opposed to your TLSA records) is quite likely to result in mail > never being delivered because MX records effectively fail to > resolve--but it's hypothetically possible for a sender to still send > TLSRPT reports from a client whose resolver does not validate, and we > leave that possibility open by having this error type. > > > Section 7, Reports as DDoS: The discussion revolves around the fact > that, unlike DMARC, there isn't a third party involved in a DMARC report > so it isn't necessary to validate delegation. I'm not sure this > completely alleviates the DDoS risk, though: it's equally possible for > malicious second parties to overload the receiver with reports, or for > malicious parties to look around for TLSRPT policies with mailto: > addresses and just spam them. > > > It's certainly possible that merely running a mail service opens you up > to a DoS. But TLSRPT with mailto: endpoints doesn't (I would contend) > exacerbate the risk, in that we assume anyone running a mailto: endpoint > for TLSRPT is probably already running a mail service. The point of that > paragraph is really to explain why DMARC's misdirected-reports attack > doesn't apply; without that attack, the only concern is the generic case > of "you're running a mail server and might get unwanted mail." Which is > true, but isn't new attack surface induced by TLSRPT. > > > > Also, the suggestion of sending the messages daily for > 0000-2400 UTC (section 4.1) does not scale well, and may be a DDoS in > itself. > > > I think your point is that while it may make sense to send daily > reports, they should not necessarily be /synchronized/--i.e. the mail > covering the period 00:00 - 24:00 should not be sent at 24:00. That's a > fair point and maybe worth being called out, I agree. > > > > Section 7, additional consideration: The "untrusted content" > consideration talks about malicious code, but attackers could also send > counterfeit reports that look real in an effort to confuse the report > recipient. Should valid DKIM signatures from the reporting domain be > required on TLSRPT messages? > > Detailed comments and nits: > > 1.1 last bullet: initiating the delivery -> initiating the transmission > > 3. in tlsrpt-uri: [@!RFC3986] -> [RFC3986] > What is the "numeric portion" that is referred to here? > > 4. bullet 2a "neither a TLSA nor MTA-STS policy" -> "neither a DANE nor > MTA-STS policy" > > 5.1 "The filename is typically constructed": Is that a MAY? SHOULD? > DMARC uses this wording, but it's informational. > Following the ABNF, "json.gz": The IANA considerations section > lists this is .gz. And the MUST here is confusing, is this only if the > filename is 'typically constructed' or always? > > 5.3 The [RFC5322].Subject field for individual report submissions: There > isn't an "individual" report defined here. Looks like this is left over > from DMARC. > > 5.4 should use the media type -> SHOULD use the media type > > 5.5 should be on a logarithmic scale -> SHOULD be on a logarithmic scale > (do MTAs typically do this, or is it calling for something special?) > > Sections 8 and 9 should be renumbered as appendices, and marked as > informative examples. > > -Jim > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > > > > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > From nobody Tue Aug 1 13:02:14 2017 Return-Path: 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 DEC85127136 for ; Tue, 1 Aug 2017 13:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 wGxofHJiR-oP for ; Tue, 1 Aug 2017 13:02:11 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id A03F3126B71 for ; Tue, 1 Aug 2017 13:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1501617730; d=isode.com; s=june2016; i=@isode.com; bh=KTS6VHHk0iZrlGhAcqaxmsauRatHTTNQzCA6aHgAQ3w=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=sq7wm6hXYfisYuSebUzV27T0r6BP2aGu3+0+pg8AD4q4HJ3KoOElcnXF7QCjQWo6v+vdi7 FbaLbvRd2xV+L3rgyPX1A0H5PXbsJT/90inPjQmHrXYGBMNdJjxqebYIJsaolDimxhRLd5 sLYqWKFtV1fdzNGFjEhXzZZHDR0Dims=; Received: from [192.168.0.3] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 1 Aug 2017 21:02:10 +0100 To: Jim Fenton References: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> <24B2EFA1-457B-4C4D-8AFF-7B42D89F48D4@isode.com> Cc: uta@ietf.org From: Alexey Melnikov Message-ID: <5980DE3B.6010409@isode.com> Date: Tue, 1 Aug 2017 21:02:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 20:02:13 -0000 On 01/08/2017 19:41, Jim Fenton wrote: > On 8/1/17 2:11 AM, Alexey Melnikov wrote: >> Jim, >> I would like to disagree: >> >>> On 1 Aug 2017, at 00:02, Jim Fenton wrote: >>> A better approach IMO would be to suggest the use of separate email >>> addresses (e.g., reports@example.org or reports+client1@example.org for >>> a service provider) in order to distinguish reports from other traffic. >> This is already possible. > > Yes, and for this reason the requirement to add new message header > fields seems gratuitous. I expect reports will be separated by > destination address rather than using IMAP filters, the latter being > given as the motivation for the new header fields. Not really, abusing Subject to encode this information is a hack. So these header fields are useful even only if one type of report goes to a particular email mailbox, because it is easy to separate specific reports by domains, etc. programmatically, for example using IMAP. From nobody Tue Aug 1 13:08:16 2017 Return-Path: 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 A11FA129B26 for ; Tue, 1 Aug 2017 13:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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] 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 nv0PK1HOSW5r for ; Tue, 1 Aug 2017 13:08:13 -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 38882126B71 for ; Tue, 1 Aug 2017 13:08:13 -0700 (PDT) Received: from splunge.local (c-24-4-226-141.hsd1.ca.comcast.net [24.4.226.141]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v71K8AkA014898 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 1 Aug 2017 13:08:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1501618092; bh=Ht0n/ijNO6GXy3qvrAHiEvrLKRML6q++BWLehTVb7fA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=udsRWSJ5l/6s3c6HEafk3W14ufPy8yBHKZi2i7/VHX4IGUM/Xz8EDzLlT7bmsfkuR XhHm4xdk5iNewhAjhstrWDg2bq7OOGt5Qozo04kd5DPgCdR6FldOBWVC6vFEWtSUSn k92fyFzXuAuhHYueFLrWQU5ePEkKaTVSua+rpQZA= To: Alexey Melnikov Cc: uta@ietf.org References: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> <24B2EFA1-457B-4C4D-8AFF-7B42D89F48D4@isode.com> <5980DE3B.6010409@isode.com> From: Jim Fenton Message-ID: Date: Tue, 1 Aug 2017 13:08:04 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5980DE3B.6010409@isode.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 20:08:15 -0000 On 8/1/17 1:02 PM, Alexey Melnikov wrote: > On 01/08/2017 19:41, Jim Fenton wrote: >> On 8/1/17 2:11 AM, Alexey Melnikov wrote: >>> Jim, >>> I would like to disagree: >>> >>>> On 1 Aug 2017, at 00:02, Jim Fenton wrote: >>>> A better approach IMO would be to suggest the use of separate email >>>> addresses (e.g., reports@example.org or reports+client1@example.org for >>>> a service provider) in order to distinguish reports from other traffic. >>> This is already possible. >> Yes, and for this reason the requirement to add new message header >> fields seems gratuitous. I expect reports will be separated by >> destination address rather than using IMAP filters, the latter being >> given as the motivation for the new header fields. > Not really, abusing Subject to encode this information is a hack. So > these header fields are useful even only if one type of report goes to a > particular email mailbox, because it is easy to separate specific > reports by domains, etc. programmatically, for example using IMAP. I don't think I was suggesting anything involving Subject. There's already some of this in Section 5.3, and I'm not crazy about doing that either, especially since it's only a SHOULD (so the report recipient can't really depend on it being formatted that way). From nobody Tue Aug 1 22:17:41 2017 Return-Path: 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 E25AB127ABE for ; Tue, 1 Aug 2017 22:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com 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 5XaClXn2l161 for ; Tue, 1 Aug 2017 22:17:38 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A561126CD8 for ; Tue, 1 Aug 2017 22:17:38 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id o85so15156951lff.3 for ; Tue, 01 Aug 2017 22:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=jP8nzEEOqNdfTQVSSrKldU/ssCtNhAXyQf9f3GEmpk4=; b=XtHDbNYC01qNrZq2pA1BJbYWo2uw2/OLqDVrrQG64crb6d6xKEAOvrOHG0dGX8Jm6G w2mn8K5m9a5LbaL+gVAGx6nnIGsLHWadLm0bcjLT66fcjnLeXA/F3raFiNnAeKToY+VA cYqb8LXrQuwsH2AkSPPZ6UA6z27BKw8pUtszitn5L24kzyZVpujVPpakGk8ty5hja/Ei FXrqCkrf4OZeNa4FxHM6yuvUPnX+UvxwQO+N4zvR6lRSfBRVDSCQ9a5H6nUTBvrZKYNm HhUGbIlHT5PdMmQk81npiDU2ggVTgCxMeMH17g89jEIh9Y3BYeI7AvcCojU/axDVvpZ8 C5sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jP8nzEEOqNdfTQVSSrKldU/ssCtNhAXyQf9f3GEmpk4=; b=hqzb/clXOMSf/HL82Ym7YnZo/dVy6xLtTtlGuRSoY4J84Fup1TMh1T5CjAAMLFHnWz G6zAOR/ST1JpbS8HB2HgqDD7KFqLW541uRN3y9wCV4l+xyQkA3GL/SRMXETcgiLJjhhs qmSeHq72ViaK+VIcKyPxN70HUGE20QRus4m4d2DJPXd2yK6Po+xZ0gBJVkCSFvPqVoWN VkFv0IfvtTqxLxtehNcO1cOhAQSOxtYptg4nYiYYYtI1NY/xE0SWRwnfG+5AWw4QkS2t G3gscKNm6BMeN1oYx0kGPVTygTTPtf8m3nIZjuvf+CtEANWLvhfQ1K8iPpIMqZOYMeAy sc+Q== X-Gm-Message-State: AIVw113W2mHmhaXCQVmsgts7/WMWhSwShcAh/VKNEkmxwRto3CtA/Rux tpxGo2tXEEjWvVg3+jelTA== X-Received: by 10.46.20.74 with SMTP id 10mr3386020lju.11.1501651055984; Tue, 01 Aug 2017 22:17:35 -0700 (PDT) Received: from [192.168.1.72] (81-230-12-165-no206.tbcn.telia.com. [81.230.12.165]) by smtp.gmail.com with ESMTPSA id 25sm6902750ljn.10.2017.08.01.22.17.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 22:17:34 -0700 (PDT) To: uta@ietf.org References: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> <24B2EFA1-457B-4C4D-8AFF-7B42D89F48D4@isode.com> <5980DE3B.6010409@isode.com> From: Leif Johansson Message-ID: Date: Wed, 2 Aug 2017 07:17:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 05:17:40 -0000 On 2017-08-01 22:08, Jim Fenton wrote: > On 8/1/17 1:02 PM, Alexey Melnikov wrote: >> On 01/08/2017 19:41, Jim Fenton wrote: >>> On 8/1/17 2:11 AM, Alexey Melnikov wrote: >>>> Jim, >>>> I would like to disagree: >>>> >>>>> On 1 Aug 2017, at 00:02, Jim Fenton wrote: >>>>> A better approach IMO would be to suggest the use of separate email >>>>> addresses (e.g., reports@example.org or reports+client1@example.org for >>>>> a service provider) in order to distinguish reports from other traffic. >>>> This is already possible. >>> Yes, and for this reason the requirement to add new message header >>> fields seems gratuitous. I expect reports will be separated by >>> destination address rather than using IMAP filters, the latter being >>> given as the motivation for the new header fields. >> Not really, abusing Subject to encode this information is a hack. So >> these header fields are useful even only if one type of report goes to a >> particular email mailbox, because it is easy to separate specific >> reports by domains, etc. programmatically, for example using IMAP. > > I don't think I was suggesting anything involving Subject. There's > already some of this in Section 5.3, and I'm not crazy about doing that > either, especially since it's only a SHOULD (so the report recipient > can't really depend on it being formatted that way). On the contrary. A SHOULD basically means you follow the spec unless you have a good reason not to do so. From nobody Wed Aug 2 01:15:38 2017 Return-Path: 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 5780D131C04 for ; Wed, 2 Aug 2017 01:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 c3FkKnPvqCOu for ; Wed, 2 Aug 2017 01:15:35 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06DB126BF3 for ; Wed, 2 Aug 2017 01:15:35 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id v77so12696362pgb.3 for ; Wed, 02 Aug 2017 01:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mX/dKqnhOHyfkmtu0R88HEA5/hX/ei7gEdu34G5mQaE=; b=bMuUyLPgnKA11TwHfncpnpLAFdv3ow19qX2w4BteVFg+DkNVkYiw342Tm/RmUPIf6W lbNKjI42kLosRIg4asCgGknhrZrtuYPvEYWL8TQ7r4Oqz7s3VBeyexcJ6Gx/U8FEtK60 M2zkixQ2i25JE65OODHXTi78QKyTy8eRsi12n2uywwnKrw/FxMjsR9W07a5pFOsCNWjX 5TV0zZgKPvsJuxZoO8yY05vsG6225hNiL1wENlliOx0nbvUJSQ34aql3UZSqZoCb1+Gn tX+lKHvUjcqpN9O/0qZBNh0xjeKzRBWbmVosEZilxbX/EyfH+1XeLXngMfqCDvtDBjPx fIcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mX/dKqnhOHyfkmtu0R88HEA5/hX/ei7gEdu34G5mQaE=; b=pUcKtURojOD1gv4E+5n7sGShpVDEl3ju5hnClerwOt1eJxzXZX4UZUTKUXAQemqUzF WhmSz5uxLXS2bTN4Nom1SO7+VVyrjx+sJpwoLAT24x/lpT2M1BA0Iu6acxTLn3htGkEd skLA21ZSD7mtBYt1aRf9UjoBVkVpiCLRVEhyG7Y5FsX1n1JmdRKcZaajQCotB1bodozu 5flqWh7TAtjggkVtXtzohWwx8ggsxeDxez/YEU0eFLYHtCUIRwuCYFfTiVlHNwbOrt4j HyOsTTxe0IySVtmpYjK6Lr5PKqTlfCw8UG1ikOeTJriyQvhBWcUVo8RfWBQAsvUDb2tJ DXKA== X-Gm-Message-State: AIVw1109es3XYjJSvYTPbz0Rdw666TJ4C10GN+JMzxcW/73OWRTtjYxc y7AzycvYpP6GOH3fKSTaQxjD7Z2ezfqv18s= X-Received: by 10.84.237.15 with SMTP id s15mr25506705plk.100.1501661735508; Wed, 02 Aug 2017 01:15:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.2 with HTTP; Wed, 2 Aug 2017 01:15:34 -0700 (PDT) In-Reply-To: <24ecb63305ed43bc8ee0564d5cd18b69@PACDCEX19.cable.comcast.com> References: <24ecb63305ed43bc8ee0564d5cd18b69@PACDCEX19.cable.comcast.com> From: David Illsley Date: Wed, 2 Aug 2017 09:15:34 +0100 Message-ID: To: "Brotman, Alexander" Cc: "uta@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1ceb7e5161230555c0defb" Archived-At: Subject: Re: [Uta] Updated TLSRPT Draft (v07) X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 08:15:37 -0000 --94eb2c1ceb7e5161230555c0defb Content-Type: text/plain; charset="UTF-8" A couple of minor comments: 1. Section 3 includes: "A URI specifying the endpoint to which aggregate information about policy failures should be sent" and "When sending failure reports via SMTP" This might imply that reports should only be sent when a failure is experienced, whereas I believe the intention is for this to be like DMARC where reporting is sent when messages are exchanged even if there are no policy failures. This could be clarified with the above changed to: "A URI specifying the endpoint to which aggregate information about policy validation results should be sent" and "When sending aggregate reports via SMTP" 2. Appendix 2: Example JSON Report - the JSON has a few syntax problems: - A , is required after the "summary" object - A " is required to close the result-type property in the third failure - A " is required to close the receiving-mx-hostname in the third failure HTH David On Mon, Jul 31, 2017 at 6:35 PM, Brotman, Alexander < Alexander_Brotman@comcast.com> wrote: > Hello Folks, > > We attempted to incorporate the feedback from Alexey and Chris as best we > could, and we believe we have addressed each of their concerns either via > the updated draft or via the mailing list. The period for the WGLC is > nearly over, and we wanted to try to provide an interim/updated draft for > any final review. Thank you for any comments. > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse > Comcast > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --94eb2c1ceb7e5161230555c0defb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A couple of minor comments:
1. Section 3 in= cludes:
=C2=A0 "A URI specifying the endpoint to which a= ggregate information about policy failures should be sent" and "W= hen sending failure reports via SMTP"
This might imply = that reports should only be sent when a failure is experienced, whereas I b= elieve the intention is for this to be like DMARC where reporting is sent w= hen messages are exchanged even if there are no policy failures.
= This could be clarified with the above changed to:
=C2=A0"A = URI specifying the endpoint to which aggregate information about=20 policy validation results should be sent" and "When sending aggre= gate reports via=20 SMTP"

2. Appendix 2: Example JSON Report - th= e JSON has a few syntax problems:
=C2=A0- A , is required after t= he "summary" object
=C2=A0- A " is required to clo= se the result-type property in the third failure
=C2=A0- A "= is required to close the receiving-mx-hostname in the third failure

HTH
David


On Mon, Jul 31, 201= 7 at 6:35 PM, Brotman, Alexander <Alexander_Brotman@comcast.co= m> wrote:
Hello Folks,

We attempted to incorporate the feedback from Alexey and Chris as best we c= ould, and we believe we have addressed each of their concerns either via th= e updated draft or via the mailing list.=C2=A0 The period for the WGLC is n= early over, and we wanted to try to provide an interim/updated draft for an= y final review.=C2=A0 Thank you for any comments.

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast


_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--94eb2c1ceb7e5161230555c0defb-- From nobody Wed Aug 2 13:43:07 2017 Return-Path: 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 1811413188D for ; Wed, 2 Aug 2017 13:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 x--qK8mMNmYX for ; Wed, 2 Aug 2017 13:43:05 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAFE131C98 for ; Wed, 2 Aug 2017 13:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1501706584; d=isode.com; s=june2016; i=@isode.com; bh=hjyWzgzw+dGmJv+Ax82JSq2kwgvFDUfujqn5p8PfbiM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=oePDhyB88r/GqBLVr4uFHtLXQ00VqYRSJixA5fmmhcpW3h4oWfbWx7cMQl9SgVwzQEXgxR BttBqoT8/Y63ZC8KAZAQqnmcAoaiQ4tYo/QBc29RcwXE2XUfA9zYSz7RSGsqKFY74Wg7vo CjN+qZItSOle/UHFVtWWWWunMw+iR2E=; Received: from [192.168.0.3] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 2 Aug 2017 21:43:04 +0100 To: Chris Newman , Leif Johansson References: Cc: uta@ietf.org From: Alexey Melnikov Message-ID: <59823957.2050106@isode.com> Date: Wed, 2 Aug 2017 21:43:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 20:43:06 -0000 On 20/07/2017 13:28, Chris Newman wrote: >> o "email-address": The contact information for a responsible party >> of the report. It is provided as a string formatted according to >> Section 3.4.1, "Addr-Spec", of [RFC5322]. >=20 > Can we format according to the "Mailbox" rule in section 4.1.2 of > [RFC5321]? I'd prefer not to require receivers to strip out FWS & CFWS > from the address. I think this change would be a good idea. From nobody Wed Aug 2 22:01:51 2017 Return-Path: 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 B7EA912EC37 for ; Wed, 2 Aug 2017 22:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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] 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 ON70brpyvdHJ for ; Wed, 2 Aug 2017 22:01:49 -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 1CB3212783A for ; Wed, 2 Aug 2017 22:01:48 -0700 (PDT) Received: from [IPv6:2601:647:5500:1330:785f:b18f:418f:3fa1] ([IPv6:2601:647:5500:1330:785f:b18f:418f:3fa1]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v7351lKS005439 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 2 Aug 2017 22:01:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1501736508; bh=y8ZsLTwuoDYzdn3hGrSosCz2OILv+6PqEUAuXyReYE0=; h=Subject:To:References:From:Date:In-Reply-To; b=Vx8ro8+BYr3HZ9aAOeNrzcANYgjhRsLVtW7nUmUm5HdLvylf4jVe6EGbxXMjlHqH5 PvTbjUyVIK62gViHui2zNRw4dm4FIEwPxX8EXEpT/7rCtw46T62jnNbXHOeO0/w44X fR5sv0IlpVeGGuiYHpyRmwCOj2e9qVq+uAfHvhAM= To: uta@ietf.org References: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> <24B2EFA1-457B-4C4D-8AFF-7B42D89F48D4@isode.com> <5980DE3B.6010409@isode.com> From: Jim Fenton Message-ID: Date: Wed, 2 Aug 2017 22:01:40 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 05:01:51 -0000 On 08/01/2017 10:17 PM, Leif Johansson wrote: > > On 2017-08-01 22:08, Jim Fenton wrote: >> >> I don't think I was suggesting anything involving Subject. There's >> already some of this in Section 5.3, and I'm not crazy about doing tha= t >> either, especially since it's only a SHOULD (so the report recipient >> can't really depend on it being formatted that way). > On the contrary. A SHOULD basically means you follow the spec unless > you have a good reason not to do so. In this case, you're depending on all of the domains that send TLS reports not to have a good reason not to do so. Maybe I'm just extra-careful, but I don't know what good reasons might come up (maybe some agent rewriting the Subject header field?) so I would be inclined to not depend on it. If this Subject header field formatting stands, is there some requirement that the requirement isn't a MUST (like the TLS-Report-* header fields)? Even so, recipients need to be able to handle any Subject header field that anyone throws at them, at least to discard those messages and not otherwise fail. For that reason, I think it's a good idea to minimize the number of things that require robust checking. Isn't this information in the payload of the report anyway? I'm not a fan of redundant information that can be inconsistent. -Jim From nobody Thu Aug 3 14:11:28 2017 Return-Path: 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 6093C131C11 for ; Thu, 3 Aug 2017 14:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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] 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 jKTCiW8OUSJc for ; Thu, 3 Aug 2017 14:11:25 -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 260D012741D for ; Thu, 3 Aug 2017 14:11:24 -0700 (PDT) Received: from splunge.local (sfosf0017s350801.wiline.com [64.71.6.2] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v73LBMKd016320 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 3 Aug 2017 14:11:24 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1501794684; bh=7PATFh/7gbhX50bh2EAE+1m4VXIOIhHLAOhIUItSFOY=; h=Subject:From:To:References:Date:In-Reply-To; b=rHl3qLF3VmiCnagcrfdhbQEu2vpGFn1trm1VoLL5PSostLRKx5NCyBlXFJwOnKAns k6PPomGf+s9cexnDwYoJIcQmxo3WpqCj3TJoCK2n6AzKtLwQB4br8ewqM18uVoWjZO c9Nekdywjv15imrMN8kmolepIWo3mdut24Ruy5dY= From: Jim Fenton To: uta@ietf.org References: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> Message-ID: <8d9f92ea-6cea-1828-0f4b-3487240a81bd@bluepopcorn.net> Date: Thu, 3 Aug 2017 14:11:17 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 21:11:26 -0000 In response to Leif's request for specific text for the larger issues: On 7/31/17 4:02 PM, Jim Fenton wrote: > > General comments: > > All of the references are listed as normative, which I strongly suspect= > isn't really the case. Informative references need to be separated. > > As the document notes, the reference for MTA-STS needs to be added. If > it is a normative reference, this document will be held up until that i= s > published. I agree that the MTA-STS reference is informative. By my reading, the following RFC references are also informative: 3207, 3501, 3864, 7435, 7469, 7489 But check me on those... > > Section 3, what happens in the case of HTTPS delivery of reports if > there is some problem with the certificate presented by the server? For= > mailto:, it explicitly states that the message should be sent in the > clear if necessary, but that doesn't seem to be the case with https:. Section 3, third bullet: o In the case of "https", reports SHOULD be submitted via POST ([RFC2818]) to the specified URI. Report submitters MAY ignore certificate verification errors when submitting reports via https. > > Section 4.3.2.1, dnssec-invalid: In this case, would the TLSRPT policy > be found? Maybe just note this situation; add the following text to this bullet: Note that DNSSEC failures are likely to also affect the retrieval of the TLSRPT record, so reports with this failure are likely to be rare in practice. > > Section 5.1, I don't like the idea of associating semantics with the > filename of MIME parts. As it's written, use of the specified filename > format is optional, so the recipient can't depend on it anyway. DMARC > does this, and I didn't like it there either, but it's an informational= > document so this may not have gotten all the scrutiny this should as a > standards-track document. I suggest eliminating this requirement. > > Section 5.3, I don't think it's a good idea to define and require new > message header fields for this. This means that some of the > general-purpose libraries for sending email messages can't be used. A > better approach IMO would be to suggest the use of separate email > addresses (e.g., reports@example.org or reports+client1@example.org for= > a service provider) in order to distinguish reports from other traffic.= I suggest eliminating this requirement. > > IANA considerations: Consider adding a request to register _smtp-tlsrpt= > in the registry being created by draft-ietf-dnsop-attrleaf if that > registry is created before this is published. 6.6. _smtp-tlsrpt DNS Global Underscore Scoped Registry Entry This document registers a new DNS name in the "DNS Global Underscore Scoped Entry Registry" as follows: Scoped Entry: _smtp-tlsrpt Applicable protocol: SMTP Status: standard Author/Change controller: IETF Specification document(s): This document Note that this registry is created by the publication of draft-ietf-dnsop-attrleaf. If this document precedes it in publication, the entry is requested to be included in the registry at its creation. > > Section 7, Reports as DDoS: The discussion revolves around the fact > that, unlike DMARC, there isn't a third party involved in a DMARC repor= t > so it isn't necessary to validate delegation. I'm not sure this > completely alleviates the DDoS risk, though: it's equally possible for > malicious second parties to overload the receiver with reports, or for > malicious parties to look around for TLSRPT policies with mailto: > addresses and just spam them. It might be good to acknowledge that > possibility here. Also, the suggestion of sending the messages daily fo= r > 0000-2400 UTC (section 4.1) does not scale well, and may be a DDoS in > itself. Section 4.1: The report SHOULD cover a full day (24 hours). In order to avoid congestion caused by synchronized transmission and receipt of reports, report senders SHOULD choose an arbitrary time to send their reports, either individually or as a group. The transmission time MAY be determined, for example, by hashing the reporting domain name, taking the result modulo 1440, and sending reports at that many minutes past midnight UTC each day. In Section 7: (original text is OK here too if you prefer, but suggest including the "More broadly" sentence) Reports as DDoS: TLSRPT allows specifying destinations for reports that are outside the authority of the Policy Domain, which allows domains to delegate processing of reports to a partner organization. However, an attacker who controls a Policy Domain DNS could also use this mechanism to direct the reports to an unwitting victim, flooding that victim with excessive reports. More broadly, the publication of a reporting email address or URI presents the opportunity for the addresses to be harvested and used as the target of a DoS or DDoS attack. DMARC [RFC7489] defines a solution for verifying delegation to avoid such attacks, which is an effective countermeasure for innocent third-party senders of reports, but TLSRPT has less need for a verification mechanism because it would require the attacker to induce the innocent third party to send mail to the attacker. > > Section 7, additional consideration: The "untrusted content" > consideration talks about malicious code, but attackers could also send= > counterfeit reports that look real in an effort to confuse the report > recipient. Should valid DKIM signatures from the reporting domain be > required on TLSRPT messages? Add to Section 7: Deceptive reports: TLSRPT supports the processing of reports from arbitrary sources. As such, the data in the reports may be incorrect or even intentionally deceptive. Report recipients need to be aware of and prepared to handle this situation. Add to bullet 4 of Section 3: Reports sent via SMTP MUST contain a valid DKIM [RFC6376] signature by the reporting domain. Reports lacking such a signature MUST be ignored by the recipient. (add normative reference to RFC6376) (note that we still have a problem authenticating https reports, unless client-authenticated TLS is required, which would be an onerous requirement). From nobody Fri Aug 4 01:59:15 2017 Return-Path: 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 CC2691320BE for ; Fri, 4 Aug 2017 01:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com 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 pC9WVSVgLIX7 for ; Fri, 4 Aug 2017 01:59:11 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5464124234 for ; Fri, 4 Aug 2017 01:59:10 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id d17so4437773lfe.0 for ; Fri, 04 Aug 2017 01:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QhqxPd1bnqio1H3+sA6U+CHBXJwan/mSHxC6E6pE+KM=; b=fz4FindTx62yuqck8+pSekYD6DQ3FBVXDeLLetFDugfuFHajuKFpygQ5aw6nTBSO8I mNb4QiNxI/4my020ZQv9wF36mWfKBHlrlWdexWUYXlcAYrkzfZOBz3aJ20koTT+Z8Mtk EekwcbICErTTLF/q3dM7OYbjRIkMcd9+MyuWPYIulIHIKqWjZOrx8/UEZeDymp7AwNem bOyJnhVv4y1is4BYzy0tNkXFH6srvRLojh54jfNeI/Snd3b9khCx4Qz3ccEVx8lXVwly hSltVPT34S8kNjs0yZjSvkk4Xuox3U36qaMmLIMoNFpyoZ5sj71FQyYq3IUSuCre1ihT uKrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QhqxPd1bnqio1H3+sA6U+CHBXJwan/mSHxC6E6pE+KM=; b=YKPZHTfeXH7AlOctq3FoLkBrEIN8FV9rqNrkATZpD2afrqB9Q5DDsMY0hhx30XcdVC XE0wfO+iV11OCCI9FUENJfo9/PcHBWMEdLDnOZoiUya7M9siTlM+XgQ99qPtjc8LHwUS 2dMAtU+y+A9I+vHRpC4eJjSWSa4GGvKXzdOBzRqpi1pb9+9HykjIJ+ZChXvadIq7Yh0j YITlYjdNWuvnnEBoV4P5gbbmwZaMSjV0wn7rtm5YbrKQeVSJ5EbcZJUARTpFU75FJ9xE GsQ9TviT7G70afmizdONo+bbqdm9cC0+WLKQfasky9wrnyW1DRaxgwSitmE8yS8qt6WT F1Yw== X-Gm-Message-State: AIVw110SZ2mj95whijwHFJa73JnvGRcIgT/P1zs+jKHAvyLtZ2tQGtjY h8FGe+k2uQyLbs115SIbwQ== X-Received: by 10.46.83.25 with SMTP id h25mr701054ljb.46.1501837148773; Fri, 04 Aug 2017 01:59:08 -0700 (PDT) Received: from [79.138.207.118] (79.138.207.118.bredband.tre.se. [79.138.207.118]) by smtp.gmail.com with ESMTPSA id v10sm870006lja.29.2017.08.04.01.59.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 01:59:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (14G60) In-Reply-To: <8d9f92ea-6cea-1828-0f4b-3487240a81bd@bluepopcorn.net> Date: Fri, 4 Aug 2017 10:59:03 +0200 Cc: uta@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <106F8C76-E13A-4BAC-A5B4-CA2BA3C8ADF7@mnt.se> References: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> <8d9f92ea-6cea-1828-0f4b-3487240a81bd@bluepopcorn.net> To: Jim Fenton Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 08:59:14 -0000 Thx! Skickat fr=C3=A5n min iPhone > 3 aug. 2017 kl. 23:11 skrev Jim Fenton : >=20 > In response to Leif's request for specific text for the larger issues: >=20 >> On 7/31/17 4:02 PM, Jim Fenton wrote: >>=20 >> General comments: >>=20 >> All of the references are listed as normative, which I strongly suspect >> isn't really the case. Informative references need to be separated. >>=20 >> As the document notes, the reference for MTA-STS needs to be added. If >> it is a normative reference, this document will be held up until that is >> published. >=20 > I agree that the MTA-STS reference is informative. By my reading, the > following RFC references are also informative: > 3207, 3501, 3864, 7435, 7469, 7489 >=20 > But check me on those... >>=20 >> Section 3, what happens in the case of HTTPS delivery of reports if >> there is some problem with the certificate presented by the server? For >> mailto:, it explicitly states that the message should be sent in the >> clear if necessary, but that doesn't seem to be the case with https:. >=20 > Section 3, third bullet: >=20 > o In the case of "https", reports SHOULD be submitted via POST > ([RFC2818]) to the specified URI. Report submitters MAY ignore > certificate verification errors when submitting reports via https. >=20 >>=20 >> Section 4.3.2.1, dnssec-invalid: In this case, would the TLSRPT policy >> be found? >=20 > Maybe just note this situation; add the following text to this bullet: >=20 > Note that DNSSEC failures are likely to also affect the retrieval of the > TLSRPT record, so reports with this failure are likely to be rare in > practice. >=20 >>=20 >> Section 5.1, I don't like the idea of associating semantics with the >> filename of MIME parts. As it's written, use of the specified filename >> format is optional, so the recipient can't depend on it anyway. DMARC >> does this, and I didn't like it there either, but it's an informational >> document so this may not have gotten all the scrutiny this should as a >> standards-track document. >=20 > I suggest eliminating this requirement. >>=20 >> Section 5.3, I don't think it's a good idea to define and require new >> message header fields for this. This means that some of the >> general-purpose libraries for sending email messages can't be used. A >> better approach IMO would be to suggest the use of separate email >> addresses (e.g., reports@example.org or reports+client1@example.org for >> a service provider) in order to distinguish reports from other traffic. >=20 > I suggest eliminating this requirement. >>=20 >> IANA considerations: Consider adding a request to register _smtp-tlsrpt >> in the registry being created by draft-ietf-dnsop-attrleaf if that >> registry is created before this is published. >=20 > 6.6. _smtp-tlsrpt DNS Global Underscore Scoped Registry Entry >=20 > This document registers a new DNS name in the "DNS Global Underscore > Scoped Entry Registry" as follows: >=20 > Scoped Entry: _smtp-tlsrpt > Applicable protocol: SMTP > Status: standard > Author/Change controller: IETF > Specification document(s): This document >=20 > Note that this registry is created by the publication of > draft-ietf-dnsop-attrleaf. If this document precedes it in publication, > the entry is requested to be included in the registry at its creation. >>=20 >> Section 7, Reports as DDoS: The discussion revolves around the fact >> that, unlike DMARC, there isn't a third party involved in a DMARC report >> so it isn't necessary to validate delegation. I'm not sure this >> completely alleviates the DDoS risk, though: it's equally possible for >> malicious second parties to overload the receiver with reports, or for >> malicious parties to look around for TLSRPT policies with mailto: >> addresses and just spam them. It might be good to acknowledge that >> possibility here. Also, the suggestion of sending the messages daily for >> 0000-2400 UTC (section 4.1) does not scale well, and may be a DDoS in >> itself. >=20 > Section 4.1: >=20 > The report SHOULD cover a full day (24 hours). In order to avoid > congestion caused by synchronized transmission and receipt of reports, > report senders SHOULD choose an arbitrary time to send their reports, > either individually or as a group. The transmission time MAY be > determined, for example, by hashing the reporting domain name, taking > the result modulo 1440, and sending reports at that many minutes past > midnight UTC each day. >=20 > In Section 7: (original text is OK here too if you prefer, but suggest > including the "More broadly" sentence) >=20 > Reports as DDoS: TLSRPT allows specifying destinations for reports that > are outside the authority of the Policy Domain, which allows domains to > delegate processing of reports to a partner organization. However, an > attacker who controls a Policy Domain DNS could also use this mechanism > to direct the reports to an unwitting victim, flooding that victim with > excessive reports. More broadly, the publication of a reporting email > address or URI presents the opportunity for the addresses to be > harvested and used as the target of a DoS or DDoS attack. DMARC > [RFC7489] defines a solution for verifying delegation to avoid such > attacks, which is an effective countermeasure for innocent third-party > senders of reports, but TLSRPT has less need for a verification > mechanism because it would require the attacker to induce the innocent > third party to send mail to the attacker. >=20 >=20 >>=20 >> Section 7, additional consideration: The "untrusted content" >> consideration talks about malicious code, but attackers could also send >> counterfeit reports that look real in an effort to confuse the report >> recipient. Should valid DKIM signatures from the reporting domain be >> required on TLSRPT messages? >=20 > Add to Section 7: >=20 > Deceptive reports: TLSRPT supports the processing of reports from > arbitrary sources. As such, the data in the reports may be incorrect or > even intentionally deceptive. Report recipients need to be aware of and > prepared to handle this situation. >=20 > Add to bullet 4 of Section 3: >=20 > Reports sent via SMTP MUST contain a valid DKIM [RFC6376] signature by > the reporting domain. Reports lacking such a signature MUST be ignored > by the recipient. >=20 > (add normative reference to RFC6376) >=20 > (note that we still have a problem authenticating https reports, unless > client-authenticated TLS is required, which would be an onerous > requirement). >=20 >=20 > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta From nobody Mon Aug 7 13:53:31 2017 Return-Path: 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 4C5E5132396 for ; Mon, 7 Aug 2017 13:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com 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 7bviglV4nkT6 for ; Mon, 7 Aug 2017 13:53:28 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B0813238C for ; Mon, 7 Aug 2017 13:53:27 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id o85so6783310lff.3 for ; Mon, 07 Aug 2017 13:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=FifkpyHtL6F5Rs+twJGRVTjd9ed5P+gkjaf2vAjjA0Y=; b=UyARg6y5s93tNasdLcHuyT4pAprRFxoJ1pcSHz0SKo4e23SbVlVm2ECFqnxxHeqcZl QGuzhFFtUx8dxaFlv63RZlD1TkWpKVUeduGjf5ytfy2o4igrIB/g9nJvLgnHMfm5zhJ/ z/RaVCvE0CuYFEhPW0X5qctHs/cD76iWmTuNgtUcs+tHMPnDRm64wN53sCTTDS7w6V9e DcDWqNYtO6BvsBHsobFEGYiiRAeQorvN7aDmC2z5g4USYf5IIysy5LwW1KR4hrdWqj4U 9GWcdCPEH/6dDVdAOHFu1JuGd/+QBHt+HBqePKNLd/tRdZ3OlGaezy/K3WzuB4vjWn1F KiDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FifkpyHtL6F5Rs+twJGRVTjd9ed5P+gkjaf2vAjjA0Y=; b=CCr98bZijrWUBTxhMh4EdX0zDRkUNqAWWPzLnZb9xDQxtCSeP/XwMgcqkdBH+LV1/I +gmOT6/c39t30+ZKbcrSyAPSn3R7fay7/UQg2cu7W/FJ8WOp0pmhnXX4npI0bIX40jk1 KD1XfAyN6q0ibNbPDdTm/GTJeCuGx0pRfhEMlb/GvrqmK9/n7GAE4yHYpp1+EsdQejC0 rn2HfV5+IDvLoJd39UIugzx+0g2zR1w1//EUFWDGkgfakLoKIs9B/Wy8q7TyUFjppofr ZjQfxxpypq+kMtijz+eTx/4O39zFnMh5kKQhOiKAbqD5rDHJEq+leCkUhbOnFC3rpsPs m1UA== X-Gm-Message-State: AHYfb5g5JnMnQtDDpuLrfzq7wySTOpxT9SU+468Zyu/URVY3XLqNSdA5 DwaGG57g9MFfXP0FngXwhQ== X-Received: by 10.46.2.72 with SMTP id 69mr590198ljc.113.1502139205117; Mon, 07 Aug 2017 13:53:25 -0700 (PDT) Received: from [10.0.0.129] (h-155-4-129-189.NA.cust.bahnhof.se. [155.4.129.189]) by smtp.gmail.com with ESMTPSA id g133sm764980lfe.1.2017.08.07.13.53.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 13:53:24 -0700 (PDT) To: uta@ietf.org References: <74C79FFC-FA64-4226-ACA7-72A85E426B06@bangj.com> From: Leif Johansson Message-ID: Date: Mon, 7 Aug 2017 22:53:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <74C79FFC-FA64-4226-ACA7-72A85E426B06@bangj.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] consensus call on K/V vs JSON X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 20:53:30 -0000 >> We had a (less than spirited) discussion in Praha about the K/V vs JSON. >> >> The situation is that of the active participants that are also >> implementors one (postfix - Victor) has said that he does not believe >> that postfix will ship with a standard JSON-based implementation but >> that this doesn't preclude third-party plugins. >> >> The other major implementor who is also an active participant (google) >> has stated that they have a JSON implementation but that they are >> also eager to close this issue. One more implementor (Chris) has stated >> no preference but also said that his (native) JSON parser is somewhat >> smaller than his K/V one. >> >> Based on this and falling back to the IETF WG process as chair I would >> conclude that there isn't enough consensus to make a change and that >> we are staying with JSON. >> >> I would prefer to have more opinions (implementors in particular) but >> we are also going to get past this. In particular I would like to hear >> from implementors who (like Victor) have a problem living with either >> choice. I'm calling this in favor of K/V over JSON. A significant number of implementors of SMTP came forward to support K/V over JSON and that is a clear indication of (rough) consensus. The authors should feel encouraged to submit a new version asap so we can move this document close to WGLC Cheers Leif From nobody Mon Aug 7 14:55:26 2017 Return-Path: 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 258661243F6 for ; Mon, 7 Aug 2017 14:55:24 -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] 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 wq3Np7e41vqJ for ; Mon, 7 Aug 2017 14:55:22 -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 D77E31200F3 for ; Mon, 7 Aug 2017 14:55:21 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4EABD7A3309; Mon, 7 Aug 2017 21:55:20 +0000 (UTC) Date: Mon, 7 Aug 2017 21:55:20 +0000 From: Viktor Dukhovni To: uta@ietf.org Message-ID: <20170807215520.GM8146@mournblade.imrryr.org> Reply-To: uta@ietf.org References: <149874228049.6468.6647983832951662733@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <149874228049.6468.6647983832951662733@ietfa.amsl.com> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 21:55:24 -0000 I've tried to explain a number of times that policy in STS is problematic. This is another attempt. First what I believe to be the requirements: 1. We need to provide a means for a domain to transition from having an STS policy to not having an STS policy. 2. The transition process should not look like failure to obtain the policy, generating warnings in the logs that don't look different from an active attack. 3. It should be possible to remove policy in a timely manner. We have two signalling methods understood by STS-capable clients: A. The DNS TXT record which triggers a policy refresh when different from the previously observed value. B. The STS policy obtained via WebPKI-authenticated HTTPS. Based on the requirements, it should be possible to construct a combination of the TXT record and STS policy that have the following semantics: I. The STS policy causes clients to flush the existing cached entry, thereby enabling "clean" timely policy removal. Clients that do policy refresh in the background may still send a few messages based on previously cached policy, but should have current policy by the time any deferred messages are retried. II. The requisite TXT record will cause a refresh of existing cached policies, but will avoid new policy requests if the client does not yet have a cached policy for the destination domain. This avoids a state in which clients constantly look for a new policy after removing the current policy. To this end I propose the following design refinement. a. In the STS policy a value of 0 for max_age signals policy removal. b. In the STS DNS TXT record, an empty "id" value implies that no new policy is expected. Just as with other changes in the id value an empty id must also trigger refresh of cached policies, but must not trigger attempts to load new policies. The process for clean policy removal is then: i. Publish a new policy with max_age=0, check that all HTTPS servers have the new policy. ii. Publish an empty value for the id in the TXT record. iii. After the expiration of all previous policies (time of publication + non-zero "max_age"), delete the empty id TXT record. The client state is then one of the following: 1. No policy in the cache When seeing empty id TXT do nothing, just as with NXDOMAIN or NODATA 2. A policy in the cache with max_age=0 and an expiration time derived from the DNS TTL of the non-empty id TXT record that was observed at the time of policy refresh. Such policies do not enforce TLS or send reports. When seeing empty id TXT, NXDOMAIN or NODATA, flush such a cached policy. If instead (before an empty or non-existent TXT record is seen) a new policy appears with max_age > 0, cache that. 3. A policy in the cache with max_age > 0 and non-empty TXT id. Enforce TLS and/or send reports. If a new policy with max_age=0 is seen along with a non empty id in the TXT, cache that for the DNS TTL of the TXT record. When an empty TXT id is seen fetch the new policy, it will typically have max_age=0, but otherwise is treated just as any other policy. 4. A policy in the cache with max_age > 0, and an empty TXT id. Treat as any other policy until a refresh results in max_age=0. At that time, if the TXT is empty or missing flush the policy without further caching. The basic idea is that an empty TXT tells existing caches to update, but does not elicit fresh cache entries. While a cache entry with "max_age=0", waits for the TXT record to become empty or deleted, so as to avoid policy refresh on every delivery while the TXT id remains non-empty. The expiration time of the "max_age=0" cache entry is based on the DNS TTL of the observed non-empty TXT id. -- Viktor. From nobody Tue Aug 8 05:58:10 2017 Return-Path: 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 4CFB11321BF for ; Tue, 8 Aug 2017 05:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 HmcCqvDwpRkU for ; Tue, 8 Aug 2017 05:58:06 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE91E129ADA for ; Tue, 8 Aug 2017 05:58:05 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id u133so12797937vke.3 for ; Tue, 08 Aug 2017 05:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=CdJ8PVeDSR1fTDLn45Y4nIqxNqByRBjUb89pNKhIcKI=; b=jk6TXOL4HSWaqP3x3AbUcQ7VtsJ48XzsZd1GiysITdZZ7O9c8/NFLVHcrMn79M+tTF A5XRBweJEW0x8Y7T7JsX0SQnxlx4m6T0bYst8PANzIh5bgAjP+aLK1u5K+SgIq/rSfTa UuoOYOZPnQH00FUF3ZJs7GL/+X6NVQ4pSGSeSUxTwe06JCzmuzzCmZ8BGRzwXipn3I1b kEtU/pFgr6C2w7pLLgDvds9S+TFIvKl0R1r60aEa2J5A6Ghh/E1HgO0FAE3rEd2sFYiC YxmUGD8f4xIkWZW+EFitjXmoqFl84jZL93zQlyOyNO/5K7B/AZJjS+iXJkkmNc9xEfuG eeXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=CdJ8PVeDSR1fTDLn45Y4nIqxNqByRBjUb89pNKhIcKI=; b=SKhVIw2vC3Lm3Re9CcceeBGDjXoNxg9JPVbd5mLE+L2nzBstldQIYnpBcvMoQsAKBK v/7Pcx8cdAa+D2wNACcS9mAlobnCZe9+4+Mr9AxPD33lepiYOIvDnckVjfsPpM41Ek+s 4WCDnb3Crot9hasBB+WozCKWROsFAAKgaQ2AeejI8k3N1aW5M1f490G7AZiFiFYimPdj q7/OtALqNrzs4UTlyHeB9OufC1sLS6L4drNEpJiWbdUwHtp/lvquiaLJVZliT4JHZMSH obC1J2CxC3xZAA/DqbDSJFrBmsXgePFha3VBmjpoa6uFvhE7NbtAiQ0RhXUa9vz2pFFv b5nw== X-Gm-Message-State: AHYfb5jq3gBsxJ9nCScKrSkO9a5lg0abgFAkEnRjqm8cQlafPHONcUbp ncedF4yjwXMDdLT/RKR4h7WGdagLDa64WCy5og== X-Received: by 10.31.234.195 with SMTP id i186mr2267099vkh.178.1502197084207; Tue, 08 Aug 2017 05:58:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.161.142 with HTTP; Tue, 8 Aug 2017 05:58:03 -0700 (PDT) In-Reply-To: <20170807215520.GM8146@mournblade.imrryr.org> References: <149874228049.6468.6647983832951662733@ietfa.amsl.com> <20170807215520.GM8146@mournblade.imrryr.org> From: Daniel Margolis Date: Tue, 8 Aug 2017 08:58:03 -0400 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c091528a026d605563d833a" Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 12:58:08 -0000 --94eb2c091528a026d605563d833a Content-Type: multipart/alternative; boundary="94eb2c09152897840405563d8382" --94eb2c09152897840405563d8382 Content-Type: text/plain; charset="UTF-8" Hi, Viktor, Thanks for the thorough writeup. A question about the "requirements" stated: 1. We need to provide a means for a domain to transition > from having an STS policy to not having an STS policy. > 2. The transition process should not look like failure to > obtain the policy, generating warnings in the logs that > don't look different from an active attack. > 3. It should be possible to remove policy in a timely manner. What do you mean by "remove" and "not having" a policy? What specific behavior do you want from senders? E.g. senders will stop a) performing any kind of certificate validation checks per the policy? b) making reports based on those checks? c) any change in delivery behavior based on those checks? d) maintaining a policy cache entry for the recipient domain? The reason I ask is that some of these are achievable today, and some of them are achievable with more minimal modifications than the flow you describe. Thanks. On Mon, Aug 7, 2017 at 5:55 PM, Viktor Dukhovni wrote: > I've tried to explain a number of times that policy in STS is > problematic. This is another attempt. First what I believe > to be the requirements: > > 1. We need to provide a means for a domain to transition > from having an STS policy to not having an STS policy. > > 2. The transition process should not look like failure to > obtain the policy, generating warnings in the logs that > don't look different from an active attack. > > 3. It should be possible to remove policy in a timely manner. > > We have two signalling methods understood by STS-capable clients: > > A. The DNS TXT record which triggers a policy refresh when > different from the previously observed value. > > B. The STS policy obtained via WebPKI-authenticated HTTPS. > > Based on the requirements, it should be possible to construct a > combination of the TXT record and STS policy that have the > following semantics: > > I. The STS policy causes clients to flush the existing cached > entry, thereby enabling "clean" timely policy removal. Clients > that do policy refresh in the background may still send a few > messages based on previously cached policy, but should have > current policy by the time any deferred messages are retried. > > II. The requisite TXT record will cause a refresh of existing > cached policies, but will avoid new policy requests if the > client does not yet have a cached policy for the destination > domain. This avoids a state in which clients constantly look > for a new policy after removing the current policy. > > To this end I propose the following design refinement. > > a. In the STS policy a value of 0 for max_age signals policy > removal. > > b. In the STS DNS TXT record, an empty "id" value implies that no > new policy is expected. Just as with other changes in the id > value an empty id must also trigger refresh of cached policies, > but must not trigger attempts to load new policies. > > The process for clean policy removal is then: > > i. Publish a new policy with max_age=0, check that all HTTPS > servers have the new policy. > ii. Publish an empty value for the id in the TXT record. > iii. After the expiration of all previous policies (time > of publication + non-zero "max_age"), delete the > empty id TXT record. > > The client state is then one of the following: > > 1. No policy in the cache > > When seeing empty id TXT do nothing, just as with NXDOMAIN > or NODATA > > 2. A policy in the cache with max_age=0 and an expiration > time derived from the DNS TTL of the non-empty id TXT > record that was observed at the time of policy refresh. > > Such policies do not enforce TLS or send reports. > > When seeing empty id TXT, NXDOMAIN or NODATA, flush such > a cached policy. > > If instead (before an empty or non-existent TXT record is > seen) a new policy appears with max_age > 0, cache that. > > 3. A policy in the cache with max_age > 0 and non-empty TXT id. > > Enforce TLS and/or send reports. > > If a new policy with max_age=0 is seen along with a non > empty id in the TXT, cache that for the DNS TTL of the TXT > record. > > When an empty TXT id is seen fetch the new policy, it will > typically have max_age=0, but otherwise is treated just as > any other policy. > > 4. A policy in the cache with max_age > 0, and an empty TXT id. > > Treat as any other policy until a refresh results in max_age=0. > At that time, if the TXT is empty or missing flush the policy > without further caching. > > The basic idea is that an empty TXT tells existing caches to update, > but does not elicit fresh cache entries. While a cache entry with > "max_age=0", waits for the TXT record to become empty or deleted, > so as to avoid policy refresh on every delivery while the TXT id > remains non-empty. The expiration time of the "max_age=0" cache > entry is based on the DNS TTL of the observed non-empty TXT id. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --94eb2c09152897840405563d8382 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Viktor,=C2=A0

Thanks for the thorou= gh writeup. A question about the "requirements" stated:

1.=C2=A0 We need to provide a means for a domain to tran= sition
=C2=A0 =C2=A0 from having= an STS policy to not having an STS policy.
2.=C2=A0 The transition process shou= ld not look like failure to
=C2= =A0 =C2=A0 obtain the policy, generating warnings in the logs that
=C2=A0 =C2=A0 don't look different f= rom an active attack.
3.=C2=A0 It should be possible to remove policy in a timel= y manner.

What do you mean by "= remove" and "not having" a policy? What specific behavior do= you want from senders?

E.g. senders will stop

a) performing any kind of certificate validation chec= ks per the policy?
b) making reports based on those checks?
=
c) any change in delivery behavior based on those checks?
d)= maintaining a policy cache entry for the recipient domain?
=C2= =A0
The reason I ask is that some of these are achievable tod= ay, and some of them are achievable with more minimal modifications than th= e flow you describe.=C2=A0

Thanks.=C2=A0

On Mon, Aug 7, = 2017 at 5:55 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
I've tried to explain a num= ber of times that policy in STS is
problematic.=C2=A0 This is another attempt.=C2=A0 First what I believe
to be the requirements:

1.=C2=A0 We need to provide a means for a domain to transition
=C2=A0 =C2=A0 from having an STS policy to not having an STS policy.

2.=C2=A0 The transition process should not look like failure to
=C2=A0 =C2=A0 obtain the policy, generating warnings in the logs that
=C2=A0 =C2=A0 don't look different from an active attack.

3.=C2=A0 It should be possible to remove policy in a timely manner.

We have two signalling methods understood by STS-capable clients:

A.=C2=A0 The DNS TXT record which triggers a policy refresh when
=C2=A0 =C2=A0 different from the previously observed value.

B.=C2=A0 The STS policy obtained via WebPKI-authenticated HTTPS.

Based on the requirements, it should be possible to construct a
combination of the TXT record and STS policy that have the
following semantics:

I.=C2=A0 The STS policy causes clients to flush the existing cached
=C2=A0 =C2=A0 entry, thereby enabling "clean" timely policy remov= al.=C2=A0 Clients
=C2=A0 =C2=A0 that do policy refresh in the background may still send a few=
=C2=A0 =C2=A0 messages based on previously cached policy, but should have =C2=A0 =C2=A0 current policy by the time any deferred messages are retried.=

II. The requisite TXT record will cause a refresh of existing
=C2=A0 =C2=A0 cached policies, but will avoid new policy requests if the =C2=A0 =C2=A0 client does not yet have a cached policy for the destination<= br> =C2=A0 =C2=A0 domain.=C2=A0 This avoids a state in which clients constantly= look
=C2=A0 =C2=A0 for a new policy after removing the current policy.

To this end I propose the following design refinement.

a.=C2=A0 In the STS policy a value of 0 for max_age signals policy
=C2=A0 =C2=A0 removal.

b.=C2=A0 In the STS DNS TXT record, an empty "id" value implies t= hat no
=C2=A0 =C2=A0 new policy is expected.=C2=A0 Just as with other changes in t= he id
=C2=A0 =C2=A0 value an empty id must also trigger refresh of cached policie= s,
=C2=A0 =C2=A0 but must not trigger attempts to load new policies.

The process for clean policy removal is then:

=C2=A0 =C2=A0 i.=C2=A0 =C2=A0Publish a new policy with max_age=3D0, check t= hat all HTTPS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0servers have the new policy.
=C2=A0 =C2=A0 ii.=C2=A0 Publish an empty value for the id in the TXT record= .
=C2=A0 =C2=A0 iii. After the expiration of all previous policies (time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of publication + non-zero "max_age&q= uot;), delete the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0empty id TXT record.

The client state is then one of the following:

=C2=A0 =C2=A0 1.=C2=A0 No policy in the cache

=C2=A0 =C2=A0 =C2=A0 =C2=A0 When seeing empty id TXT do nothing, just as wi= th NXDOMAIN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 or NODATA

=C2=A0 =C2=A0 2.=C2=A0 A policy in the cache with max_age=3D0 and an expira= tion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 time derived from the DNS TTL of the non-empty = id TXT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 record that was observed at the time of policy = refresh.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Such policies do not enforce TLS or send report= s.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 When seeing empty id TXT, NXDOMAIN or NODATA, f= lush such
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a cached policy.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If instead (before an empty or non-existent TXT= record is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 seen) a new policy appears with max_age > 0,= cache that.

=C2=A0 =C2=A0 3.=C2=A0 A policy in the cache with max_age > 0 and non-em= pty TXT id.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Enforce TLS and/or send reports.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If a new policy with max_age=3D0 is seen along = with a non
=C2=A0 =C2=A0 =C2=A0 =C2=A0 empty id in the TXT, cache that for the DNS TTL= of the TXT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 record.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 When an empty TXT id is seen fetch the new poli= cy, it will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 typically have max_age=3D0, but otherwise is tr= eated just as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 any other policy.

=C2=A0 =C2=A0 4.=C2=A0 A policy in the cache with max_age > 0, and an em= pty TXT id.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Treat as any other policy until a refresh resul= ts in max_age=3D0.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 At that time, if the TXT is empty or missing fl= ush the policy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 without further caching.

The basic idea is that an empty TXT tells existing caches to update,
but does not elicit fresh cache entries.=C2=A0 While a cache entry with
"max_age=3D0", waits for the TXT record to become empty or delete= d,
so as to avoid policy refresh on every delivery while the TXT id
remains non-empty.=C2=A0 The expiration time of the "max_age=3D0"= cache
entry is based on the DNS TTL of the observed non-empty TXT id.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--94eb2c09152897840405563d8382-- --94eb2c091528a026d605563d833a Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMK8x525biWylzaTdKMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTE4NDIxNVoXDTE3MTAx ODE4NDIxNVowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwhqodpCO7YNSzRIz9ahzJEd2Fmnm1g9pYE2GUs5S8c6Jh JLiZkF4+kTvQVptWmuoWxWqgeIJcqZKozIYoNl06ecCUcCSo/61I+QeD061Vfl9SemzDYrK9IJ5i fsx9sXOD+c20D4Lef7F0wC9azTDs36EwgEDBcLKUef5/Y/n3TDPth8kllj0cKBitt1MC2Il95W7a MyESYucDAH7gSG/dIOGNUaIh+vLLMtRvDQVRfveOum2uUf52bF3rywDJ32dvPCDVsRJHWuhBUfaP shyNiw4d/NzDjMdc504m+GABUpF9r8203gWdhHMxPyeDIzeV7wujWEZ19c0jOcFwdpupAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFB8LoXS3E+322ae/sSMWqyi4zefEMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCeAGD8kMXY iuahwdAzZ8iUfQSAM9M8Q1JPN+jXR6gcJXagqqdjHep1KcrhYx4xvhAUurzdH0AtzjdHuS1OKOj4 OYaMUtjuSYQ6SfFdpkM6K/Ih9IklpIV4BynT4/8D6WROz5f+sQGMf22geoCWbRUsBZv7GgMIWg+1 w6F7FiSFR7NKTBRZS4y/SHv0LCtC12JHyyVQrbxrjXy2tIcrhKC0DhToxe4s9aIA/kauGUSGXyLa U55gCBKpReCTtn1b4aQIwJp9aj0wDzfqs88hyIkWKDUMW7VP+Wdk9y6qUpKwbSN9pIu3m3UmjZC7 6923PlCyPXBkAIcLrTExf7wVn9lpMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBkfu9aOmL7L4Dj Gw3BfDwWFnBQd0PYQo2kznMFlIIGJjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MDgxMjU4MDRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAGQGBI9H9qpF1NtfSVhZa3FSSNarfTgEJ Mv2o8IN70bWHUEOjsd3GUmLJViJQjZ+oMZr+boG5YslKY0jlUFKnhktTsk5D6MTHVyZx7l392DPV UvazzH/9ETgRM5W2vz54QI++dSgK1rcmG1AP40WV/wdjvOYn8ld0f8QA300MeqARqfkksp7nG2KB X0uyJYhaExe9gE/Beq7Lc7kwq67NV2CNHqhaAP7kvMpU1eMB5c643KxBvyNVYUuhUAwQJhmdWDE3 5bZXkDx9S02xbBtXSH4/fQ67sryJOtprLopzlNlVfT5qcx9yNPNNzKOklYJg+fsPmHyPoP4hoLVy MWzagA== --94eb2c091528a026d605563d833a-- From nobody Tue Aug 8 07:30:27 2017 Return-Path: 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 585EA1323C0 for ; Tue, 8 Aug 2017 07:30:25 -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] 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 bBWAsXLhRW-f for ; Tue, 8 Aug 2017 07:30:23 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4191323BC for ; Tue, 8 Aug 2017 07:30:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id C4A8E97A82; Tue, 8 Aug 2017 17:30:20 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id NF_BgGore4vd; Tue, 8 Aug 2017 17:30:20 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 889452313; Tue, 8 Aug 2017 17:30:18 +0300 (EEST) Date: Tue, 8 Aug 2017 17:30:18 +0300 From: Ilari Liusvaara To: Daniel Margolis Cc: uta@ietf.org Message-ID: <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> References: <149874228049.6468.6647983832951662733@ietfa.amsl.com> <20170807215520.GM8146@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 14:30:25 -0000 On Tue, Aug 08, 2017 at 08:58:03AM -0400, Daniel Margolis wrote: > Hi, Viktor, > > Thanks for the thorough writeup. A question about the "requirements" stated: > > 1. We need to provide a means for a domain to transition > > from having an STS policy to not having an STS policy. > > 2. The transition process should not look like failure to > > obtain the policy, generating warnings in the logs that > > don't look different from an active attack. > > 3. It should be possible to remove policy in a timely manner. > > > What do you mean by "remove" and "not having" a policy? What specific > behavior do you want from senders? > > E.g. senders will stop > > a) performing any kind of certificate validation checks per the policy? > b) making reports based on those checks? > c) any change in delivery behavior based on those checks? > d) maintaining a policy cache entry for the recipient domain? The way I understand the request, it is full clear of policy, that is: - The existing policy is (immediately) invalidated. - The policy cache entry for the recipient is deleted. And since there is no policy anymore: - All certificate validation per the policy ceases. - All reporting per the policy ceases. - There is no difference in delivery behavior (for future deliveries) from STS policy having never existed. This is similar behavior with what happens with HSTS if valid HSTS header with max-age=0 is ever received: The HSTS policy is instantly deleted and the name reverts to non-HSTS operation (http:// connections work and certificate errors can be clicked through). -Ilari From nobody Tue Aug 8 08:12:04 2017 Return-Path: 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 EF4851323AC for ; Tue, 8 Aug 2017 08:12:02 -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] 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 YLphpsvst8LF for ; Tue, 8 Aug 2017 08:12:01 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 51B371323B2 for ; Tue, 8 Aug 2017 08:11:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 4198E97A39; Tue, 8 Aug 2017 18:11:57 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id BU_SVQIz2kcD; Tue, 8 Aug 2017 18:11:57 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 052232313; Tue, 8 Aug 2017 18:11:54 +0300 (EEST) Date: Tue, 8 Aug 2017 18:11:54 +0300 From: Ilari Liusvaara To: Daniel Margolis Cc: uta@ietf.org Message-ID: <20170808151154.faoxa36jo64f4rxp@LK-Perkele-VII> References: <149874228049.6468.6647983832951662733@ietfa.amsl.com> <20170807215520.GM8146@mournblade.imrryr.org> <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 15:12:03 -0000 On Tue, Aug 08, 2017 at 05:30:18PM +0300, Ilari Liusvaara wrote: > On Tue, Aug 08, 2017 at 08:58:03AM -0400, Daniel Margolis wrote: Also, reading the specification, there looks to be some issues with the use of PKIX: 1) CN-IDs have long been deprecated. RFC 6125 is pretty clear that: - If SAN contains any recoginized identifier type (which here does include DNS-ID), then CN-ID MUST be ignored. So union is just wrong. - CN-ID is for backward compatiblity only, which does not apply here, since the specification is new -> CN-ID is not to be used at all. 2) Does mx pattern '.example.net' match host 'example.net'? The text is not explicitly say if it does or does not (the example code in appendix does not seem to consider those two to match). 3) The wildcards in PKIX are not recursive. Thus, certificate with only SAN '*.example.net' can not match 'foo.bar.example.net'. Yet, tracing the code in appendix, it appears that the code considers this to match. -Ilari From nobody Tue Aug 8 10:20:07 2017 Return-Path: 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 412B91324A4 for ; Tue, 8 Aug 2017 10:20:06 -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] 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 7rJjrA0drTDW for ; Tue, 8 Aug 2017 10:20:04 -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 62433132043 for ; Tue, 8 Aug 2017 10:20:04 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D79F17A3309; Tue, 8 Aug 2017 17:20:02 +0000 (UTC) Date: Tue, 8 Aug 2017 17:20:02 +0000 From: Viktor Dukhovni To: uta@ietf.org Message-ID: <20170808172002.GN8146@mournblade.imrryr.org> Reply-To: uta@ietf.org References: <149874228049.6468.6647983832951662733@ietfa.amsl.com> <20170807215520.GM8146@mournblade.imrryr.org> <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 17:20:06 -0000 On Tue, Aug 08, 2017 at 05:30:18PM +0300, Ilari Liusvaara wrote: > > Thanks for the thorough writeup. A question about the "requirements" stated: > > > > > 3. It should be possible to remove policy in a timely manner. > > > > What do you mean by "remove" and "not having" a policy? What specific > > behavior do you want from senders? > > The way I understand the request, it is full clear of policy, that is: > > - The existing policy is (immediately) invalidated. > - The policy cache entry for the recipient is deleted. > > And since there is no policy anymore: > > - All certificate validation per the policy ceases. > - All reporting per the policy ceases. > - There is no difference in delivery behavior (for future deliveries) > from STS policy having never existed. > > This is similar behavior with what happens with HSTS if valid HSTS > header with max-age=0 is ever received: The HSTS policy is instantly > deleted and the name reverts to non-HSTS operation (http:// connections > work and certificate errors can be clicked through). Correct. Full removal of any prior evidence of SMTP STS Policy, but because SMTP STS has both a DNS TXT record and a policy obtained via HTTPS, the process of policy removal involves more steps on both sides. For example, policy removal should not result in an intermediate state where the client is constantly refetching the max_age=0 STS policy (because the TXT record is still visible, but the cache has been flushed). I had considered using NXDOMAIN/NODATA, instead of an empty id, to signal policy removal (provided the other end returns max_age = 0), but this leads to a problem, because some DNS libraries (e.g. libresolv) make it difficult to obtain the TTL of a negative reply. With no TTL for NXDOMAIN/NODATA it is not clear how often one should attempt to poll for "max_age = 0", and with TXT record removed, it can no longer trigger early refresh. -- Viktor. [ It is unfortunate that DNS NXDOMAIN/NODATA is often considered a lookup error, whereas it is actually a lookup success, that yields an empty result. DNS APIs should expose negative TTLs, but not all do. ] From nobody Tue Aug 8 11:47:08 2017 Return-Path: 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 8BE321329D1 for ; Tue, 8 Aug 2017 11:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Kz61OndFLHYB for ; Tue, 8 Aug 2017 11:47:05 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35211329BE for ; Tue, 8 Aug 2017 11:47:03 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id g71so17023883ioe.5 for ; Tue, 08 Aug 2017 11:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z+Ir7LvKmMvaOtuFJr0kAALrkzh5ryQ/TdhATRGa7us=; b=V6ZSQOKHxa5/DOqjqa/bo3FfuN2u25jXrry82VJZ4HXwzDJUc1v1wljnir8Y72B+4T wcff0otJXK9t7gaDAdQBpN1cKIeFG9NW+noLW1owUptZcChNFP8ZvL+Ep37YYmqWkYgg ahb/qcDaIlZwUXX7KPEtcIyuu47pbX02960blw7Ag6zf7gSWhiEZGKymLkn5Lp3RXMGb bGKxteMyM0DrgCHJUDccVPpjZWwdygFsuPROAM0gID/ziJkEQE7+U7vDDjQz6Hn6Xv1C PhDHR3JpPpVxSC4+RUltcQ0kVqHrCyKUZ1srzc+I/JwtF2o4r7OaAhZsrzXvRw+DBH4L NeiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z+Ir7LvKmMvaOtuFJr0kAALrkzh5ryQ/TdhATRGa7us=; b=Ipp5RGuM2FligjqfrzPhROeD1LeSsmt3Ib3ZdezxghRk1pIMslnuQmXqF/3NdnBlBP ZSud8gBRrXDjq0khZx/2MkA+Es0wZqZ7EDyCVCPDef7yefCxS+pBNQfHoQ67nt9gyLaQ IPsli4BbEFUvZ25ItDvPObWLRJ/wugXBDvNvIY+rhOL+54xs/OWe52sJWMxbocujSKaY PcRHb90Sw5PH6KfMAcDxsx85VaAWjaKoyQvjersfAW7mwN8R92jP3JoTefR0D67ClqhY xoAmZueDZZ711/yHgJAiBTyUAUP43v+ZX+P7UpCPniMWZ7Akc4AqHfUW0XyQVTQsV1LB RbZQ== X-Gm-Message-State: AHYfb5jCRsVxPVRv0DIY3R1DB7hlBtYU4mERtbXuA3kbTS9jtYdf+dIe sip0kTgMaryuN2uYBX3rMrxyLWqf41os X-Received: by 10.107.134.87 with SMTP id i84mr4392604iod.293.1502218022659; Tue, 08 Aug 2017 11:47:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.159 with HTTP; Tue, 8 Aug 2017 11:47:01 -0700 (PDT) In-Reply-To: <20170808151154.faoxa36jo64f4rxp@LK-Perkele-VII> References: <149874228049.6468.6647983832951662733@ietfa.amsl.com> <20170807215520.GM8146@mournblade.imrryr.org> <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> <20170808151154.faoxa36jo64f4rxp@LK-Perkele-VII> From: Daniel Margolis Date: Tue, 8 Aug 2017 11:47:01 -0700 Message-ID: To: Ilari Liusvaara Cc: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113f0b82a5110405564263a3" Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 18:47:07 -0000 --001a113f0b82a5110405564263a3 Content-Type: multipart/alternative; boundary="001a113f0b829e201d0556426359" --001a113f0b829e201d0556426359 Content-Type: text/plain; charset="UTF-8" Thanks for the comments. Inline: On Tue, Aug 8, 2017 at 8:11 AM, Ilari Liusvaara wrote: > On Tue, Aug 08, 2017 at 05:30:18PM +0300, Ilari Liusvaara wrote: > > On Tue, Aug 08, 2017 at 08:58:03AM -0400, Daniel Margolis wrote: > > Also, reading the specification, there looks to be some issues with > the use of PKIX: > > 1) CN-IDs have long been deprecated. RFC 6125 is pretty clear that: > > - If SAN contains any recoginized identifier type (which here does > include DNS-ID), then CN-ID MUST be ignored. So union is just wrong. > - CN-ID is for backward compatiblity only, which does not apply here, > since the specification is new -> CN-ID is not to be used at all. > I had thought I had specified to use only SAN if present, but apparently I didn't. Nonetheless, I thought it made sense to allow matching by CN-ID if no SAN is present. While this is a new specification, the certificates may be pre-existing. So you're definitely right on ignoring CN-ID if SAN is present, but I would err on the side of falling back to CN-ID. Does it make sense? > 2) Does mx pattern '.example.net' match host 'example.net'? The text > is not explicitly say if it does or does not (the example code in > appendix does not seem to consider those two to match). > Thanks. I filed issues on the github for this and the below. > > 3) The wildcards in PKIX are not recursive. Thus, certificate with only > SAN '*.example.net' can not match 'foo.bar.example.net'. Yet, tracing > the code in appendix, it appears that the code considers this to match. > > -Ilari > --001a113f0b829e201d0556426359 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the comments. Inline:

On Tue, Aug 8, 2017 at 8:11 AM, Ilari L= iusvaara <ilariliusvaara@welho.com> wrote:
On Tue, A= ug 08, 2017 at 05:30:18PM +0300, Ilari Liusvaara wrote:
> On Tue, Aug 08, 2017 at 08:58:03AM -0400, Daniel Margolis wrote:

Also, reading the specification, there looks to be some issues with<= br> the use of PKIX:

1) CN-IDs have long been deprecated. RFC 6125 is pretty clear that:

- If SAN contains any recoginized identifier type (which here does
=C2=A0 include DNS-ID), then CN-ID MUST be ignored. So union is just wrong.=
- CN-ID is for backward compatiblity only, which does not apply here,
=C2=A0 since the specification is new -> CN-ID is not to be used at all.=
=C2=A0
I had thought I had specified to use= only SAN if present, but apparently I didn't. Nonetheless, I thought i= t made sense to allow matching by CN-ID if no SAN is present. While this is= a new specification, the certificates may be pre-existing.=C2=A0
=

So you're definitely right on ignoring CN-ID if SAN= is present, but I would err on the side of falling back to CN-ID. Does it = make sense?
=C2=A0
2) Does mx pattern '.example.net' match host 'example.net'? The t= ext
is not explicitly say if it does or does not (the example code in
appendix does not seem to consider those two to match).

Thanks. I filed issues on the github for this and the belo= w.
=C2=A0

3) The wildcards in PKIX are not recursive. Thus, certificate with only
SAN '*.example.net' can not match 'foo.bar.example.net'. = Yet, tracing
the code in appendix, it appears that the code considers this to match.=C2= =A0


-Ilari

--001a113f0b829e201d0556426359-- --001a113f0b82a5110405564263a3 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMK8x525biWylzaTdKMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTE4NDIxNVoXDTE3MTAx ODE4NDIxNVowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwhqodpCO7YNSzRIz9ahzJEd2Fmnm1g9pYE2GUs5S8c6Jh JLiZkF4+kTvQVptWmuoWxWqgeIJcqZKozIYoNl06ecCUcCSo/61I+QeD061Vfl9SemzDYrK9IJ5i fsx9sXOD+c20D4Lef7F0wC9azTDs36EwgEDBcLKUef5/Y/n3TDPth8kllj0cKBitt1MC2Il95W7a MyESYucDAH7gSG/dIOGNUaIh+vLLMtRvDQVRfveOum2uUf52bF3rywDJ32dvPCDVsRJHWuhBUfaP shyNiw4d/NzDjMdc504m+GABUpF9r8203gWdhHMxPyeDIzeV7wujWEZ19c0jOcFwdpupAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFB8LoXS3E+322ae/sSMWqyi4zefEMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCeAGD8kMXY iuahwdAzZ8iUfQSAM9M8Q1JPN+jXR6gcJXagqqdjHep1KcrhYx4xvhAUurzdH0AtzjdHuS1OKOj4 OYaMUtjuSYQ6SfFdpkM6K/Ih9IklpIV4BynT4/8D6WROz5f+sQGMf22geoCWbRUsBZv7GgMIWg+1 w6F7FiSFR7NKTBRZS4y/SHv0LCtC12JHyyVQrbxrjXy2tIcrhKC0DhToxe4s9aIA/kauGUSGXyLa U55gCBKpReCTtn1b4aQIwJp9aj0wDzfqs88hyIkWKDUMW7VP+Wdk9y6qUpKwbSN9pIu3m3UmjZC7 6923PlCyPXBkAIcLrTExf7wVn9lpMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCC19+lbQwm+/YoS 91aJQ2UrmtI/VOQu4izX+5zQ9ZTlJTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MDgxODQ3MDNaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAcx27gr/s1AsFxXZS0x7KMEharzNwL2EE /SRFB12wySmhDmHRNdEd5Sk8pwrK1jVVQ+IYt8xLzvnO0IlxLJEhivxoedbtA1vHq+DKR+PzI8p5 NUuGlmll4t8qksZceNMy7Zjl9rbjlonXN2vFSZj7LbTHbWRMXDrlPiAzvzuSTxDYLRFNbdUob2O1 LCWe4nEB4bdVidVAObtZDTMn4WYlq1btxcvmkcsWr/LPhms0LbKx+by/rhG1JIfMCGXteXjnZcXz N2y1tn2tMCTVNIXBarLTCxiTd0e7FmpvWTALagtPvfoMDvLm8yaBCZApiTRT5rEoWtynDC+tZz6q J1RHDQ== --001a113f0b82a5110405564263a3-- From nobody Tue Aug 8 12:08:13 2017 Return-Path: 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 EC667132354 for ; Tue, 8 Aug 2017 12:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 2ls5_m1ZdiLA for ; Tue, 8 Aug 2017 12:08:08 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E0A813235F for ; Tue, 8 Aug 2017 12:08:07 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id m34so8719549iti.1 for ; Tue, 08 Aug 2017 12:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ElpUOoT/1k6ukUNJdip1cmS5QzPiyABEw0XcLm/2ojY=; b=oKp19oGMzQGhZ4FG/O73B2nTJP1us3b6GK9yuSUy0D+ixU813nz30d+QtgrMxTjMY8 nDkx8BxjCccVgyW3KAcLjWRZCCAefS9haU0E79qYhzV5ePuaJVadlNhe2Vj35agsiStY 03B1HMLuph/46D2YMJ0qXHxwDrbJDEgD2vIuAgbptwybmH/3lfFX0xI0bEw1lwvKse18 GMv3LR41XBZPNal4hfUgSpBerP09dYD2dPXxvcMq4mX4oY8rx2pL4o1Y0ibaw5Y0ym9/ PPvZZHRbfi8l3pXaL0/ernpaLP1nPWfNkW/TIA1muWxHQ72QsZjrHOz/O3zPgE1hDq+5 xkBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ElpUOoT/1k6ukUNJdip1cmS5QzPiyABEw0XcLm/2ojY=; b=HMNZYZWxzw2sKkdgnT8wRwP1KxZZuIrTpGyVJ/1cWcIv+ogGJzXI88MEdJzh3h4/BU OqoCoYyLXhgENoioCSklQPq5keS2VIJnb5KKoZBz+OsjHy0NFHXmD95vmYYX6jUzaTIk SLbL0oQNpAT5d8zqfae/9OMxOewMjE1ouC8fEhYqjvGyIxr5UZItn2quEnDRAUbhpKz+ r6QZZLWt2pHHnbe7qXkcBk4nqn8TWTWBFkUtgz+C55tj7WgrmAlKYkTNUzzTZykZFW2O sjmhyMKHrZruaPg2mepj8UTfP80XDwLkTscRcrS40pUfxYgOdDvvFFFmPk/AAh0Im7hm 6y7g== X-Gm-Message-State: AHYfb5gKsGA50UuCI538Fm48wtPxrHnhTpvRZRAVihY7ctFW7GuQxjOg JWlGG9BboWi67z5IJm9cATmMmQF3rfVwaMnVOw== X-Received: by 10.36.163.137 with SMTP id p131mr4754060ite.22.1502219286583; Tue, 08 Aug 2017 12:08:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.159 with HTTP; Tue, 8 Aug 2017 12:08:05 -0700 (PDT) In-Reply-To: <20170808172002.GN8146@mournblade.imrryr.org> References: <149874228049.6468.6647983832951662733@ietfa.amsl.com> <20170807215520.GM8146@mournblade.imrryr.org> <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> <20170808172002.GN8146@mournblade.imrryr.org> From: Daniel Margolis Date: Tue, 8 Aug 2017 12:08:05 -0700 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c112460fc889d055642ae92" Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 19:08:12 -0000 --94eb2c112460fc889d055642ae92 Content-Type: multipart/alternative; boundary="94eb2c112460f45d49055642ae1a" --94eb2c112460f45d49055642ae1a Content-Type: text/plain; charset="UTF-8" The reason I asked this question is, as I said, we can achieve some of the desired properties with less complexity. I'd like to break down the various implementation options and which of the "removal" properties they retain so we can make sure we choose the simplest option that satisfies the requirements (or understand what the extra complexity buys us). So forgive me for fleshing out slightly more, but I believe "removal" is comprised of roughly the following behaviors: A. MX/certificate changes don't affect mail delivery B. MX/certificate changes don't affect TLSRPT reporting (since a domain may wish to continue to use TLSRPT but stop using MTA-STS) C. Any resource impact on *senders to this domain* from doing MTA-STS validation is eliminated D. It is safe to remove the policy and TXT record (D), I believe, is invariant in all implementations: any hypothetical "removal" flow *will* involve serving the "removal" signal (whatever it is--a max_age=0 policy or anything else) until the last point in time the *old* policy was served + that policy's max_age. So (D) does not distinguish between different "removal" options. *Currently: *By setting "mode=report", you can achieve (A), but not (B). *Under the "max_age=0" proposal: *You can achieve (A), (B), and (C). *Alternatively: *If we had a "mode=none", you would achieve (A) and (B) but *not* (C), since senders would cache the "mode=none" policy until max_age has passed). I believe "mode=none" is simpler to implement and reason about, since it doesn't change the policy caching logic; it *only* changes the actual reporting and enforcing behavior. (Conversely, the "max_age=0" proposal may be simpler when viewed as changes only to the process that fetches and caches policies, since it does not involve any changes to policy use; that process simply purges the cached policy and calls it a day.) I also believe property (C) is unimportant, since senders who implement MTA-STS must be resilient (in the resource usage sense) to recipients who have live policies; they can't in any way depend on the recipient revoking a policy to keep the cost of policy validation or caching down. *Questions:* Is the "mode=none" proposal simpler or more complex than "max_age=0"? Is property (C) important? *tl;dr:* I'm good with policy removal, but "mode=none" seems a bit simpler to me (both in implementation and reasoning about its properties). Thoughts? On Tue, Aug 8, 2017 at 10:20 AM, Viktor Dukhovni wrote: > On Tue, Aug 08, 2017 at 05:30:18PM +0300, Ilari Liusvaara wrote: > > > > Thanks for the thorough writeup. A question about the "requirements" > stated: > > > > > > > 3. It should be possible to remove policy in a timely manner. > > > > > > What do you mean by "remove" and "not having" a policy? What specific > > > behavior do you want from senders? > > > > The way I understand the request, it is full clear of policy, that is: > > > > - The existing policy is (immediately) invalidated. > > - The policy cache entry for the recipient is deleted. > > > > And since there is no policy anymore: > > > > - All certificate validation per the policy ceases. > > - All reporting per the policy ceases. > > - There is no difference in delivery behavior (for future deliveries) > > from STS policy having never existed. > > > > This is similar behavior with what happens with HSTS if valid HSTS > > header with max-age=0 is ever received: The HSTS policy is instantly > > deleted and the name reverts to non-HSTS operation (http:// connections > > work and certificate errors can be clicked through). > > Correct. Full removal of any prior evidence of SMTP STS Policy, but > because SMTP STS has both a DNS TXT record and a policy obtained via > HTTPS, the process of policy removal involves more steps on both sides. > > For example, policy removal should not result in an intermediate > state where the client is constantly refetching the max_age=0 STS > policy (because the TXT record is still visible, but the cache > has been flushed). > > I had considered using NXDOMAIN/NODATA, instead of an empty id, to > signal policy removal (provided the other end returns max_age = > 0), but this leads to a problem, because some DNS libraries (e.g. > libresolv) make it difficult to obtain the TTL of a negative reply. > With no TTL for NXDOMAIN/NODATA it is not clear how often one should > attempt to poll for "max_age = 0", and with TXT record removed, it > can no longer trigger early refresh. > > -- > Viktor. > > [ It is unfortunate that DNS NXDOMAIN/NODATA is often considered a > lookup error, whereas it is actually a lookup success, that yields > an empty result. DNS APIs should expose negative TTLs, but not > all do. ] > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --94eb2c112460f45d49055642ae1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The reason I asked this question is, as I said, we can ach= ieve some of the desired properties with less complexity. I'd like to b= reak down the various implementation options and which of the "removal= " properties they retain so we can make sure we choose the simplest op= tion that satisfies the requirements (or understand what the extra complexi= ty buys us).=C2=A0

So forgive me for fleshing out slight= ly more, but I believe "removal" is comprised of roughly the foll= owing behaviors:

A. MX/certificate changes don'= ;t affect mail delivery
B. MX/certificate changes don't affec= t TLSRPT reporting (since a domain may wish to continue to use TLSRPT but s= top using MTA-STS)
C. Any resource impact on senders to this d= omain=C2=A0from doing MTA-STS validation is eliminated
D. It is safe to remove the policy and TXT record

(D), I believe, is=C2=A0invariant in all implementations: a= ny hypothetical "removal" flow will=C2=A0involve serving t= he "removal" signal (whatever it is--a max_age=3D0 policy or anyt= hing else) until the last point in time the old=C2=A0policy was serv= ed + that policy's max_age. So (D) does not distinguish between differe= nt "removal" options.=C2=A0

Currently= : By setting "mode=3Dreport", you can achieve (A), but not (B= ).=C2=A0

Under the "max_age=3D0" prop= osal: You can achieve (A), (B), and (C).=C2=A0

Alternatively: If we had a "mode=3Dnone", you would achie= ve (A) and (B) but not=C2=A0(C), since senders would cache the "= ;mode=3Dnone" policy until max_age has passed).=C2=A0

I believe "mode=3Dnone" is simpler to implement and reas= on about, since it doesn't change the policy caching logic; it only<= /i>=C2=A0changes the actual reporting and enforcing behavior. (Conversely, = the "max_age=3D0" proposal may be simpler when viewed as changes = only to the process that fetches and caches policies, since it does not inv= olve any changes to policy use; that process simply purges the cached polic= y and calls it a day.)

I also believe property (C)= is unimportant, since senders who implement MTA-STS must be resilient (in = the resource usage sense) to recipients who have live policies; they can= 9;t in any way depend on the recipient revoking a policy to keep the cost o= f policy validation or caching down.

Questions:=

Is =C2=A0the "mode=3Dnone" proposal= simpler or more complex than "max_age=3D0"?=C2=A0

=
Is property (C) important?

tl;dr:

I'm good with policy removal, but &qu= ot;mode=3Dnone" seems a bit simpler to me (both in implementation and = reasoning about its properties). Thoughts?

On Tue, Aug 8, 2017 at 10:20 AM, Vikto= r Dukhovni <ietf-dane@dukhovni.org> wrote:
On Tue, Aug 08, 2017 at 05:30:18PM += 0300, Ilari Liusvaara wrote:

> > Thanks for the thorough writeup. A questi= on about the "requirements" stated:
> >
> > > 3.=C2=A0 It should be possible to re= move policy in a timely manner.
> >
> > What do you mean by "remove" and "not having"= a policy? What specific
> > behavior do you want from senders?
>
> The way I understand the request, it is full c= lear of policy, that is:
>
> - The existing policy is (immediately) invalidated.
> - The policy cache entry for the recipient is deleted.
>
> And since there is no policy anymore:
>
> - All certificate validation per the policy ceases.
> - All reporting per the policy ceases.
> - There is no difference in delivery behavior (for future deliveries)<= br> >=C2=A0 =C2=A0from STS policy having never existed.
>
> This is similar behavior with what happens with HSTS if valid HSTS
> header with max-age=3D0 is ever received: The HSTS policy is instantly=
> deleted and the name reverts to non-HSTS operation (http:// connection= s
> work and certificate errors can be clicked through).

Correct.=C2=A0 Full removal of any prior evidence of SMTP STS Policy= , but
because SMTP STS has both a DNS TXT record and a policy obtained via
HTTPS, the process of policy removal involves more steps on both sides.

For example, policy removal should not result in an intermediate
state where the client is constantly refetching the max_age=3D0 STS
policy (because the TXT record is still visible, but the cache
has been flushed).

I had considered using NXDOMAIN/NODATA, instead of an empty id, to
signal policy removal (provided the other end returns max_age =3D
0), but this leads to a problem, because some DNS libraries (e.g.
libresolv) make it difficult to obtain the TTL of a negative reply.
With no TTL for NXDOMAIN/NODATA it is not clear how often one should
attempt to poll for "max_age =3D 0", and with TXT record removed,= it
can no longer trigger early refresh.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

[ It is unfortunate that DNS NXDOMAIN/NODATA is often considered a
=C2=A0 lookup error, whereas it is actually a lookup success, that yields =C2=A0 an empty result.=C2=A0 DNS APIs should expose negative TTLs, but not=
=C2=A0 all do. ]

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--94eb2c112460f45d49055642ae1a-- --94eb2c112460fc889d055642ae92 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMK8x525biWylzaTdKMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTE4NDIxNVoXDTE3MTAx ODE4NDIxNVowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwhqodpCO7YNSzRIz9ahzJEd2Fmnm1g9pYE2GUs5S8c6Jh JLiZkF4+kTvQVptWmuoWxWqgeIJcqZKozIYoNl06ecCUcCSo/61I+QeD061Vfl9SemzDYrK9IJ5i fsx9sXOD+c20D4Lef7F0wC9azTDs36EwgEDBcLKUef5/Y/n3TDPth8kllj0cKBitt1MC2Il95W7a MyESYucDAH7gSG/dIOGNUaIh+vLLMtRvDQVRfveOum2uUf52bF3rywDJ32dvPCDVsRJHWuhBUfaP shyNiw4d/NzDjMdc504m+GABUpF9r8203gWdhHMxPyeDIzeV7wujWEZ19c0jOcFwdpupAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFB8LoXS3E+322ae/sSMWqyi4zefEMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCeAGD8kMXY iuahwdAzZ8iUfQSAM9M8Q1JPN+jXR6gcJXagqqdjHep1KcrhYx4xvhAUurzdH0AtzjdHuS1OKOj4 OYaMUtjuSYQ6SfFdpkM6K/Ih9IklpIV4BynT4/8D6WROz5f+sQGMf22geoCWbRUsBZv7GgMIWg+1 w6F7FiSFR7NKTBRZS4y/SHv0LCtC12JHyyVQrbxrjXy2tIcrhKC0DhToxe4s9aIA/kauGUSGXyLa U55gCBKpReCTtn1b4aQIwJp9aj0wDzfqs88hyIkWKDUMW7VP+Wdk9y6qUpKwbSN9pIu3m3UmjZC7 6923PlCyPXBkAIcLrTExf7wVn9lpMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCA2u5vogkz2B3Z7 4WiqFA2NnE0IARPP+us7D6xWCWwbFTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MDgxOTA4MDdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAES1da05QilkPEaWhDSCwouH8YXIPYta+ pJvy8ZOnVqo0YuCLATsMlYRKS1jSpgGbIC2SsuCQfmQdfUpbOObPIbZEsza7VlELJzK8/G/yt6Nr Q5A98ZvMxZo8mD1GCXSEClkQxiDWtt3IEB/Jdgo/A1xGwsSIXCmkl6hZdnaWbNVmUS/6M0CARpE4 apqZa1lbEIZ88rwgPQmS2mAYi9OWrjA+h+MlPiXGwhjQOUVJEIZqqYId1SJ0rz/2YCAF+/NlI6Ob We7suM+8Uk0LR3wffCRqLa2U44j1l0jOuBrUSFaXsVSKl8J2+dA2Jeo6j0X5sXBzJYeWi9orbRKy ihxNdg== --94eb2c112460fc889d055642ae92-- From nobody Tue Aug 8 14:06:37 2017 Return-Path: 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 1A9FC1324F4 for ; Tue, 8 Aug 2017 14:06:35 -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] 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 dYgkxcYEDkA4 for ; Tue, 8 Aug 2017 14:06:33 -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 76E9313242C for ; Tue, 8 Aug 2017 14:06:33 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 82FC67A3309; Tue, 8 Aug 2017 21:06:32 +0000 (UTC) Date: Tue, 8 Aug 2017 21:06:32 +0000 From: Viktor Dukhovni To: uta@ietf.org Message-ID: <20170808210631.GO8146@mournblade.imrryr.org> Reply-To: uta@ietf.org References: <149874228049.6468.6647983832951662733@ietfa.amsl.com> <20170807215520.GM8146@mournblade.imrryr.org> <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> <20170808172002.GN8146@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 21:06:35 -0000 On Tue, Aug 08, 2017 at 12:08:05PM -0700, Daniel Margolis wrote: > So forgive me for fleshing out slightly more, but I believe "removal" is > comprised of roughly the following behaviors: > > A. MX/certificate changes don't affect mail delivery > B. MX/certificate changes don't affect TLSRPT reporting (since a domain may > wish to continue to use TLSRPT but stop using MTA-STS) > C. Any resource impact on *senders to this domain* from doing MTA-STS > validation is eliminated > D. It is safe to remove the policy and TXT record > > (D), I believe, is invariant in all implementations: any hypothetical > "removal" flow *will* involve serving the "removal" signal (whatever it > is--a max_age=0 policy or anything else) until the last point in time the > *old* policy was served + that policy's max_age. So (D) does not > distinguish between different "removal" options. It must be possible to phase out the STS policy and decommission the associated HTTPS service. So, it I think that it is D that I'm trying describe, and specifically looking for D to happen "cleanly", that is, removal happens without policy refresh failures that look like an active attack. > *Currently: *By setting "mode=report", you can achieve (A), but not (B). Not the subject of this thread. > *Under the "max_age=0" proposal: *You can achieve (A), (B), and (C). The *combination* of max_age=0 *and* empty TXT id, makes it possible to cleanly transition from STS to no STS with no DNS TXT record and no HTTPS policy object. > *Alternatively: *If we had a "mode=none", you would achieve (A) and (B) but > *not* (C), since senders would cache the "mode=none" policy until max_age > has passed). mode=none still requires period refresh via HTTPS. So it fails the requirement to be able to erase all trace of STS. > I also believe property (C) is unimportant, since senders who implement > MTA-STS must be resilient (in the resource usage sense) to recipients who > have live policies; they can't in any way depend on the recipient revoking > a policy to keep the cost of policy validation or caching down. Once again the goal is to give the domain that publishes the policy a clean way out. > *Questions:* > > Is the "mode=none" proposal simpler or more complex than "max_age=0"? It fails to address how to actually *remove* all STS policy. The domain owner should be able to discontinue the underlying HTTPS service, and periodic policy updates from senders. -- Viktor. From nobody Tue Aug 8 15:25:01 2017 Return-Path: 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 1929D132043 for ; Tue, 8 Aug 2017 15:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 wq8zVrSWmF6i for ; Tue, 8 Aug 2017 15:24:47 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8BE132031 for ; Tue, 8 Aug 2017 15:24:47 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id 77so11397155itj.1 for ; Tue, 08 Aug 2017 15:24:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=pu1gXQfGY3RC+vvR/r6pLXkJEUu2kRmy4BjWkg5g1W4=; b=theqBTap+fhR+30Pv/AMHmj68Ee/oP45JmvSNLCIsOJu1oPzTpvgH/ApLINeS3h0LX skosb1/LJR6e6mUMTbJDTIJ5tKOvlvPc4wbMg8/wWabY64MmgxJRV4kN6YoI/OyaRkWg C8DmiMIn9fsiFC6jHYOQX9kdemBRMtvFSe2IgigWc8GccwH3kFX9Jwr/QDXQ6XNQPr+u tkJ1LQVVPaBsevupbsdLRGrFgOZGoNQzWweN5bke7Fa74hwH+tndnQvZU0xJnnRsTuC2 qaQKSrOxqbcYo8o1X8WTFYGfbfM3DU3BYnu43exgNNwzbujbbD6LCGrVPMzWEGIiH0wN URsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=pu1gXQfGY3RC+vvR/r6pLXkJEUu2kRmy4BjWkg5g1W4=; b=JXy1iMYW7cQtvRguw9Bcd2V2jV8y1jpQZi09RqN3N5IQG7TUECAnT9lzOMdVcM8pPp aOQ5Ye1ToiKKKGp9leiUkBQD+kXAU5QbCwfKmpdPwJNeBDQPVsM2wxeNBfBbp/bq+Slj nxKMwlKPckm9og/SpJc5h35udurDQy2QX/l/7BKddt0VkXgfMcODUUcnz0kRTAdho5VY OH/By3Ofp2B3KafQDn1JEruYQaaM7pNFMWevVNdf0Apv2pj61ISaKwh6k9lRSUHzw9p+ MZADNqPOMc0ScpzIcsleT17nwDwGeGoHCeQkisM52whJiUSnkgJVc5Xa/X6yL9SV4+y3 QBsQ== X-Gm-Message-State: AHYfb5h5+VRSUhGhc24yCggBrNW7jgH8FPnly6BtsNFmmE87ToqVRPUo /boeVRh9QVkqLGlnj3Y2e5GJKz7/nkDar9o= X-Received: by 10.36.37.130 with SMTP id g124mr5804394itg.114.1502231086339; Tue, 08 Aug 2017 15:24:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.159 with HTTP; Tue, 8 Aug 2017 15:24:45 -0700 (PDT) In-Reply-To: <20170808210631.GO8146@mournblade.imrryr.org> References: <149874228049.6468.6647983832951662733@ietfa.amsl.com> <20170807215520.GM8146@mournblade.imrryr.org> <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> <20170808172002.GN8146@mournblade.imrryr.org> <20170808210631.GO8146@mournblade.imrryr.org> From: Daniel Margolis Date: Tue, 8 Aug 2017 15:24:45 -0700 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1143cecc4d4b440556456e74" Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 22:25:00 -0000 --001a1143cecc4d4b440556456e74 Content-Type: multipart/alternative; boundary="001a1143cecc46674d0556456ebf" --001a1143cecc46674d0556456ebf Content-Type: text/plain; charset="UTF-8" Just for the sake of below discussion, I'm going to pretend there are three options on the table: 1. mode=report (as I said, this achieves A but not B) 2. mode=none (this doesn't exist, but you can imagine what it would look like) 3. max_age=0 (this is my shorthand for the previous proposal Viktor described, i.e. max_age=0 and an empty TXT ID) With that said, comments inline: On Tue, Aug 8, 2017 at 2:06 PM, Viktor Dukhovni wrote: > On Tue, Aug 08, 2017 at 12:08:05PM -0700, Daniel Margolis wrote: > > > So forgive me for fleshing out slightly more, but I believe "removal" is > > comprised of roughly the following behaviors: > > > > A. MX/certificate changes don't affect mail delivery > > B. MX/certificate changes don't affect TLSRPT reporting (since a domain > may > > wish to continue to use TLSRPT but stop using MTA-STS) > > C. Any resource impact on *senders to this domain* from doing MTA-STS > > validation is eliminated > > D. It is safe to remove the policy and TXT record > > > > (D), I believe, is invariant in all implementations: any hypothetical > > "removal" flow *will* involve serving the "removal" signal (whatever it > > is--a max_age=0 policy or anything else) until the last point in time the > > *old* policy was served + that policy's max_age. So (D) does not > > distinguish between different "removal" options. > > It must be possible to phase out the STS policy and decommission > the associated HTTPS service. > > So, it I think that it is D that I'm trying describe, and specifically > looking for D to happen "cleanly", that is, removal happens without > policy refresh failures that look like an active attack. > Sorry, I might have been unclear here, but I agree that you want to achieve (D). My point was that all three options have the exact same properties with respect to (D). In all three cases, you have to serve some "I'm opting out policy"--in option 1, this is a policy with "mode=report", in option 2 this is a policy with "mode=none", in option 3 this is a policy with "max_age=0"--for the same amount of time (i.e. preceding policies' last-serve-time + their max_age). So, you want (D), but the behavior with respect to (D) is unchanged in all three options, thus it doesn't help us distinguish between options. > > *Currently: *By setting "mode=report", you can achieve (A), but not (B). > > Not the subject of this thread. > > > *Under the "max_age=0" proposal: *You can achieve (A), (B), and (C). > > The *combination* of max_age=0 *and* empty TXT id, makes it possible > to cleanly transition from STS to no STS with no DNS TXT record > and no HTTPS policy object. > > > > *Alternatively: *If we had a "mode=none", you would achieve (A) and (B) > but > > *not* (C), since senders would cache the "mode=none" policy until max_age > > has passed). > > mode=none still requires period refresh via HTTPS. So it fails the > requirement to be able to erase all trace of STS. > How do you mean? You have to continue to serve this policy until all other previously served policies have expired; past that point you can turn it down at will. > It fails to address how to actually *remove* all STS policy. > The domain owner should be able to discontinue the underlying > HTTPS service, and periodic policy updates from senders. > Let me explain the process to remove all STS policy under a "mode=none" scenario: Suppose at time *t0* I have a normal (e.g. mode=enforce) policy with a max_age of *m*. Step 1: publish a policy with mode=none, and change the TXT record -- this happens at *t1* Step 2: wait until time *t1 + m* Step 3: remove the mode=none policy and TXT record In comparison, the process with the "max_age=0" scenario, as I understand it: Step 1: publish a policy with max_age=0, and change the TXT record Step 2: wait until *t1 + m* Step 3: remove the max_age=0 policy and TXT record So in fact property (D) is the same in both cases, is it not? > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a1143cecc46674d0556456ebf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just= for the sake of below discussion, I'm going to pretend there are three= options on the table:

1. mode=3Dreport (as I said, this achieves A but not B)
2. mode=3Dnone (this doesn't exist, but y= ou can imagine what it would look like)
3. = max_age=3D0 (this is my shorthand for the previous proposal Viktor describe= d, i.e. max_age=3D0 and an empty TXT ID)
With that said, comments inline:

On Tue, Aug 8= , 2017 at 2:06 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
On Tue, Aug = 08, 2017 at 12:08:05PM -0700, Daniel Margolis wrote:

> So forgive me for fleshing out slightly more, but I believe "remo= val" is
> comprised of roughly the following behaviors:
>
> A. MX/certificate changes don't affect mail delivery
> B. MX/certificate changes don't affect TLSRPT reporting (since a d= omain may
> wish to continue to use TLSRPT but stop using MTA-STS)
> C. Any resource impact on *senders to this domain* from doing M= TA-STS
> validation is eliminated
> D. It is safe to remove the policy and TXT record
>
> (D), I believe, is invariant in all implementations: any hypothetical<= br> > "removal" flow *will* involve serving the "remov= al" signal (whatever it
> is--a max_age=3D0 policy or anything else) until the = last point in time the
> *old* policy was served + that policy's max_age. So (D) doe= s not
> distinguish between different "removal" opt= ions.

It must be possible to phase out the STS policy and decommission
the associated HTTPS service.

So, it I think that it is D that I'm trying describe, and specifically<= br> looking for D to happen "cleanly", that is, removal happens witho= ut
policy refresh failures that look like an active attack.

Sorry, I might have been unclear here, but I agree that y= ou want to achieve (D). My point was that all three options have the exact = same properties with respect to (D).=C2=A0

In all = three cases, you have to serve some "I'm opting out policy"--= in option 1, this is a policy with "mode=3Dreport", in option 2 t= his is a policy with "mode=3Dnone", in option 3 this is a policy = with "max_age=3D0"--for the same amount of time (i.e. preceding p= olicies' last-serve-time + their max_age).=C2=A0

So, you want (D), but the behavior with respect to (D) is unchanged in a= ll three options, thus it doesn't help us distinguish between options.= =C2=A0
=C2=A0
> *Currently: *By setting "mode=3Dreport", you can achieve (A)= , but not (B).

Not the subject of this thread.

> *Under the "max_age=3D0" proposal: *You can achieve (A), (B)= , and (C).

The *combination* of max_age=3D0 *and* empty TXT id, makes it possible
to cleanly transition from STS to no STS with no DNS TXT record
and no HTTPS policy object.


> *Alternatively: *If we had a "mode=3Dnone", you would achiev= e (A) and (B) but
> *not* (C), since senders would cache the "mode=3Dnone" polic= y until max_age
> has passed).

mode=3Dnone still requires period refresh via HTTPS.=C2=A0 So it fails the<= br> requirement to be able to erase all trace of STS.

=
How do you mean? You have to continue to serve this policy until= all other previously served policies have expired; past that point you can= turn it down at will.=C2=A0
=C2=A0
It fails to address how to actually *remove* all STS policy.
The domain owner should be able to discontinue the underlying
HTTPS service, and periodic policy updates from senders.

Let me explain the process to remove all STS policy under= a "mode=3Dnone" scenario:

Suppose at ti= me t0=C2=A0I have a normal (e.g. mode=3Denforce) policy with a max_a= ge of m.=C2=A0

Step 1: publish a policy wit= h mode=3Dnone, and change the TXT record -- this happens at t1
=
Step 2: wait until time t1 + m
Step 3: remove the mod= e=3Dnone policy and TXT record

In comparison, the = process with the "max_age=3D0" scenario, as I understand it:

Step 1: publish a policy with max_age=3D0, and change = the TXT record
Step 2: wait until t1 + m
Step 3:= remove the max_age=3D0 policy and TXT record

So i= n fact property (D) is the same in both cases, is it not?
=C2=A0<= /div>

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--001a1143cecc46674d0556456ebf-- --001a1143cecc4d4b440556456e74 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMK8x525biWylzaTdKMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTE4NDIxNVoXDTE3MTAx ODE4NDIxNVowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwhqodpCO7YNSzRIz9ahzJEd2Fmnm1g9pYE2GUs5S8c6Jh JLiZkF4+kTvQVptWmuoWxWqgeIJcqZKozIYoNl06ecCUcCSo/61I+QeD061Vfl9SemzDYrK9IJ5i fsx9sXOD+c20D4Lef7F0wC9azTDs36EwgEDBcLKUef5/Y/n3TDPth8kllj0cKBitt1MC2Il95W7a MyESYucDAH7gSG/dIOGNUaIh+vLLMtRvDQVRfveOum2uUf52bF3rywDJ32dvPCDVsRJHWuhBUfaP shyNiw4d/NzDjMdc504m+GABUpF9r8203gWdhHMxPyeDIzeV7wujWEZ19c0jOcFwdpupAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFB8LoXS3E+322ae/sSMWqyi4zefEMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCeAGD8kMXY iuahwdAzZ8iUfQSAM9M8Q1JPN+jXR6gcJXagqqdjHep1KcrhYx4xvhAUurzdH0AtzjdHuS1OKOj4 OYaMUtjuSYQ6SfFdpkM6K/Ih9IklpIV4BynT4/8D6WROz5f+sQGMf22geoCWbRUsBZv7GgMIWg+1 w6F7FiSFR7NKTBRZS4y/SHv0LCtC12JHyyVQrbxrjXy2tIcrhKC0DhToxe4s9aIA/kauGUSGXyLa U55gCBKpReCTtn1b4aQIwJp9aj0wDzfqs88hyIkWKDUMW7VP+Wdk9y6qUpKwbSN9pIu3m3UmjZC7 6923PlCyPXBkAIcLrTExf7wVn9lpMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAJ5C+9AKHe2D2T np0GWRZZd9LiOE/1ndMCylpy59281TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MDgyMjI0NDZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAaVG3MHyrXJMM2xSQm9BKDAgtqPgcL8i6 Tosp5/Cfoc5aZiF4I8QFweom9kVD6S/bi9IIXEOKUnsk4smTRKDxGNGQUgOEAIYEyiXqZOo/V6FK 2185hfh3z8Lq4231vVnQ7BqG9vBunVh3Fm7kASLFmn7QPeh0S+upoK2IG1nCfR64wRn2x9y9ZZvG aCYiKywt9vAM6466vOkBqSAq+9pJEh/5fyE9CkyhK7r6n5zNCfU6TMS/fWMzMxkllriLjxrw5qZY 73RvE5k/J0qSMEPV2l3ECoVJ+3HwAYCUH6JXiXJE7eAG7d7BiHWSfwUMUZMHDjS8ibKR0yTtxl6c u+T9/w== --001a1143cecc4d4b440556456e74-- From nobody Tue Aug 8 22:11:42 2017 Return-Path: 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 AA967131DB6 for ; Tue, 8 Aug 2017 22:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 1_lm0KHu-lz7 for ; Tue, 8 Aug 2017 22:11:39 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CEEF131DA2 for ; Tue, 8 Aug 2017 22:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1502255499; x=1533791499; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZR86Xr+eZvuwIkGvNFCTKoYNM23Jh+x8NfXzNSYrMpg=; b=o2FzYPlO68JnBcn1fw1NS2hRCT/3iwDygbejj6pPJjxsHKeR7f/CzlCW QRSw7wHpOorp7XRahV9yV9fyyk7DWIQAUJ0t9QxkzhP5KQlxecDE6B3HW sRkki5ASAGEC9DTF9dhuS8sjB8ePA2weWdUyelhUT4tRqX1tRRG83XRPm X0qHDI/QT4q1J03IOZPSXD8dIkY6jC+83aZTS6glnLQ50uddbO0mvajkc XctdQS518LXkUnaaMd4I0hlKZBmCPYsnKKp1wnqXnh//5KbxeCAQC9LKD 6Hg/dilWU3kep/J+9JiLBm68Hcc8neByPJSc7KzzYgENxKhHJWIsJDPEp Q==; X-IronPort-AV: E=Sophos;i="5.41,346,1498478400"; d="scan'208";a="172381998" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-e.UoA.auckland.ac.nz) ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Aug 2017 17:11:36 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.29) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 9 Aug 2017 17:11:36 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Wed, 9 Aug 2017 17:11:35 +1200 From: Peter Gutmann To: Ilari Liusvaara , Daniel Margolis CC: "uta@ietf.org" Thread-Topic: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. Thread-Index: AQHTEEYDpYDEZIQ0WEKjM6/GO4ylyaJ5vAAAgAALoACAAbOYmg== Date: Wed, 9 Aug 2017 05:11:35 +0000 Message-ID: <1502255463294.57211@cs.auckland.ac.nz> References: <149874228049.6468.6647983832951662733@ietfa.amsl.com> <20170807215520.GM8146@mournblade.imrryr.org> <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII>, <20170808151154.faoxa36jo64f4rxp@LK-Perkele-VII> In-Reply-To: <20170808151154.faoxa36jo64f4rxp@LK-Perkele-VII> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 05:11:41 -0000 Ilari Liusvaara writes:=0A= =0A= >1) CN-IDs have long been deprecated. =0A= =0A= Right, but everyone uses the CN for the primary ID anyway, that's pretty mu= ch=0A= the universal usage for it. Deprecating this universal usage is an example= of=0A= what someone on the PKIX list once called "workgroup posturing" (it wasn't = me,=0A= even if it sounds like the sort of thing I'd say :-).=0A= =0A= >Thus, certificate with only SAN '*.example.net' can not match=0A= >'foo.bar.example.net'. Yet, tracing the code in appendix, it appears that = the=0A= >code considers this to match.=0A= =0A= The pseudocode and long-form descriptions don't match up in a number of=0A= locations. In fact the 2459 pseudocode, the 3280 pseudocode, and the text = all=0A= disagree with each other (I haven't checked whether it's changed again in= =0A= 5280), so depending on which you use as your reference you can get differen= t=0A= results for path validation. Or think of it as a great deal of flexibility= in=0A= what you can call a compliant implementation.=0A= =0A= I've always taken the text as being definitive. Or at least I produced my = own=0A= pseudocode, leading to the inevitable reference to https://xkcd.com/927.=0A= =0A= Peter.=0A= From nobody Tue Aug 8 22:20:38 2017 Return-Path: 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 54B75131D27 for ; Tue, 8 Aug 2017 22:20:37 -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] 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 JTuPh_biZ6_q for ; Tue, 8 Aug 2017 22:20:35 -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 600EA120227 for ; Tue, 8 Aug 2017 22:20:35 -0700 (PDT) Received: from [192.168.1.161] (static-100-2-39-101.nycmny.fios.verizon.net [100.2.39.101]) (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 EE6BE7A3302 for ; Wed, 9 Aug 2017 05:20: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.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 9 Aug 2017 01:20:54 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> References: <149874228049.6468.6647983832951662733@ietfa.amsl.com> <20170807215520.GM8146@mournblade.imrryr.org> <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> <20170808172002.GN8146@mournblade.imrryr.org> <20170808210631.GO8146@mournblade.imrryr.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 05:20:37 -0000 > On Aug 8, 2017, at 6:24 PM, Daniel Margolis = wrote: >=20 > mode=3Dnone still requires period refresh via HTTPS. So it fails the > requirement to be able to erase all trace of STS. >=20 > How do you mean? You have to continue to serve this policy until all = other previously served policies have expired; past that point you can = turn it down at will. No. That's the point, you can't generally just turn it out at will without some care, or else risk creating refresh failures during a transition period. When a "none" policy is cached, it is still a policy and still subject to periodic refresh, perhaps you're suggesting to use "none" as a synonym for "max_age=3D0" that still leaves us with a usable cache time, in which case are free to use NODATA/NXDOMAIN as that TTL is no longer requires. So the new process would be: * Publish a "none" policy with a comparatively short "max_age". * Remove the TXT record. * After some time (all previous policies expire) remove the "none" policy. Now the clients can: * Cache policies with empty id (not otherwise valid) when TXT lookup returns NXDOMAIN/NODATA. Except when policy mode is "none" in which case the cache is immediately flushed, and stays that way unless the TXT reappears at some point. Refresh per max_age and proactive update attempt cycle. * When "none" is seen with a "TXT" id, cache that as indicated, but if TXT disappears at any time, flush the policy then. This seems to work better than "max_age =3D 0". However, the same cannot be said of "report", which has no clean transition to policy removal, as dropping the TXT record still leads to policy refresh with no end in sight, while a suddenly missing policy (404 and the like) is not defined (deliberately IIRC and likely correctly) to mean policy removal. =20 --=20 Viktor. From nobody Wed Aug 9 06:07:24 2017 Return-Path: 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 1A13A1321D2 for ; Wed, 9 Aug 2017 06:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kc6ndDqEVAlX for ; Wed, 9 Aug 2017 06:07:21 -0700 (PDT) Received: from pacdcmhout02.cable.comcast.com (pacdcmhout02.cable.comcast.com [68.87.96.15]) (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 C8C531200C5 for ; Wed, 9 Aug 2017 06:07:20 -0700 (PDT) X-AuditID: 4457600f-c41ff7000000ac47-dd-598b0905ff76 Received: from PACDCEX17.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by pacdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id D2.FB.44103.5090B895; Wed, 9 Aug 2017 09:07:19 -0400 (EDT) Received: from PACDCEX19.cable.comcast.com (24.40.1.142) by PACDCEX17.cable.comcast.com (24.40.1.140) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 9 Aug 2017 09:07:16 -0400 Received: from PACDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8304]) by PACDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8304%19]) with mapi id 15.00.1293.002; Wed, 9 Aug 2017 09:07:16 -0400 From: "Brotman, Alexander" To: Jim Fenton , "uta@ietf.org" Thread-Topic: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 Thread-Index: AQHS+vc6d9zr6ZLgOkqvSwpHSRIkfKJu7zEAgASYBoCACKJjMA== Date: Wed, 9 Aug 2017 13:07:16 +0000 Message-ID: References: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> <8d9f92ea-6cea-1828-0f4b-3487240a81bd@bluepopcorn.net> In-Reply-To: <8d9f92ea-6cea-1828-0f4b-3487240a81bd@bluepopcorn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA11UXUwUVxjNnZllZ3GvDIO7ex3B1okPRpBSJXEtrbXWKDEaTTSpa0J1WEZ2 ZfYnM7sKliYkplYgJjXREJe0tRUMIBujKQkobpPVTRRt/SG1pr6gQgoYHrCkrUlDe+/MDs72 ab455557zvfdO8PS/AOHwAbDMVkNS4qYl89s+UQsXmN3tPsqxh4h75+tCdo7kjkONlHVE33T VHVX12tqN7U///06WQkekdV3Nh7MDzzLjNujPd7G2Zd99hYwtqYNOFjEVaKfzj2k20A+y3PX KHRn+h4wXoYASkz2Zl9uAzR0u9dOJHnce2jm3y9pUi/htqJvTv+u40WcF538ZQIY+AZ05vu7 NqPejJK9/QypGW4lmn3aqa+B3Hb0pOVHyjBIAjT79SV9kYP7GJ0eTukGgHOjv0b6KVLTnAf9 Nv4tZeTmUNfwfdqoXWjqxbzNqCvQQHcK78Pi+i28Z1Zahs5ff5Vn1KXo4ncvaSNDIbpzbpwx pB5089ag7SvgSVjcEhZ5wiJPWOTnAdMHlkclf50/FIjEYxVry/1SrSKX+yMhv6TFyPMq0I/t YMEgyHRUpwHHAtEJK6fafLxNOqI1hdKggaVEF7xa2urjF9dG6poCkhY4oMYVWROXwE0Qr4QL cG1caRAF6GDbfXzRAhqWj2qKHMP3RFwOUTdWeBY4La5Fg/5gJK4diKtKGiCWxtsWkA1gndR0 TFYjhlkaLGMZ0QObS4/7eK5eiskNshyVVZM9yrIignvsWFioyvVy46GgEjNprON+PYF1VkYP WwKrTp308W4rYcm7AgpbMS1Y6f9HplhHGtSzTpx7jNhDLSqFtGB91roIhhiMOk1Ut10KD5EW eRO0WJbAIBmR26Ry7UZAO2B/SAzMUWz/5eE5imfCkbAseGCSWHNEFIiHFxoX3FDb+IWPL7AQ JIBQDD8nuMuCv8kgvA2bCbvUwubGML/2aeDHN6YIHibuTvwveNM3D/cRcFEW1Ns2DyiLWbou hirp2pVlct2m8XgpPN59O1vJeGNSzDreFEGdJpod7w0C8iaYM159vdukcp2EFrDtxGeZU401 3p+3TU2+GkquqLneHbjxvP3eH6nOwqHLZ5/83TG5ebty/8PORyPqR6hr5a5FNXvX79i/atQ1 Wjn3uOzCB1cGygcb23rmbZP/LK5SOlp6b3lHL84fE6UZZUPVi/KbWvAx8+loc89EWUn3lhC8 xi/LpGwzM2L13XWMnLwiMlpAenc1rWrSf0puPAdjBQAA Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 13:07:23 -0000 Jim, To be clear, you'd like to remove the headers (5.3) and filename (5.1) sect= ions, and have all the filtering based solely on the subject that is specif= ied in 5.3? And relating to "draft-ietf-dnsop-attrleaf", could you clarify= that a bit? Are you asking me to request an alteration of the attrleaf do= cument after TLSRPT has been created? I'm working through the rest of the alterations. -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast -----Original Message----- From: Uta [mailto:uta-bounces@ietf.org] On Behalf Of Jim Fenton Sent: Thursday, August 03, 2017 5:11 PM To: uta@ietf.org Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 In response to Leif's request for specific text for the larger issues: On 7/31/17 4:02 PM, Jim Fenton wrote: > > General comments: > > All of the references are listed as normative, which I strongly=20 > suspect isn't really the case. Informative references need to be separate= d. > > As the document notes, the reference for MTA-STS needs to be added. If=20 > it is a normative reference, this document will be held up until that=20 > is published. I agree that the MTA-STS reference is informative. By my reading, the follo= wing RFC references are also informative: 3207, 3501, 3864, 7435, 7469, 7489 But check me on those... > > Section 3, what happens in the case of HTTPS delivery of reports if=20 > there is some problem with the certificate presented by the server?=20 > For mailto:, it explicitly states that the message should be sent in=20 > the clear if necessary, but that doesn't seem to be the case with https:. Section 3, third bullet: o In the case of "https", reports SHOULD be submitted via POST ([RFC2818]) to the specified URI. Report submitters MAY ignore certificate = verification errors when submitting reports via https. > > Section 4.3.2.1, dnssec-invalid: In this case, would the TLSRPT policy=20 > be found? Maybe just note this situation; add the following text to this bullet: Note that DNSSEC failures are likely to also affect the retrieval of the TL= SRPT record, so reports with this failure are likely to be rare in practice= . > > Section 5.1, I don't like the idea of associating semantics with the=20 > filename of MIME parts. As it's written, use of the specified filename=20 > format is optional, so the recipient can't depend on it anyway. DMARC=20 > does this, and I didn't like it there either, but it's an=20 > informational document so this may not have gotten all the scrutiny=20 > this should as a standards-track document. I suggest eliminating this requirement. > > Section 5.3, I don't think it's a good idea to define and require new=20 > message header fields for this. This means that some of the=20 > general-purpose libraries for sending email messages can't be used. A=20 > better approach IMO would be to suggest the use of separate email=20 > addresses (e.g., reports@example.org or reports+client1@example.org=20 > for a service provider) in order to distinguish reports from other traffi= c. I suggest eliminating this requirement. > > IANA considerations: Consider adding a request to register=20 > _smtp-tlsrpt in the registry being created by=20 > draft-ietf-dnsop-attrleaf if that registry is created before this is publ= ished. 6.6. _smtp-tlsrpt DNS Global Underscore Scoped Registry Entry This document registers a new DNS name in the "DNS Global Underscore Scoped= Entry Registry" as follows: Scoped Entry: _smtp-tlsrpt Applicable protocol: SMTP Status: standard Author/Change controller: IETF Specification document(s): This document Note that this registry is created by the publication of draft-ietf-dnsop-a= ttrleaf. If this document precedes it in publication, the entry is requeste= d to be included in the registry at its creation. > > Section 7, Reports as DDoS: The discussion revolves around the fact=20 > that, unlike DMARC, there isn't a third party involved in a DMARC=20 > report so it isn't necessary to validate delegation. I'm not sure this=20 > completely alleviates the DDoS risk, though: it's equally possible for=20 > malicious second parties to overload the receiver with reports, or for=20 > malicious parties to look around for TLSRPT policies with mailto: > addresses and just spam them. It might be good to acknowledge that=20 > possibility here. Also, the suggestion of sending the messages daily=20 > for > 0000-2400 UTC (section 4.1) does not scale well, and may be a DDoS in=20 > itself. Section 4.1: The report SHOULD cover a full day (24 hours). In order to avoid congestion= caused by synchronized transmission and receipt of reports, report senders= SHOULD choose an arbitrary time to send their reports, either individually= or as a group. The transmission time MAY be determined, for example, by ha= shing the reporting domain name, taking the result modulo 1440, and sending= reports at that many minutes past midnight UTC each day. In Section 7: (original text is OK here too if you prefer, but suggest incl= uding the "More broadly" sentence) Reports as DDoS: TLSRPT allows specifying destinations for reports that are= outside the authority of the Policy Domain, which allows domains to delega= te processing of reports to a partner organization. However, an attacker wh= o controls a Policy Domain DNS could also use this mechanism to direct the = reports to an unwitting victim, flooding that victim with excessive reports= . More broadly, the publication of a reporting email address or URI present= s the opportunity for the addresses to be harvested and used as the target = of a DoS or DDoS attack. DMARC [RFC7489] defines a solution for verifying d= elegation to avoid such attacks, which is an effective countermeasure for i= nnocent third-party senders of reports, but TLSRPT has less need for a veri= fication mechanism because it would require the attacker to induce the inno= cent third party to send mail to the attacker. > > Section 7, additional consideration: The "untrusted content" > consideration talks about malicious code, but attackers could also=20 > send counterfeit reports that look real in an effort to confuse the=20 > report recipient. Should valid DKIM signatures from the reporting=20 > domain be required on TLSRPT messages? Add to Section 7: Deceptive reports: TLSRPT supports the processing of reports from arbitrary= sources. As such, the data in the reports may be incorrect or even intenti= onally deceptive. Report recipients need to be aware of and prepared to han= dle this situation. Add to bullet 4 of Section 3: Reports sent via SMTP MUST contain a valid DKIM [RFC6376] signature by the = reporting domain. Reports lacking such a signature MUST be ignored by the r= ecipient. (add normative reference to RFC6376) (note that we still have a problem authenticating https reports, unless cli= ent-authenticated TLS is required, which would be an onerous requirement). _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta From nobody Wed Aug 9 06:34:18 2017 Return-Path: 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 1C6091321DC for ; Wed, 9 Aug 2017 06:34:16 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 V0SACDa_RrbS for ; Wed, 9 Aug 2017 06:34:13 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id EAC59131D2F for ; Wed, 9 Aug 2017 06:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1502285651; d=isode.com; s=june2016; i=@isode.com; bh=TpqDWHQdi8WN4bhnKvYECXSHeZrg2Gd+ZgO/Escg7oM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=rEV1gka984PHu97FArSybYRsPxCZU2k3isgHqMc5OYwltMBVoO4fm3EcgPwBwHbLZ64eSi OVtx6L4TqUYra/4SMMXTgY17hNHtp4u3rEwU4CnQY52CsLnv0DbeshI7yW5S+Jt55ca/Uk 77Ql+TXRwig9eNc7Lvrl5dD03CWti6E=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 9 Aug 2017 14:34:10 +0100 To: "Brotman, Alexander" , Jim Fenton , "uta@ietf.org" References: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> <8d9f92ea-6cea-1828-0f4b-3487240a81bd@bluepopcorn.net> From: Alexey Melnikov Message-ID: <6c1546c6-69e0-1d2e-1084-5013f7241073@isode.com> Date: Wed, 9 Aug 2017 14:33:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 13:34:16 -0000 Hi, (As a participant) On 09/08/2017 14:07, Brotman, Alexander wrote: > Jim, > > To be clear, you'd like to remove the headers (5.3) and filename (5.1) sections, and have all the filtering based solely on the subject that is specified in 5.3? I don't think Jim made a convincing argument for removing new header fields. From my personal experience writing IMAP based applications that search for this information (e.g. to search and process "all reports from a particular domain") is easier with new header fields than doing a search on a Subject which has complicated structure. This has nothing to do with whether the same mailbox receives multiple types of email messages, this is still a useful functionality if a particular mailbox receives only TLSRPT reports. As per my followup discussion with Jim libraries for generating messages need to be able to add new header fields anyway. If people have real world experience about whether this is problematic, I would like to hear it. Regarding filenames - I am ambivalent. If you need this information somewhere, you will need to define new header fields as well. > And relating to "draft-ietf-dnsop-attrleaf", could you clarify that a bit? Are you asking me to request an alteration of the attrleaf document after TLSRPT has been created? (As Area Director) Yes. Depending on which documents gets to IESG first, the last one should include the information. Best Regards, Alexey > I'm working through the rest of the alterations. > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse > Comcast > > > -----Original Message----- > From: Uta [mailto:uta-bounces@ietf.org] On Behalf Of Jim Fenton > Sent: Thursday, August 03, 2017 5:11 PM > To: uta@ietf.org > Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 > > In response to Leif's request for specific text for the larger issues: > > On 7/31/17 4:02 PM, Jim Fenton wrote: >> General comments: >> >> All of the references are listed as normative, which I strongly >> suspect isn't really the case. Informative references need to be separated. >> >> As the document notes, the reference for MTA-STS needs to be added. If >> it is a normative reference, this document will be held up until that >> is published. > I agree that the MTA-STS reference is informative. By my reading, the following RFC references are also informative: > 3207, 3501, 3864, 7435, 7469, 7489 > > But check me on those... >> Section 3, what happens in the case of HTTPS delivery of reports if >> there is some problem with the certificate presented by the server? >> For mailto:, it explicitly states that the message should be sent in >> the clear if necessary, but that doesn't seem to be the case with https:. > Section 3, third bullet: > > o In the case of "https", reports SHOULD be submitted via POST > ([RFC2818]) to the specified URI. Report submitters MAY ignore certificate verification errors when submitting reports via https. > >> Section 4.3.2.1, dnssec-invalid: In this case, would the TLSRPT policy >> be found? > Maybe just note this situation; add the following text to this bullet: > > Note that DNSSEC failures are likely to also affect the retrieval of the TLSRPT record, so reports with this failure are likely to be rare in practice. > >> Section 5.1, I don't like the idea of associating semantics with the >> filename of MIME parts. As it's written, use of the specified filename >> format is optional, so the recipient can't depend on it anyway. DMARC >> does this, and I didn't like it there either, but it's an >> informational document so this may not have gotten all the scrutiny >> this should as a standards-track document. > I suggest eliminating this requirement. >> Section 5.3, I don't think it's a good idea to define and require new >> message header fields for this. This means that some of the >> general-purpose libraries for sending email messages can't be used. A >> better approach IMO would be to suggest the use of separate email >> addresses (e.g., reports@example.org or reports+client1@example.org >> for a service provider) in order to distinguish reports from other traffic. > I suggest eliminating this requirement. >> IANA considerations: Consider adding a request to register >> _smtp-tlsrpt in the registry being created by >> draft-ietf-dnsop-attrleaf if that registry is created before this is published. > 6.6. _smtp-tlsrpt DNS Global Underscore Scoped Registry Entry > > This document registers a new DNS name in the "DNS Global Underscore Scoped Entry Registry" as follows: > > Scoped Entry: _smtp-tlsrpt > Applicable protocol: SMTP > Status: standard > Author/Change controller: IETF > Specification document(s): This document > > Note that this registry is created by the publication of draft-ietf-dnsop-attrleaf. If this document precedes it in publication, the entry is requested to be included in the registry at its creation. >> Section 7, Reports as DDoS: The discussion revolves around the fact >> that, unlike DMARC, there isn't a third party involved in a DMARC >> report so it isn't necessary to validate delegation. I'm not sure this >> completely alleviates the DDoS risk, though: it's equally possible for >> malicious second parties to overload the receiver with reports, or for >> malicious parties to look around for TLSRPT policies with mailto: >> addresses and just spam them. It might be good to acknowledge that >> possibility here. Also, the suggestion of sending the messages daily >> for >> 0000-2400 UTC (section 4.1) does not scale well, and may be a DDoS in >> itself. > Section 4.1: > > The report SHOULD cover a full day (24 hours). In order to avoid congestion caused by synchronized transmission and receipt of reports, report senders SHOULD choose an arbitrary time to send their reports, either individually or as a group. The transmission time MAY be determined, for example, by hashing the reporting domain name, taking the result modulo 1440, and sending reports at that many minutes past midnight UTC each day. > > In Section 7: (original text is OK here too if you prefer, but suggest including the "More broadly" sentence) > > Reports as DDoS: TLSRPT allows specifying destinations for reports that are outside the authority of the Policy Domain, which allows domains to delegate processing of reports to a partner organization. However, an attacker who controls a Policy Domain DNS could also use this mechanism to direct the reports to an unwitting victim, flooding that victim with excessive reports. More broadly, the publication of a reporting email address or URI presents the opportunity for the addresses to be harvested and used as the target of a DoS or DDoS attack. DMARC [RFC7489] defines a solution for verifying delegation to avoid such attacks, which is an effective countermeasure for innocent third-party senders of reports, but TLSRPT has less need for a verification mechanism because it would require the attacker to induce the innocent third party to send mail to the attacker. > > >> Section 7, additional consideration: The "untrusted content" >> consideration talks about malicious code, but attackers could also >> send counterfeit reports that look real in an effort to confuse the >> report recipient. Should valid DKIM signatures from the reporting >> domain be required on TLSRPT messages? > Add to Section 7: > > Deceptive reports: TLSRPT supports the processing of reports from arbitrary sources. As such, the data in the reports may be incorrect or even intentionally deceptive. Report recipients need to be aware of and prepared to handle this situation. > > Add to bullet 4 of Section 3: > > Reports sent via SMTP MUST contain a valid DKIM [RFC6376] signature by the reporting domain. Reports lacking such a signature MUST be ignored by the recipient. > > (add normative reference to RFC6376) > > (note that we still have a problem authenticating https reports, unless client-authenticated TLS is required, which would be an onerous requirement). > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta From nobody Wed Aug 9 06:40:12 2017 Return-Path: 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 0D5F81321C4 for ; Wed, 9 Aug 2017 06:40:11 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 DqNHsrJY_XL8 for ; Wed, 9 Aug 2017 06:40:09 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id A100D1321AF for ; Wed, 9 Aug 2017 06:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1502286008; d=isode.com; s=june2016; i=@isode.com; bh=3txJIVVPv0+OQ8XFCikjwi3NI8knW8CdvhHH7HfhyOg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=w86IVxWZeAMyOe3GjR2EXVVXloCzd9YkivGMW8Uu+0TZ+jO195Gkwa7AqOBc1F4/TcE5dm 8/v8v5IoNzGXijH++7UKCCn/Ea8R9oYnhrrmelCAdauwBxe1Jfq7YTtWg0ABWM/T9dqaBG fmLG34y3J7NgteEuwL4cKYMRrktgNGs=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 9 Aug 2017 14:40:08 +0100 From: Alexey Melnikov To: "Brotman, Alexander" , Jim Fenton , "uta@ietf.org" References: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> <8d9f92ea-6cea-1828-0f4b-3487240a81bd@bluepopcorn.net> <6c1546c6-69e0-1d2e-1084-5013f7241073@isode.com> Message-ID: Date: Wed, 9 Aug 2017 14:39:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 In-Reply-To: <6c1546c6-69e0-1d2e-1084-5013f7241073@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 13:40:11 -0000 A few more comments on filenames: On 09/08/2017 14:33, Alexey Melnikov wrote: > Regarding filenames - I am ambivalent. If you need this information > somewhere, you will need to define new header fields as well. In IMAP filename Content-Disposition parameter is returned as a part of BODYSTRUCTURE. This means that it is easy to extract this information algorithmically in one round trip, without the need to downaload and parse the whole report message. I am not saying that filename is the best thing, but this is a nice property. If people think that this type of information should be easy to retrieve through IMAP, there are other ways that are IMAP-friendly. For example making this a new parameter to Content-Disposition header field would still work (it is also returned in BODYSTRUCTURE). Best Regards, Alexey From nobody Wed Aug 9 06:47:37 2017 Return-Path: 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 349AE1321D8 for ; Wed, 9 Aug 2017 06:47:37 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 PjjFEwXEfYQV for ; Wed, 9 Aug 2017 06:47:36 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 019721321CE for ; Wed, 9 Aug 2017 06:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1502286455; d=isode.com; s=june2016; i=@isode.com; bh=Hq5Orr4+8y/VFGaCnAwzKygqxKE+2Q8AbVW/vp+rixU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Tyd4rei9Yu6ewzmeV0Kl+ZFkOSf8YyXkDYBH6V7emzqosuXydatNn/eav97P4a/SBY9+kC AiG7LhBA2MHfST+dMfRDnx1pCpYvPWSmzaic7GidCtefpxTqN/yz/dW3PDHBjL6FZJngkH PHahsQhzznA+hPLArcHJweg7nFRN9Ag=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 9 Aug 2017 14:47:35 +0100 To: Jim Fenton , uta@ietf.org References: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> <24B2EFA1-457B-4C4D-8AFF-7B42D89F48D4@isode.com> <5980DE3B.6010409@isode.com> From: Alexey Melnikov Message-ID: Date: Wed, 9 Aug 2017 14:47:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 13:47:37 -0000 Hi Jim, On 03/08/2017 06:01, Jim Fenton wrote: > On 08/01/2017 10:17 PM, Leif Johansson wrote: >> On 2017-08-01 22:08, Jim Fenton wrote: >>> I don't think I was suggesting anything involving Subject. There's >>> already some of this in Section 5.3, and I'm not crazy about doing that >>> either, especially since it's only a SHOULD (so the report recipient >>> can't really depend on it being formatted that way). >> On the contrary. A SHOULD basically means you follow the spec unless >> you have a good reason not to do so. > In this case, you're depending on all of the domains that send TLS > reports not to have a good reason not to do so. Maybe I'm just > extra-careful, but I don't know what good reasons might come up (maybe > some agent rewriting the Subject header field?) so I would be inclined > to not depend on it. If this Subject header field formatting stands, is > there some requirement that the requirement isn't a MUST (like the > TLS-Report-* header fields)? > > Even so, recipients need to be able to handle any Subject header field > that anyone throws at them, at least to discard those messages and not > otherwise fail. This is true. > For that reason, I think it's a good idea to minimize > the number of things that require robust checking. Isn't this > information in the payload of the report anyway? I'm not a fan of > redundant information that can be inconsistent. Yes, this information is available in the JSON report itself, but it is hard to extract without downloading and parsing the whole report. If one writes an application which is mindful of bandwidth it is using (e.g. using IMAP) and such application wants to find all reports that have a particular property (e.g. all reports from or about a particular domain), it is more bandwidth and CPU efficient to extract this information from some header fields. Best Regards, Alexey From nobody Wed Aug 9 08:52:54 2017 Return-Path: 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 C48461323CE for ; Wed, 9 Aug 2017 08:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 vQm9Me_4D-Ok for ; Wed, 9 Aug 2017 08:52:51 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A771323A6 for ; Wed, 9 Aug 2017 08:52:51 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id f16so10668501itb.0 for ; Wed, 09 Aug 2017 08:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=DEvecOiAFHVU0iFIZqdXDw45t44hbZTcu6vencyFWA0=; b=v3N3jeCVyVYO5kakx8v16Be5F1sy4PqQDl8NYifxV0EZBVaS/QyJL1fCRwtajybnKd Uj8vKWJw+X32yeBckD0bCwS5rsmcU+YW6sfl9Z/35VG5L3AbiFdqzRCGzgiJpS3mpiRW 9IZloYQROUOsg5BS/z4o5XBu+zIHaYbsOL1VPvXVWholNFbGQqcPrDPdFU6Y6WBZBecs UI2lzR0Pm6i/cx3UXfIJDqAz/r5jf7vpNm/yzzcz1Rgd7lRhyHzUZLDDHMdCsu2xh0zp qZduYDh1Wfknmiee/B4wGucAqjlMBymLpqeeFP6n0VuwXf0abSu0v9oBvPamURtZlm7J H6Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=DEvecOiAFHVU0iFIZqdXDw45t44hbZTcu6vencyFWA0=; b=QZgdokTV6g3IqL+61MzTiHjOfRUX7UGZPauX1eGyY6FtfyvE2TEtgJaplbNgp17qON 5zRzqcCaWSuLjHfgNjo5MZcqGPbdWSRB/h0UiGC5bXoB9P1H58XX8pPEmVvOkoz17DxX EIf8aHeWInTceFcwlICrOJ0P8HYungj+JRPBgZ2aKUM7SpcUBqMAOwT6gr3cbhcicu6h KJIer+7aPQxgjKHja5koXI8Om6y1NakS4/CH6TDM+WKWWkW1eDM9wB3x99sFraIo1Aeb A7Owq73plADvzOyN7McCFGBvWyx0S/V7I64VnbsGyeuw4Or5tlz0egMop5Bid8fptLl9 KEgw== X-Gm-Message-State: AHYfb5jIj83zRFLkEVN/0Y6fIwkbO1QroEXrbowaPOA9L14mWI7+Crv9 XEyVScyTnXUWC3E1DiZntBZARFR/lgIBxycyRQ== X-Received: by 10.36.37.130 with SMTP id g124mr8233607itg.114.1502293969774; Wed, 09 Aug 2017 08:52:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.159 with HTTP; Wed, 9 Aug 2017 08:52:48 -0700 (PDT) In-Reply-To: <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> References: <149874228049.6468.6647983832951662733@ietfa.amsl.com> <20170807215520.GM8146@mournblade.imrryr.org> <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> <20170808172002.GN8146@mournblade.imrryr.org> <20170808210631.GO8146@mournblade.imrryr.org> <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> From: Daniel Margolis Date: Wed, 9 Aug 2017 08:52:48 -0700 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1143cecc78f6f60556541226" Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 15:52:54 -0000 --001a1143cecc78f6f60556541226 Content-Type: multipart/alternative; boundary="001a1143cecc6b73970556541264" --001a1143cecc6b73970556541264 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 8, 2017 at 10:20 PM, Viktor Dukhovni wrote: > > > On Aug 8, 2017, at 6:24 PM, Daniel Margolis > wrote: > > > > mode=none still requires period refresh via HTTPS. So it fails the > > requirement to be able to erase all trace of STS. > > > > How do you mean? You have to continue to serve this policy until all > other previously served policies have expired; past that point you can turn > it down at will. > > No. That's the point, you can't generally just turn it out at > will without some care, or else risk creating refresh failures > during a transition period. > Sorry, can you give an example? As I stated before: > (D), I believe, is invariant in all implementations: any hypothetical > "removal" flow *will* involve serving the "removal" signal (whatever it > is--a max_age=0 policy or anything else) until the last point in time the > *old* policy was served + that policy's max_age. So (D) does not > distinguish between different "removal" options. The time period during which a domain who opts out of STS must publish the "opt out" signal--regardless of how it is expressed--is the same in all possible implementations of any opt-out signal. > When a "none" policy is cached, it is still a policy and still > subject to periodic refresh, perhaps you're suggesting to use > "none" as a synonym for "max_age=0" that still leaves us with > a usable cache time, in which case are free to use NODATA/NXDOMAIN > as that TTL is no longer requires. I'm not entirely sure I understand you. To be clear, my point was that "mode=none" can be an indicator of "don't check anything against this policy." The rest--policy caching--still applies as normal. > So the new process would be: > > * Publish a "none" policy with a comparatively short "max_age". > Call the above time "t0". > * Remove the TXT record. > Call this time "t1." Note that this step (removal of the TXT record) can only safely be done once any *previously published* policies are expired. Normally this would require that "t1 > t0 + previous_max_age" (though of course it's possible for *previous-previous policies* to have been published with overlapping max_ages). > * After some time (all previous policies expire) remove the > "none" policy. > This can also happen at "t1", if the above is observed. > Now the clients can: > > * Cache policies with empty id (not otherwise valid) > when TXT lookup returns NXDOMAIN/NODATA. Except > when policy mode is "none" in which case the cache > is immediately flushed, and stays that way unless > the TXT reappears at some point. Refresh per max_age > and proactive update attempt cycle. > * When "none" is seen with a "TXT" id, cache that as > indicated, but if TXT disappears at any time, flush > the policy then. > > This seems to work better than "max_age = 0". However, the > same cannot be said of "report", which has no clean transition > to policy removal, as dropping the TXT record still leads to > policy refresh with no end in sight, while a suddenly missing > policy (404 and the like) is not defined (deliberately IIRC > and likely correctly) to mean policy removal. > I don't understand this statement. If you have a cached policy which has expired and there is no TXT record, why would you be refreshing the policy at all? > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a1143cecc6b73970556541264 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
--001a11499ff65df8da0556560c9c-- --001a11499ff6655f050556560cc6 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMK8x525biWylzaTdKMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTE4NDIxNVoXDTE3MTAx ODE4NDIxNVowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwhqodpCO7YNSzRIz9ahzJEd2Fmnm1g9pYE2GUs5S8c6Jh JLiZkF4+kTvQVptWmuoWxWqgeIJcqZKozIYoNl06ecCUcCSo/61I+QeD061Vfl9SemzDYrK9IJ5i fsx9sXOD+c20D4Lef7F0wC9azTDs36EwgEDBcLKUef5/Y/n3TDPth8kllj0cKBitt1MC2Il95W7a MyESYucDAH7gSG/dIOGNUaIh+vLLMtRvDQVRfveOum2uUf52bF3rywDJ32dvPCDVsRJHWuhBUfaP shyNiw4d/NzDjMdc504m+GABUpF9r8203gWdhHMxPyeDIzeV7wujWEZ19c0jOcFwdpupAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFB8LoXS3E+322ae/sSMWqyi4zefEMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCeAGD8kMXY iuahwdAzZ8iUfQSAM9M8Q1JPN+jXR6gcJXagqqdjHep1KcrhYx4xvhAUurzdH0AtzjdHuS1OKOj4 OYaMUtjuSYQ6SfFdpkM6K/Ih9IklpIV4BynT4/8D6WROz5f+sQGMf22geoCWbRUsBZv7GgMIWg+1 w6F7FiSFR7NKTBRZS4y/SHv0LCtC12JHyyVQrbxrjXy2tIcrhKC0DhToxe4s9aIA/kauGUSGXyLa U55gCBKpReCTtn1b4aQIwJp9aj0wDzfqs88hyIkWKDUMW7VP+Wdk9y6qUpKwbSN9pIu3m3UmjZC7 6923PlCyPXBkAIcLrTExf7wVn9lpMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCHc0eesMRyIL4V HVGU1Y4H/3oKmJTFDaRhwNjNXqxyMDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MDkxODE0MThaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEASSNCoalryiCPNWDvr7dGUd0sv6bN6ksj gxS1QlLbAKSow6iJFqFPjYQOFpMBwwzWOsZNjQ1PebCmfiSvs1jB/BxhNY7RvEFL0CVIGlUehnL+ hpTPh+BzTpkvCtU1AfrGz1MTQnnPYP3qQQZLKzogV73GOFYkmPGwrMvoobSb6zmHB8QbLwvPvDRe S7RVvt+cKX1RgPBPwbbQVHikXos1oQyfqmah5rzSaAV4kaAKdJrGvNNPuSDx6VsmjDgWwe7Dbclm eELaBWeLBhvdNQ6GzVo0djWfUTp272xGSx6HDOrmfDEapF4EvGD6fC96no/ZZy2FKtNU98qeXBri R4orVw== --001a11499ff6655f050556560cc6-- From nobody Wed Aug 9 11:33:15 2017 Return-Path: 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 02B5F13232D for ; Wed, 9 Aug 2017 11:33:14 -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] 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 psaQe3fB8BJf for ; Wed, 9 Aug 2017 11:33:12 -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 2A678131CD7 for ; Wed, 9 Aug 2017 11:33:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 243307A3309; Wed, 9 Aug 2017 18:33:11 +0000 (UTC) Date: Wed, 9 Aug 2017 18:33:11 +0000 From: Viktor Dukhovni To: uta@ietf.org Message-ID: <20170809183310.GU8146@mournblade.imrryr.org> Reply-To: uta@ietf.org References: <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> <20170808172002.GN8146@mournblade.imrryr.org> <20170808210631.GO8146@mournblade.imrryr.org> <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> <20170809174827.GQ8146@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 18:33:14 -0000 On Wed, Aug 09, 2017 at 11:14:16AM -0700, Daniel Margolis wrote: > > No, with "none" the policy refresh can stop (and cache flushed) as > > soon as NXDOMAIN/NODATA is seen for the TXT lookup. The same is > > not true for "report", to avoid downgrade attacks. > > > > That's not true; once a policy expires, it can be flushed from the cache > (as it can no longer safely be used). You're missing the point, a robust STS implementation will rarely encounter an expired policy because it will periodically refresh policies (for domains to which email is still being sent) *before* they are due to expire. When an unexpired policy is being refreshed, there should not be mysterious refresh failures. So if the policy is not yet deleted, its lifetime will be again extended by the published "max_age". What signal *securely* indicates actual deletion of an unexpired policy? (Not the DNS TXT record, which just expedites refresh). > > Because the TXT record presence/absense is *insecure* (no DNSSEC > > or else we'd be doing DANE!). Therefore the TXT record must ONLY > > be used: > > > > 1. To signal initial policy presence when none is cached. > > 2. To signal expedited policy refresh when the id changes. > > 3. [New] To signal policy removal when the policy is "none" > > and the TXT record "disappears". > > 4. [New] Conversely to signal policy removal when the policy > > transitions to "none" and was cached in the absence of a > > TXT record (still absent). > > Can you point to what language in the current draft suggests that the > behavior with respect to policy refreshing differs if you have a cached > policy versus if you do not? I am still not understanding what difference > you see here. The draft under-specifies the requirements for getting refresh right. Let's forget the draft and think logically, then fix the draft. When a policy is cached, it should be easily downgraded to no policy. Therefore a signal forged DNS response MUST NOT flush the cache. STS is subject to downgrade at first contact, but is supposed to be resilient there-after, so long as mail flow to the domain happens often enough. Therefore, already cached policies are refreshed periodically (for domains that receive some mail) regardless of the TXT record, and the TXT record is only there to *expedite* refresh and signal cold-start policy presence. > > Mere removal of the TXT record is *not* sufficient to stop policy > > refresh. Recall that policy refresh will typically happen > > before the policy is expired (more robust continuity) and must > > not at that time be subject to DNS downgrade. > > I believe this is your mistake. While I agree that one should try to > refresh a policy prior to expiration, "refresh a policy" means checking the > TXT record. Sorry that means STS is trivial to downgrade to cold-start. If that's the spec, I'm not implementing it. > Your first sentence ("mere removal of the TXT record...") does not follow > from your second sentence. > > There's zero security advantage in ignoring the TXT record and going > straight to HTTPS, since HTTPS also relies upon the (insecure) DNS > resolution. No it does not. That's the whole point of HTTPS. > As a result, it makes no real sense to refresh the policy if > the TXT does not say to do it. I'm afraid you're missing the consequent attack, and that's why we've failed to reach closure on this issue. > A sender who implements this will appear to > be compliant with the draft--there's no real harm from doing this, aside > from maybe excessive HTTPS requests--but there's no great reason to do this > unless you think attackers can only attack the TXT record and not the > CNAME/A for the policy host. Forged CNAME/A do not downgrade the policy. They just cause a (noisy in the mail logs) failure to do the policy refresh, which will be retried, and hence the attack must stay on path for a good fraction of the policy lifetime (some time back I proposed refreshing the policy at 0.5 max_age, 0.75 max_age, ... but no less than the larger of 0.5 max_age and say 1 hour; search the list archive). STS policy refresh must not be suppressed by forged DNS replies. Only first contact is inevitably subject to DNS downgrade. -- Viktor. From nobody Wed Aug 9 17:06:01 2017 Return-Path: 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 8D585126DD9 for ; Wed, 9 Aug 2017 17:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 oC5sU62BaWzU for ; Wed, 9 Aug 2017 17:05:54 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542B81324C7 for ; Wed, 9 Aug 2017 17:05:54 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id 77so5702053itj.1 for ; Wed, 09 Aug 2017 17:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Vx4IUiU6VqFulwPfPEJ5qVFZeTGVmM+wIoG5CrodqJo=; b=PdL2cJxxtyge0DZ/FidVtSG0/zQxFI5ZeGhNVSErPyNUYMWHhCdCjjfPH68q9JsYyx fZSAR6d0fsRLj3wJJO8YrOctyex6NmpNT5E+QqtdhFXIGFndgfN4qTtPH1xvOcceIWKA 43yhLbkm8R1xFVnaxXDplhev6CYUulpLuJeKnvhQ0Q+ify+7Q1VpOqgcx/dKjL0/GRJd BWscmRcQrXlyFhRuvqqhFfMbqIVdMJxggct/T/eS5bATDtR34T7Ze5tV/xYE2FF+UW2g a7itrFeHDgau42Ec2YZmPBNc4O9ALeeSo+mBwZorJrX2zS+EB3qqFaSnDbPbYbfWUlK2 fCsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Vx4IUiU6VqFulwPfPEJ5qVFZeTGVmM+wIoG5CrodqJo=; b=D4W5ebDkqZf/Yztd3jlFQjJv/6TCQpc5M7rzI54pv/ALlNyns3YtJspwsvNqbvn1W0 ekuguqU+fIG4nI2Lxfcy4jyX9AGOSaXVy8fVsPw8vPMHMDQR1Z19BZgW86qRdEsC7wpC +yOg/SiNaFSkQ/VU3zQsIkGIhOnantGZIIUdetDjpQgdSwTxEbVHIz7QUhiAGGu26/Eq CkSrH05vRSj3aOuXl5x3untI1R29duR5/rvvLh56AHt3ypneCxgJQdwL8kvWhI/XJcVO yyP/Hvuz2+NUllbY14Aueihx4xBd1acXfRL6T9Db6Kesq/4yq6H7Hd/TTMi73JFjyEtD P6mQ== X-Gm-Message-State: AIVw110xcg/GBY2K9BJHvg5bI1b17+UQEAoT1fnkiB6wX4CPRBRauES/ lFkzxUKnj7Wv3EeOUyKlZG8/7bDoaBGDJmM= X-Received: by 10.36.172.65 with SMTP id m1mr8714300iti.118.1502323552420; Wed, 09 Aug 2017 17:05:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.159 with HTTP; Wed, 9 Aug 2017 17:05:51 -0700 (PDT) In-Reply-To: <20170809183310.GU8146@mournblade.imrryr.org> References: <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> <20170808172002.GN8146@mournblade.imrryr.org> <20170808210631.GO8146@mournblade.imrryr.org> <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> <20170809174827.GQ8146@mournblade.imrryr.org> <20170809183310.GU8146@mournblade.imrryr.org> From: Daniel Margolis Date: Wed, 9 Aug 2017 17:05:51 -0700 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c1fc808b7b28805565af568" Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 00:05:57 -0000 --94eb2c1fc808b7b28805565af568 Content-Type: multipart/alternative; boundary="94eb2c1fc808aed7d605565af549" --94eb2c1fc808aed7d605565af549 Content-Type: text/plain; charset="UTF-8" For everyone else, Viktor and I were able to talk face-to-face for a half hour and sort this out. Much easier. :) To skip the reasoning (unless people have questions), our conclusions in terms of changes: 1. Implement a "none" mode (along side "enforce" and "report"), which does exactly what it sounds like (i.e. don't report, don't enforce) 2. We suggest in the Security Considerations that MTAs proactively refresh policies long before expiration; we should additionally suggest that when proactive refreshes fail (for any reason--i.e. DNS records not found, HTTPS connect fails), MTAs should also be noisy about this (i.e. log it to their owner and, if possible, send a TLSRPT report), *except* if the existing cached policy has a "none" mode. 3. Finally, and unrelated to this discussion but arising from it, if the TXT record does not exist (or does not parse), senders who are doing a proactive refresh should probably bail on the policy retrieval (i.e., they should not go straight to policy.example.com just because they have a cached policy); this seems like unexpected behavior (at least to me). With the above, the guidance to "downgrade" from STS is as follows: 1. Publish a new policy (as with any new policy, updating the TXT record's ID) with mode=none. 2. After all pre-existing policies have expired (e.g. the time of step 1 plus the existing policy's max_age), safely remove the TXT record and current policy. I will incorporate this into draft 08. Thanks for the discussion. On Wed, Aug 9, 2017 at 11:33 AM, Viktor Dukhovni wrote: > On Wed, Aug 09, 2017 at 11:14:16AM -0700, Daniel Margolis wrote: > > > > No, with "none" the policy refresh can stop (and cache flushed) as > > > soon as NXDOMAIN/NODATA is seen for the TXT lookup. The same is > > > not true for "report", to avoid downgrade attacks. > > > > > > > That's not true; once a policy expires, it can be flushed from the cache > > (as it can no longer safely be used). > > You're missing the point, a robust STS implementation will rarely > encounter an expired policy because it will periodically refresh > policies (for domains to which email is still being sent) *before* > they are due to expire. > > When an unexpired policy is being refreshed, there should not be > mysterious refresh failures. So if the policy is not yet deleted, > its lifetime will be again extended by the published "max_age". > > What signal *securely* indicates actual deletion of an unexpired > policy? (Not the DNS TXT record, which just expedites refresh). > > > > Because the TXT record presence/absense is *insecure* (no DNSSEC > > > or else we'd be doing DANE!). Therefore the TXT record must ONLY > > > be used: > > > > > > 1. To signal initial policy presence when none is cached. > > > 2. To signal expedited policy refresh when the id changes. > > > 3. [New] To signal policy removal when the policy is "none" > > > and the TXT record "disappears". > > > 4. [New] Conversely to signal policy removal when the policy > > > transitions to "none" and was cached in the absence of a > > > TXT record (still absent). > > > > Can you point to what language in the current draft suggests that the > > behavior with respect to policy refreshing differs if you have a cached > > policy versus if you do not? I am still not understanding what difference > > you see here. > > The draft under-specifies the requirements for getting refresh > right. Let's forget the draft and think logically, then fix > the draft. > > When a policy is cached, it should be easily downgraded to no > policy. Therefore a signal forged DNS response MUST NOT flush > the cache. STS is subject to downgrade at first contact, but > is supposed to be resilient there-after, so long as mail flow > to the domain happens often enough. > > Therefore, already cached policies are refreshed periodically (for > domains that receive some mail) regardless of the TXT record, and > the TXT record is only there to *expedite* refresh and signal > cold-start policy presence. > > > > Mere removal of the TXT record is *not* sufficient to stop policy > > > refresh. Recall that policy refresh will typically happen > > > before the policy is expired (more robust continuity) and must > > > not at that time be subject to DNS downgrade. > > > > I believe this is your mistake. While I agree that one should try to > > refresh a policy prior to expiration, "refresh a policy" means checking > the > > TXT record. > > Sorry that means STS is trivial to downgrade to cold-start. > If that's the spec, I'm not implementing it. > > > Your first sentence ("mere removal of the TXT record...") does not follow > > from your second sentence. > > > > There's zero security advantage in ignoring the TXT record and going > > straight to HTTPS, since HTTPS also relies upon the (insecure) DNS > > resolution. > > No it does not. That's the whole point of HTTPS. > > > As a result, it makes no real sense to refresh the policy if > > the TXT does not say to do it. > > I'm afraid you're missing the consequent attack, and that's why > we've failed to reach closure on this issue. > > > A sender who implements this will appear to > > be compliant with the draft--there's no real harm from doing this, aside > > from maybe excessive HTTPS requests--but there's no great reason to do > this > > unless you think attackers can only attack the TXT record and not the > > CNAME/A for the policy host. > > Forged CNAME/A do not downgrade the policy. They just cause a > (noisy in the mail logs) failure to do the policy refresh, which > will be retried, and hence the attack must stay on path for a good > fraction of the policy lifetime (some time back I proposed refreshing > the policy at 0.5 max_age, 0.75 max_age, ... but no less than the > larger of 0.5 max_age and say 1 hour; search the list archive). > > STS policy refresh must not be suppressed by forged DNS replies. > Only first contact is inevitably subject to DNS downgrade. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --94eb2c1fc808aed7d605565af549 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For everyone else, Viktor and I= were able to talk face-to-face for a half hour and sort this out. Much eas= ier. :)

To skip the reasoning (unless people have questions), our conclusions in = terms of changes:

1. Implement a "none" mode (along side "enforce&= quot; and "report"), which does exactly what it sounds like (i.e.= don't report, don't enforce)
2. We= suggest in the Security Considerations that MTAs proactively refresh polic= ies long before expiration; we should additionally suggest that when proact= ive refreshes fail (for any reason--i.e. DNS records not found, HTTPS conne= ct fails), MTAs should also be noisy about this (i.e. log it to their owner= and, if possible, send a TLSRPT report), except=C2=A0if the existin= g cached policy has a "none" mode.
3. Finally, and unrelated to this discussion but arising from it, if the = TXT record does not exist (or does not parse), senders who are doing a proa= ctive refresh should probably bail on the policy retrieval (i.e., they shou= ld not go straight to policy.example.= com just because they have a cached policy); this seems like unexpected= behavior (at least to me).=C2=A0

With the above, the guidance to "downgrade= " from STS is as follows:

1. Publish a new policy (as with any new policy, u= pdating the TXT record's ID) with mode=3Dnone.=C2=A0
2. After all pre-existing policies have expired (e.g. the tim= e of step 1 plus the existing policy's max_age), safely remove the TXT = record and current policy.

I will incorporate this into draft 08.

Thanks for the discus= sion.=C2=A0

= On Wed, Aug 9, 2017 at 11:33 AM, Viktor Dukhovni <ietf-dane@dukhovni.= org> wrote:
On Wed, Aug 09, 2017 at 11:14:16AM -0700, Daniel Margolis wrote:

> > No, with "none" the policy refresh can stop (and cache = flushed) as
> > soon as NXDOMAIN/NODATA is seen for the TXT lookup.=C2=A0 The sam= e is
> > not true for "report", to avoid downgrade attacks.
> >
>
> That's not true; once a policy expires, it can be flushed from the= cache
> (as it can no longer safely be used).

You're missing the point, a robust STS implementation will rarel= y
encounter an expired policy because it will periodically refresh
policies (for domains to which email is still being sent) *before*
they are due to expire.

When an unexpired policy is being refreshed, there should not be
mysterious refresh failures.=C2=A0 So if the policy is not yet deleted,
its lifetime will be again extended by the published "max_age".
What signal *securely* indicates actual deletion of an unexpired
policy?=C2=A0 (Not the DNS TXT record, which just expedites refresh).

> > Because the TXT record presence/absense is *insecure* (no DNSSEC<= br> > > or else we'd be doing DANE!).=C2=A0 Therefore the TXT record = must ONLY
> > be used:
> >
> >=C2=A0 =C2=A0 =C2=A01.=C2=A0 To signal initial policy presence whe= n none is cached.
> >=C2=A0 =C2=A0 =C2=A02.=C2=A0 To signal expedited policy refresh wh= en the id changes.
> >=C2=A0 =C2=A0 =C2=A03.=C2=A0 [New] To signal policy removal when t= he policy is "none"
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the TXT record "disappe= ars".
> >=C2=A0 =C2=A0 =C2=A04.=C2=A0 [New] Conversely to signal policy rem= oval when the policy
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transitions to "none" = and was cached in the absence of a
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TXT record (still absent).
>
> Can you point to what language in the current draft suggests that the<= br> > behavior with respect to policy refreshing differs if you have a cache= d
> policy versus if you do not? I am still not understanding what differe= nce
> you see here.

The draft under-specifies the requirements for getting refresh
right.=C2=A0 Let's forget the draft and think logically, then fix
the draft.

When a policy is cached, it should be easily downgraded to no
policy.=C2=A0 Therefore a signal forged DNS response MUST NOT flush
the cache.=C2=A0 STS is subject to downgrade at first contact, but
is supposed to be resilient there-after, so long as mail flow
to the domain happens often enough.

Therefore, already cached policies are refreshed periodically (for
domains that receive some mail) regardless of the TXT record, and
the TXT record is only there to *expedite* refresh and signal
cold-start policy presence.

> > Mere removal of the TXT record is *not* sufficient to stop policy=
> > refresh.=C2=A0 Recall that policy refresh will typically happen > > before the policy is expired (more robust continuity) and must > > not at that time be subject to DNS downgrade.
>
> I believe this is your mistake. While I agree that one should try to > refresh a policy prior to expiration, "refresh a policy" mea= ns checking the
> TXT record.

Sorry that means STS is trivial to downgrade to cold-start.
If that's the spec, I'm not implementing it.

> Your first sentence ("mere removal of the TXT record...") do= es not follow
> from your second sentence.
>
> There's zero security advantage in ignoring the TXT record and goi= ng
> straight to HTTPS, since HTTPS also relies upon the (insecure) DNS
> resolution.

No it does not.=C2=A0 That's the whole point of HTTPS.

> As a result, it makes no real sense to refresh the policy if
> the TXT does not say to do it.

I'm afraid you're missing the consequent attack, and that= 9;s why
we've failed to reach closure on this issue.

> A sender who implements this will appear to
> be compliant with the draft--there's no real harm from doing this,= aside
> from maybe excessive HTTPS requests--but there's no great reason t= o do this
> unless you think attackers can only attack the TXT record and not the<= br> > CNAME/A for the policy host.

Forged CNAME/A do not downgrade the policy.=C2=A0 They just cause a<= br> (noisy in the mail logs) failure to do the policy refresh, which
will be retried, and hence the attack must stay on path for a good
fraction of the policy lifetime (some time back I proposed refreshing
the policy at 0.5 max_age, 0.75 max_age, ... but no less than the
larger of 0.5 max_age and say 1 hour; search the list archive).

STS policy refresh must not be suppressed by forged DNS replies.
Only first contact is inevitably subject to DNS downgrade.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--94eb2c1fc808aed7d605565af549-- --94eb2c1fc808b7b28805565af568 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMK8x525biWylzaTdKMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTE4NDIxNVoXDTE3MTAx ODE4NDIxNVowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwhqodpCO7YNSzRIz9ahzJEd2Fmnm1g9pYE2GUs5S8c6Jh JLiZkF4+kTvQVptWmuoWxWqgeIJcqZKozIYoNl06ecCUcCSo/61I+QeD061Vfl9SemzDYrK9IJ5i fsx9sXOD+c20D4Lef7F0wC9azTDs36EwgEDBcLKUef5/Y/n3TDPth8kllj0cKBitt1MC2Il95W7a MyESYucDAH7gSG/dIOGNUaIh+vLLMtRvDQVRfveOum2uUf52bF3rywDJ32dvPCDVsRJHWuhBUfaP shyNiw4d/NzDjMdc504m+GABUpF9r8203gWdhHMxPyeDIzeV7wujWEZ19c0jOcFwdpupAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFB8LoXS3E+322ae/sSMWqyi4zefEMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCeAGD8kMXY iuahwdAzZ8iUfQSAM9M8Q1JPN+jXR6gcJXagqqdjHep1KcrhYx4xvhAUurzdH0AtzjdHuS1OKOj4 OYaMUtjuSYQ6SfFdpkM6K/Ih9IklpIV4BynT4/8D6WROz5f+sQGMf22geoCWbRUsBZv7GgMIWg+1 w6F7FiSFR7NKTBRZS4y/SHv0LCtC12JHyyVQrbxrjXy2tIcrhKC0DhToxe4s9aIA/kauGUSGXyLa U55gCBKpReCTtn1b4aQIwJp9aj0wDzfqs88hyIkWKDUMW7VP+Wdk9y6qUpKwbSN9pIu3m3UmjZC7 6923PlCyPXBkAIcLrTExf7wVn9lpMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBH3mcwv5006+rj JxsKciYnGi4sxXvKXPBZEqxrmvMTyTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MTAwMDA1NTNaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAVoP98ehumKoJCQAKf1LCGOs3f5IEQqGz syA8K8FWD3cQCN4mZB3sF8MpNgNL5WpX6y3eVDenzqwjyvenGHVMviXJj4aRMwtY59JlZzFCdX8T 5yZmjYMBkF0QsmWvJ+JHRkFaWUMUGrWUKCHqg+GsTL7VrbF/nqEnSJb3n1wD8zgd3E8281OlvV2U rZOj3dPaCzjKuVzlOrkfKDIovx22BraqjH8C++X9iHAyx03V0qdULOkUj5qhhahCLsAHdG+FU/Ew JGHj5Ds/Mvl80n0ikSIlkvPeip75734iTKECPA6vhGsxe723qPHFzaBjnTmNMTSZUhivMJgyNzz3 AL9I8Q== --94eb2c1fc808b7b28805565af568-- From nobody Wed Aug 9 21:05:05 2017 Return-Path: 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 304DD13254B for ; Wed, 9 Aug 2017 21:05:04 -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] 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 eOJ7WwittTmL for ; Wed, 9 Aug 2017 21:05:02 -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 8F614132545 for ; Wed, 9 Aug 2017 21:05:02 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (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 D28E47A3302 for ; Thu, 10 Aug 2017 04:05:00 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 10 Aug 2017 00:05:24 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: <6050C765-D3FB-4037-930A-43FE00A5CB89@dukhovni.org> References: <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> <20170808172002.GN8146@mournblade.imrryr.org> <20170808210631.GO8146@mournblade.imrryr.org> <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> <20170809174827.GQ8146@mournblade.imrryr.org> <20170809183310.GU8146@mournblade.imrryr.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 04:05:04 -0000 > On Aug 9, 2017, at 8:05 PM, Daniel Margolis = wrote: >=20 > 1. Publish a new policy (as with any new policy, updating the TXT = record's ID) with mode=3Dnone.=20 > 2. After all pre-existing policies have expired (e.g. the time of step = 1 plus the existing policy's max_age), safely remove the TXT record and = current policy. One corner of the problem space we did not consider: * I'd like to be able to delete the "none" policy promptly, by = noticing a removed TXT record. * So it would be nice to be able to remove the TXT record promptly. * However, you're suggesting that policy refresh should not happen when the TXT record is absent. * This implies that the TXT record removal must wait until everyone's max_age has expired. * Consequently "none" policies will linger in caches needlessly long. If instead NXDOMAIN/NODATA triggers a policy refresh (new logically empty id) then senders can flush "none" policies as soon as they also see the TXT record deleted, and that deletion can reduce the number of required DNS changes. Instead of modifying the TXT to trigger refresh and later deleting it, it can be deleted right away. The only complication is that deleted TXT is then, for senders with a cached policy other than none, just another TXT value (NULL if using a SQL database or similar) that triggers refresh and cached policies can then have a NULL id, but a "none" policy with a NULL id can be deleted right away. Please think it over... --=20 Viktor.= From nobody Thu Aug 10 10:02:49 2017 Return-Path: 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 BEE33132190 for ; Thu, 10 Aug 2017 10:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 UbzAgQuGYtGy for ; Thu, 10 Aug 2017 10:02:45 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3EC131CEA for ; Thu, 10 Aug 2017 10:02:45 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id 76so16427781ith.0 for ; Thu, 10 Aug 2017 10:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Rpc1qXdxhd3ahNd2Ym2ZwJZLomrUKnqiRk0jFifmHEc=; b=vyFKt67mQXZZZ61I6yYqALIUeK6kKPAIHnOeA1ir700iET/x/3gRdSDTxoW623I9A7 bOEs6JtjK8PJX6o+Yb5clcXhrd3KnNY3KfmGZcduXEFpti9gVM33uamyVOxeM63OmTjM i2hXaCnW2kQeHA/ZWKPZWbEPiewWMCw9ZRSocW1qctY4Wkam+hVGLfbYrHpRLbxqBGk+ jbMpa8/Hxr20520MfaFNodTYhH4GtOqwnvTWADl6gv1q+AbhEiAFEvY0vGy2plXH74Yn tWuOUU6KQvkehLZxyfwJC7bDg1sWYG9A5ec91wUH+jCq7/UZyFEPYlCjpWzT0yuo8YFk Mpqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Rpc1qXdxhd3ahNd2Ym2ZwJZLomrUKnqiRk0jFifmHEc=; b=NWnexS/YB3CJZEdRnA0ThTIapqsmuKq+zRGQJlu6BzQHUiIwVmBWOFPKW53XoX1KwE DEOuwZIL3r5kY/L1Rg2O/SbwpwRIqJTT/W/jt9AGo9gC3OhZqt/MVdRWFPdT9QaVk8Ox 575svsPq5P5NLpvJB5sLu9XX5Xm81j49r7UiifSkFGViH8vK852V8zCPM52bMq8Gwz3w 4w0J55rUb8fz5QAquRTROTpg6qd4wuqKVmVepEip9lwFXagyVe2GdHO7I+wAPSB7ngar ocPlyDYpR7lv5xtP/3GhZoI0nNMQ0ppPRk3tVCMtNmRvnUOtSJ8vCR78GO+GNlKhqZQm isbg== X-Gm-Message-State: AIVw11080r029ZD5F+VgYf3n0GTLA7MQ3g+Tq2Esq07ACWIVouGG4FLp wZ3fjvI3yo9aulSzwFYkothQi32bNL/Z+rI= X-Received: by 10.36.172.65 with SMTP id m1mr10993164iti.118.1502384562691; Thu, 10 Aug 2017 10:02:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.159 with HTTP; Thu, 10 Aug 2017 10:02:41 -0700 (PDT) In-Reply-To: <6050C765-D3FB-4037-930A-43FE00A5CB89@dukhovni.org> References: <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> <20170808172002.GN8146@mournblade.imrryr.org> <20170808210631.GO8146@mournblade.imrryr.org> <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> <20170809174827.GQ8146@mournblade.imrryr.org> <20170809183310.GU8146@mournblade.imrryr.org> <6050C765-D3FB-4037-930A-43FE00A5CB89@dukhovni.org> From: Daniel Margolis Date: Thu, 10 Aug 2017 10:02:41 -0700 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c1fc808497ee90556692af2" Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 17:02:48 -0000 --94eb2c1fc808497ee90556692af2 Content-Type: multipart/alternative; boundary="94eb2c1fc8082d89100556692a34" --94eb2c1fc8082d89100556692a34 Content-Type: text/plain; charset="UTF-8" It's certainly doable. As you might have guessed, I'm vaguely attached to the idea that "not having a TXT means you don't have a policy." I don't really know _why_ I'm attached to this--functionally, your suggested behavior is about the same in terms of implementation--but it feels a bit funny to me to treat _not_ having a TXT record as significant _if_ you previously had one. (Of course, if people don't know you previously had one, they don't need to know the absence is "significant", so this may be silly to worry about.) Also, note that this slightly oddifies the _DNS_ caching story; the NXDOMAIN TTL is derived from the SOA record, so unlike a "real" TXT record, the TTL on the "null" record comes (obviously) from a different place, which is a little bit (but only a little bit) weird in terms of usability of the configuration parameters, so to speak. If anyone else has read this far on the thread, I'm happy to get feedback on this proposal from others on the list. On Wed, Aug 9, 2017 at 9:05 PM, Viktor Dukhovni wrote: > > > On Aug 9, 2017, at 8:05 PM, Daniel Margolis > wrote: > > > > 1. Publish a new policy (as with any new policy, updating the TXT > record's ID) with mode=none. > > 2. After all pre-existing policies have expired (e.g. the time of step 1 > plus the existing policy's max_age), safely remove the TXT record and > current policy. > > One corner of the problem space we did not consider: > > * I'd like to be able to delete the "none" policy promptly, by noticing > a removed TXT record. > > * So it would be nice to be able to remove the TXT record promptly. > > * However, you're suggesting that policy refresh should not happen > when the TXT record is absent. > > * This implies that the TXT record removal must wait until everyone's > max_age has expired. > > * Consequently "none" policies will linger in caches needlessly long. > > If instead NXDOMAIN/NODATA triggers a policy refresh (new logically > empty id) then senders can flush "none" policies as soon as they > also see the TXT record deleted, and that deletion can reduce the > number of required DNS changes. Instead of modifying the TXT to > trigger refresh and later deleting it, it can be deleted right > away. > > The only complication is that deleted TXT is then, for senders with > a cached policy other than none, just another TXT value (NULL if > using a SQL database or similar) that triggers refresh and cached > policies can then have a NULL id, but a "none" policy with a NULL > id can be deleted right away. > > Please think it over... > > -- > Viktor. > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --94eb2c1fc8082d89100556692a34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's certainly doable. As you might have guessed, I= 9;m vaguely attached to the idea that "not having a TXT means you don&= #39;t have a policy." I don't really know _why_ I'm attached t= o this--functionally, your suggested behavior is about the same in terms of= implementation--but it feels a bit funny to me to treat _not_ having a TXT= record as significant _if_ you previously had one. (Of course, if people d= on't know you previously had one, they don't need to know the absen= ce is "significant", so this may be silly to worry about.)
Also, note that this slightly oddifies the _DNS_ caching story= ; the NXDOMAIN TTL is derived from the SOA record, so unlike a "real&q= uot; TXT record, the TTL on the "null" record comes (obviously) f= rom a different place, which is a little bit (but only a little bit) weird = in terms of usability of the configuration parameters, so to speak.

If anyone else has read this far on the thread, I'm hap= py to get feedback on this proposal from others on the list.=C2=A0

On Wed, = Aug 9, 2017 at 9:05 PM, Viktor Dukhovni <ietf-dane@dukhovni.org&g= t; wrote:

> On Aug 9, 2017, at 8:05 PM, Daniel Margolis <dmargolis@google.com> wrote:
>
> 1. Publish a new policy (as with any new policy, updating the TXT reco= rd's ID) with mode=3Dnone.
> 2. After all pre-existing policies have expired (e.g. the time of step= 1 plus the existing policy's max_age), safely remove the TXT record an= d current policy.

One corner of the problem space we did not consider:

=C2=A0 * I'd like to be able to delete the "none" policy prom= ptly, by noticing
=C2=A0 =C2=A0 a removed TXT record.

=C2=A0 * So it would be nice to be able to remove the TXT record promptly.<= br>
=C2=A0 * However, you're suggesting that policy refresh should not happ= en
=C2=A0 =C2=A0 when the TXT record is absent.

=C2=A0 * This implies that the TXT record removal must wait until everyone&= #39;s
=C2=A0 =C2=A0 max_age has expired.

=C2=A0 * Consequently "none" policies will linger in caches needl= essly long.

If instead NXDOMAIN/NODATA triggers a policy refresh (new logically
empty id) then senders can flush "none" policies as soon as they<= br> also see the TXT record deleted, and that deletion can reduce the
number of required DNS changes.=C2=A0 Instead of modifying the TXT to
trigger refresh and later deleting it, it can be deleted right
away.

The only complication is that deleted TXT is then, for senders with
a cached policy other than none, just another TXT value (NULL if
using a SQL database or similar) that triggers refresh and cached
policies can then have a NULL id, but a "none" policy with a NULL=
id can be deleted right away.

Please think it over...

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--94eb2c1fc8082d89100556692a34-- --94eb2c1fc808497ee90556692af2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMK8x525biWylzaTdKMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTE4NDIxNVoXDTE3MTAx ODE4NDIxNVowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwhqodpCO7YNSzRIz9ahzJEd2Fmnm1g9pYE2GUs5S8c6Jh JLiZkF4+kTvQVptWmuoWxWqgeIJcqZKozIYoNl06ecCUcCSo/61I+QeD061Vfl9SemzDYrK9IJ5i fsx9sXOD+c20D4Lef7F0wC9azTDs36EwgEDBcLKUef5/Y/n3TDPth8kllj0cKBitt1MC2Il95W7a MyESYucDAH7gSG/dIOGNUaIh+vLLMtRvDQVRfveOum2uUf52bF3rywDJ32dvPCDVsRJHWuhBUfaP shyNiw4d/NzDjMdc504m+GABUpF9r8203gWdhHMxPyeDIzeV7wujWEZ19c0jOcFwdpupAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFB8LoXS3E+322ae/sSMWqyi4zefEMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCeAGD8kMXY iuahwdAzZ8iUfQSAM9M8Q1JPN+jXR6gcJXagqqdjHep1KcrhYx4xvhAUurzdH0AtzjdHuS1OKOj4 OYaMUtjuSYQ6SfFdpkM6K/Ih9IklpIV4BynT4/8D6WROz5f+sQGMf22geoCWbRUsBZv7GgMIWg+1 w6F7FiSFR7NKTBRZS4y/SHv0LCtC12JHyyVQrbxrjXy2tIcrhKC0DhToxe4s9aIA/kauGUSGXyLa U55gCBKpReCTtn1b4aQIwJp9aj0wDzfqs88hyIkWKDUMW7VP+Wdk9y6qUpKwbSN9pIu3m3UmjZC7 6923PlCyPXBkAIcLrTExf7wVn9lpMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCyhuOTxll3HZ0O j6bUPu8pDumGU+Ip4GGbc5kLpKUoEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MTAxNzAyNDRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAp0R1K2sAOZJU9kcvSsR3j6iGi5jIcmE8 2Xp+cAuc3JsK2v8ttjcPaU3RsIwtOROx951xoSuax4UGC8MqNyzsFs4V61Dcre0UlkM5O67P7lDk s5i1LOD0v0J90CBzNKbmqRE5Re2K8+R6DvUcI1pB1xu23/KFK6km/jTSXNqnElEkrK6mhVxlPGGY Qrd9SSXZmQoIV2OLDD4jWJ/ZdudBuWWQQddkcgeL/U9Z1pwImiATLigL+dr+SQPjKWbL4PyguKDp nf/KrakUM2ADrdeF4fCmalveT9QtJx/eLWn88qcP8C/xEO3qUFQPdH6MdWTQGRyc4OE1xB+6kThX rbyA7g== --94eb2c1fc808497ee90556692af2-- From nobody Thu Aug 10 10:47:01 2017 Return-Path: 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 0B2AC1323B6 for ; Thu, 10 Aug 2017 10:47:00 -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] 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 JaJ1lWNsAFwt for ; Thu, 10 Aug 2017 10:46:58 -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 4976D126CC4 for ; Thu, 10 Aug 2017 10:46:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DFDBD7A3309; Thu, 10 Aug 2017 17:46:56 +0000 (UTC) Date: Thu, 10 Aug 2017 17:46:56 +0000 From: Viktor Dukhovni To: uta@ietf.org Message-ID: <20170810174656.GX8146@mournblade.imrryr.org> Reply-To: uta@ietf.org References: <20170808210631.GO8146@mournblade.imrryr.org> <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> <20170809174827.GQ8146@mournblade.imrryr.org> <20170809183310.GU8146@mournblade.imrryr.org> <6050C765-D3FB-4037-930A-43FE00A5CB89@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 17:47:00 -0000 On Thu, Aug 10, 2017 at 10:02:41AM -0700, Daniel Margolis wrote: > Also, note that this slightly oddifies the _DNS_ caching story; the > NXDOMAIN TTL is derived from the SOA record, so unlike a "real" TXT record, > the TTL on the "null" record comes (obviously) from a different place, > which is a little bit (but only a little bit) weird in terms of usability > of the configuration parameters, so to speak. Yes, the negative TTL is from the SOA, but the TXT record TTL is not something the sending MTA has to concern itself with, the TTLs are handled transparently by the resolver. The difference might plausibly matter to the administrator of the receiving domain, who might want to adjust the negative TTL, but he might do that regardless of whether we refresh cached (!= "none") policies even when the TXT is not present. That is, if you want a shorter or longer negative TTL, you would do tune it regardless of how we decide this question. > If anyone else has read this far on the thread, I'm happy to get feedback > on this proposal from others on the list. Yes, please! -- Viktor. From nobody Thu Aug 10 11:28:58 2017 Return-Path: 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 05C0D132405 for ; Thu, 10 Aug 2017 11:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Koj7ZJwyZDDi for ; Thu, 10 Aug 2017 11:28:55 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE44F1323A4 for ; Thu, 10 Aug 2017 11:28:54 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id o9so12765598iod.1 for ; Thu, 10 Aug 2017 11:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=VXalmUdq9+ALPKAlb+Wk9Z9o3W5Bd5OaI2WeHuqpwFk=; b=kfW+eu6547YRceIDmt/K8bBQCP1SXb86gCu12Ie4am2Nj84L7zDr0lAZ4n9fp8OuzY oI1Q0UpaURfNUEeFkW+w3Ixf8hW/0b4jjVZdPdN4eNCPFAlQ87timFDBPvy+ZrdsaptW INpf8+479zL8/Kvh9o1qriZcZQn2mbM5lrkqUlw3f989YRDHUm5dcNynRKW3M0I8skFF k9WzfPV6fUnUPhrdA9m08Yh0/mzPFSdZTDTGoihSG+XoA7Znjz9QPU/+aKhENvh2/rS3 fQweNcV/1drkeUAgrjnM8+ingGhEaMeYU97vw4IqbUCwGDxZjlIiGMMICa6ZjfZ2WwUU leyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=VXalmUdq9+ALPKAlb+Wk9Z9o3W5Bd5OaI2WeHuqpwFk=; b=RCMzjrHas9NKQGSTKmnKsxaex9PaLVw33731i4RypTFf1oW+Z+OgaPNK3aKjNcoIhe KujIdue5mGJ1nL1ureiKTac2/xvKP12NOxXxnp4R6z3nSWnYdtvcxzsEseIOL+Ydk0KY R7Yv0lERWcgsEk6ObK0Gx98LpHoZwRZWZPHTe4eCZOYznvCCY13EOjDxksJcmkg1UmxF vZnoNBUiesrE8PrJcRacOX5jVG3Fs2eI8Ol33ta49FZ+hfR89HmGsWm7BWa4K4LNAdGv 18H17IY1YQmE0XOgNWK1flVPNRN/4c3km5Rlcstq7NeqWI+LSSGW/CgLEsnZiKFBoXT8 ry8g== X-Gm-Message-State: AHYfb5jljodk+7MZszd7+3UhayzQ0QD4DrKLCIQZQMPBT3JHJOrzAeXe BbKD0x6YLpLEuBzKIYZCn5ggLW4GmjsBp8I= X-Received: by 10.107.134.87 with SMTP id i84mr10584870iod.293.1502389733395; Thu, 10 Aug 2017 11:28:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.159 with HTTP; Thu, 10 Aug 2017 11:28:51 -0700 (PDT) In-Reply-To: <20170810174656.GX8146@mournblade.imrryr.org> References: <20170808210631.GO8146@mournblade.imrryr.org> <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> <20170809174827.GQ8146@mournblade.imrryr.org> <20170809183310.GU8146@mournblade.imrryr.org> <6050C765-D3FB-4037-930A-43FE00A5CB89@dukhovni.org> <20170810174656.GX8146@mournblade.imrryr.org> From: Daniel Margolis Date: Thu, 10 Aug 2017 11:28:51 -0700 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113f0b826835b705566a5e48" Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 18:28:57 -0000 --001a113f0b826835b705566a5e48 Content-Type: multipart/alternative; boundary="001a113f0b82603f7505566a5e49" --001a113f0b82603f7505566a5e49 Content-Type: text/plain; charset="UTF-8" Your point about the administrator of the Policy Domain was exactly my point, yes. And if an NXDOMAIN result is never "significant"--i.e. if it only exists for people not actually using STS--then we don't have to imagine implementors are ever concerned with SOA TTL. So adding significance in this sense means people have to be aware of NXDOMAIN TTLs (which to be honest I had to lookup just now to confirm my recollection that it comes from SOA!). Again, not a big deal; it's an extra knob, which I generally have been trying to avoid, but it's not a very complicated extra knob, so it's hardly a big deal. *shrug* Feedback from others is welcome. I am very much without a strong opinion on this one. On Thu, Aug 10, 2017 at 10:46 AM, Viktor Dukhovni wrote: > On Thu, Aug 10, 2017 at 10:02:41AM -0700, Daniel Margolis wrote: > > > Also, note that this slightly oddifies the _DNS_ caching story; the > > NXDOMAIN TTL is derived from the SOA record, so unlike a "real" TXT > record, > > the TTL on the "null" record comes (obviously) from a different place, > > which is a little bit (but only a little bit) weird in terms of usability > > of the configuration parameters, so to speak. > > Yes, the negative TTL is from the SOA, but the TXT record TTL is > not something the sending MTA has to concern itself with, the TTLs > are handled transparently by the resolver. The difference might > plausibly matter to the administrator of the receiving domain, who > might want to adjust the negative TTL, but he might do that regardless > of whether we refresh cached (!= "none") policies even when the > TXT is not present. That is, if you want a shorter or longer > negative TTL, you would do tune it regardless of how we decide this > question. > > > If anyone else has read this far on the thread, I'm happy to get feedback > > on this proposal from others on the list. > > Yes, please! > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a113f0b82603f7505566a5e49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Your point about the administrator of the Policy Domain wa= s exactly my point, yes. And if an NXDOMAIN result is never "significa= nt"--i.e. if it only exists for people not actually using STS--then we= don't have to imagine implementors are ever concerned with SOA TTL. So= adding significance in this sense means people have to be aware of NXDOMAI= N TTLs (which to be honest I had to lookup just now to confirm my recollect= ion that it comes from SOA!).=C2=A0

Again, not a big dea= l; it's an extra knob, which I generally have been trying to avoid, but= it's not a very complicated extra knob, so it's hardly a big deal.= *shrug*

Feedback from others is welcome. I am ver= y much without a strong opinion on this one.=C2=A0

On Thu, Aug 10, 2017 at 10:46 = AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
=
On Thu, Aug 10, 2017 at 10:= 02:41AM -0700, Daniel Margolis wrote:

> Also, note that this slightly oddifies the _DNS_ caching story; the > NXDOMAIN TTL is derived from the SOA record, so unlike a "real&qu= ot; TXT record,
> the TTL on the "null" record comes (obviously) from a differ= ent place,
> which is a little bit (but only a little bit) weird in terms of usabil= ity
> of the configuration parameters, so to speak.

Yes, the negative TTL is from the SOA, but the TXT record TTL is
not something the sending MTA has to concern itself with, the TTLs
are handled transparently by the resolver.=C2=A0 The difference might
plausibly matter to the administrator of the receiving domain, who
might want to adjust the negative TTL, but he might do that regardless
of whether we refresh cached (!=3D "none") policies even when the=
TXT is not present.=C2=A0 That is, if you want a shorter or longer
negative TTL, you would do tune it regardless of how we decide this
question.

> If anyone else has read this far on the thread, I'm happy to get f= eedback
> on this proposal from others on the list.

Yes, please!

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--001a113f0b82603f7505566a5e49-- --001a113f0b826835b705566a5e48 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMK8x525biWylzaTdKMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTE4NDIxNVoXDTE3MTAx ODE4NDIxNVowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwhqodpCO7YNSzRIz9ahzJEd2Fmnm1g9pYE2GUs5S8c6Jh JLiZkF4+kTvQVptWmuoWxWqgeIJcqZKozIYoNl06ecCUcCSo/61I+QeD061Vfl9SemzDYrK9IJ5i fsx9sXOD+c20D4Lef7F0wC9azTDs36EwgEDBcLKUef5/Y/n3TDPth8kllj0cKBitt1MC2Il95W7a MyESYucDAH7gSG/dIOGNUaIh+vLLMtRvDQVRfveOum2uUf52bF3rywDJ32dvPCDVsRJHWuhBUfaP shyNiw4d/NzDjMdc504m+GABUpF9r8203gWdhHMxPyeDIzeV7wujWEZ19c0jOcFwdpupAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFB8LoXS3E+322ae/sSMWqyi4zefEMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCeAGD8kMXY iuahwdAzZ8iUfQSAM9M8Q1JPN+jXR6gcJXagqqdjHep1KcrhYx4xvhAUurzdH0AtzjdHuS1OKOj4 OYaMUtjuSYQ6SfFdpkM6K/Ih9IklpIV4BynT4/8D6WROz5f+sQGMf22geoCWbRUsBZv7GgMIWg+1 w6F7FiSFR7NKTBRZS4y/SHv0LCtC12JHyyVQrbxrjXy2tIcrhKC0DhToxe4s9aIA/kauGUSGXyLa U55gCBKpReCTtn1b4aQIwJp9aj0wDzfqs88hyIkWKDUMW7VP+Wdk9y6qUpKwbSN9pIu3m3UmjZC7 6923PlCyPXBkAIcLrTExf7wVn9lpMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBcY6hQhVHcSjnf i+9tHTvDYA2CaDO7PWmvaEemXvzkuzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MTAxODI4NTNaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAQf4gD3nhTmUGc/NX8jlvzu97LGcGggGe YBqDBiHlGUopiMUFlGLNU99mn7jFY1YNTsk7eovdHWJjwdNVEwUj29F4LlfAqBsSJYYjXuYviFSN MVT8IDDFRrWoY89MFzuf27HfA1ZJBTiQ9AHJRe4cii4flfqcORf2a8OFgltJ/LBtgO4aPs23mDj7 EVqoaoL36bXs2yU0xGRmXoYvk8d+Lykg8EEp8+RBw3deM8wqjpi4IyEk1hiFeu5oazOgBe5qRdsr QTnb7GSh+4FC2criSGHQTOtvucxaopkTwwUnuwzuE/ul8LJr6TTAqcH1RjVaRMO7XHNAdNYdxCTy dPnEHw== --001a113f0b826835b705566a5e48-- From nobody Thu Aug 10 15:56:41 2017 Return-Path: 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 7D3DB1324A4 for ; Thu, 10 Aug 2017 15:56:39 -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, SPF_PASS=-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 iBuy23ROtb9f for ; Thu, 10 Aug 2017 15:56:37 -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 DBB8F1324A2 for ; Thu, 10 Aug 2017 15:56:37 -0700 (PDT) Received: from splunge.local (c-24-4-226-141.hsd1.ca.comcast.net [24.4.226.141]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v7AMuZCa022906 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 10 Aug 2017 15:56:37 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1502405797; bh=v7veokjHhPEfNZDDANnoXL5ULu0nbFHTAwtBFQuVEW0=; h=Subject:To:References:From:Date:In-Reply-To; b=UV6oPY4oV7TTMEFumjg4JCUf9J85Uu80t1/lSaAeY1xCxn9xtXKdXyqAMGPiDK24C kMQmcdrie/dJKjGtZprCHmv3NrDHwSO3gcDfLTmXfHAv0vHPIadc+jaLN193EODsnB BmTpYKIMEDTfhyenccXkaClRDOWTKEZFetaag1as= To: uta@ietf.org References: <20170808210631.GO8146@mournblade.imrryr.org> <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> <20170809174827.GQ8146@mournblade.imrryr.org> <20170809183310.GU8146@mournblade.imrryr.org> <6050C765-D3FB-4037-930A-43FE00A5CB89@dukhovni.org> <20170810174656.GX8146@mournblade.imrryr.org> From: Jim Fenton Message-ID: <62416269-a781-0642-f339-5f5ebbbb4146@bluepopcorn.net> Date: Thu, 10 Aug 2017 15:56:29 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170810174656.GX8146@mournblade.imrryr.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 22:56:39 -0000 On 8/10/17 10:46 AM, Viktor Dukhovni wrote: > On Thu, Aug 10, 2017 at 10:02:41AM -0700, Daniel Margolis wrote: > >> If anyone else has read this far on the thread, I'm happy to get feedb= ack >> on this proposal from others on the list. > Yes, please! > I have been following the discussion, although not in as much detail as the two of you. One small adjustment: When removing the policy, after removing the TXT record, you should probably wait the former record's TTL before removing the "none" policy because the TXT record could be cached elsewhere, even if it looks like it's gone when you ask for it. At a higher level: I agree that including a procedure policy removal is an essential part of the specification. But we also have to make sure that that procedure doesn't present an opportunity for an attacker to downgrade the policy associated with a recipient domain. I *think* this satisfies this requirement but I'm not completely sure. -Jim From nobody Thu Aug 10 16:07:43 2017 Return-Path: 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 419761326D6 for ; Thu, 10 Aug 2017 16:07:41 -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] 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 S6SFMo6i7NAz for ; Thu, 10 Aug 2017 16:07:39 -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 9948F1326D3 for ; Thu, 10 Aug 2017 16:07:39 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B05B67A3309; Thu, 10 Aug 2017 23:07:38 +0000 (UTC) Date: Thu, 10 Aug 2017 23:07:38 +0000 From: Viktor Dukhovni To: uta@ietf.org Message-ID: <20170810230738.GE8146@mournblade.imrryr.org> Reply-To: uta@ietf.org References: <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> <20170809174827.GQ8146@mournblade.imrryr.org> <20170809183310.GU8146@mournblade.imrryr.org> <6050C765-D3FB-4037-930A-43FE00A5CB89@dukhovni.org> <20170810174656.GX8146@mournblade.imrryr.org> <62416269-a781-0642-f339-5f5ebbbb4146@bluepopcorn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62416269-a781-0642-f339-5f5ebbbb4146@bluepopcorn.net> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 23:07:41 -0000 On Thu, Aug 10, 2017 at 03:56:29PM -0700, Jim Fenton wrote: > I have been following the discussion, although not in as much detail as > the two of you. > > One small adjustment: When removing the policy, after removing the TXT > record, you should probably wait the former record's TTL before removing > the "none" policy because the TXT record could be cached elsewhere, even > if it looks like it's gone when you ask for it. Actually, not so much the DNS record's TTL, but the max_age of any previous "!= none" policy. All other policies need to expire will all caches having "none" (or be cleared) before the "none" policy is removed. Under that condition, there's no need to wait to remove the TXT record, removal of the record (being a change in the record) will in this variant of the design trigger a refresh, and the sending MTA will see a "none" policy and proceed to promptly flush it. However, since refresh will often only happen in the background when delivering mail to the domain in question, not all domains will do the refresh in a timely manner, hence the "max_age" delay to remove the policy. > At a higher level: I agree that including a procedure policy removal is > an essential part of the specification. But we also have to make sure > that that procedure doesn't present an opportunity for an attacker to > downgrade the policy associated with a recipient domain. I *think* this > satisfies this requirement but I'm not completely sure. Agreed. My goal was to make sure that deliberate removal "by the book" can be distinguished from an attack. And thus that MTAs would be able to noisily log "abnormal" policy refresh failure, while not generating any warnings for the proper policy removal procedure. -- Viktor. From nobody Thu Aug 10 16:36:26 2017 Return-Path: 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 172E81326D8 for ; Thu, 10 Aug 2017 16:36:25 -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, SPF_PASS=-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 m-Oo7Ra5SZjn for ; Thu, 10 Aug 2017 16:36:23 -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 B3AFB1326DA for ; Thu, 10 Aug 2017 16:36:23 -0700 (PDT) Received: from splunge.local (c-24-4-226-141.hsd1.ca.comcast.net [24.4.226.141]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v7ANaLOR023321 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 10 Aug 2017 16:36:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1502408183; bh=Ycw3YCUqF/orLItfzrJtKDKStn73FNccVBDe+XDeLJM=; h=Subject:To:References:From:Date:In-Reply-To; b=OtVTCXFWhlJGK/tqO/8tcTCa2/jIsB/iL2ZUX1G4aHSqzvOYe09Mld39xGGSqU4hg 7ScrvI+jgzw7LYplBjo2iPEwfhf4AxoTA1fV33QPpSFePMY3vvh1yfr3EAkHqcLd5S VBlc3mVn/2+bkTqk5a5dEHODZkzopCXhqcx2fmnU= To: uta@ietf.org References: <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> <20170809174827.GQ8146@mournblade.imrryr.org> <20170809183310.GU8146@mournblade.imrryr.org> <6050C765-D3FB-4037-930A-43FE00A5CB89@dukhovni.org> <20170810174656.GX8146@mournblade.imrryr.org> <62416269-a781-0642-f339-5f5ebbbb4146@bluepopcorn.net> <20170810230738.GE8146@mournblade.imrryr.org> From: Jim Fenton Message-ID: <80d8938a-2b27-9ba9-985c-54c688b215fe@bluepopcorn.net> Date: Thu, 10 Aug 2017 16:36:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170810230738.GE8146@mournblade.imrryr.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 23:36:25 -0000 On 8/10/17 4:07 PM, Viktor Dukhovni wrote: > > Under that condition, there's no need to wait to remove the TXT > record, removal of the record (being a change in the record) will > in this variant of the design trigger a refresh, and the sending > MTA will see a "none" policy and proceed to promptly flush it. > That's the part I didn't get: that an NXDOMAIN or NODATA response was also considered to be a record change that triggers a refresh. Thanks. That isn't immediately obvious because the lack of a TXT record when you don't already have a policy cached inhibits fetch of the policy. -Jim From nobody Thu Aug 10 19:14:15 2017 Return-Path: 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 0D8A813244C for ; Thu, 10 Aug 2017 19:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 aQjoB5PAOBZ4 for ; Thu, 10 Aug 2017 19:14:12 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A68132440 for ; Thu, 10 Aug 2017 19:14:11 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id d29so10302746uai.2 for ; Thu, 10 Aug 2017 19:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dBV/LyJAIwn38NCadrk0asIKDlEk2TsE2mPywTcs0EQ=; b=rB+jE2dJ5PQ+GnMSzZhXj9Hc+7b/j7KT/PkGsM0ZOvaxw4xWf1CXY/QR34mKIt+x+g FpGYiiRAbTRqwejJPJrHKzu1UpasH1t+fB5tRpODzeta06vFNslhl1dAfNWoKs8Nk5Yc yhVrrSIpt5+QC8a0fbCT+CwN8sury2+laUa3frFuk18DH2xFsPX9asu87UJiewzhM6uS Q5CSDz0RpPEBimO3EWBF/0q1tBcmt3rRAZtffbOpHMH8fmokWThzPu/lFFCDK2/x57hU qfirQSK0Trm8I+dFF3qdRBRM8hXsHowWRdipwFwbDObrk7UBYDkP/kZhjbRnJwQdJ/L5 UkUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dBV/LyJAIwn38NCadrk0asIKDlEk2TsE2mPywTcs0EQ=; b=LPGfMzXZVfgE3zr/+J6mp7R21XYYdNd4baMEfAMO4ezQ4yzb/cIj/i4VJOnKjpGdWw kWkbSH2Z5CzyUU+glnMxhmAp0u8O42urRnIfw4RaGzOK4xtmZafgewMlmzluWR/MY3Ex OG0YPcR+tL00tmr0ICDM615s4ikYmJU4SDvvoyooSdfj/Jnad4V9sfDp89MLitSnjaRZ aHmlMUjt02CBg7oLjYrUZ++xCnaD45yjlGiKrlacxSqwk9fOT4pjRBW1dGpXme1d3JPf YqE3eccVVG6zj/EFMWVPRZbah8yjKcdhn25qXCZNA2t7VHwOfeHQ6m7q0MWIsyHy0AS0 hqAQ== X-Gm-Message-State: AHYfb5hzRbEZOdO5mM4jHHz818Rd1wJzAbLoGlXg1t1jz8jKJbl0uhcq VuhL5LZloA3seNzrPdlxciQoiMJwYw4C43M= X-Received: by 10.176.1.169 with SMTP id 38mr10250062ual.32.1502417650446; Thu, 10 Aug 2017 19:14:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.161.142 with HTTP; Thu, 10 Aug 2017 19:14:09 -0700 (PDT) In-Reply-To: <80d8938a-2b27-9ba9-985c-54c688b215fe@bluepopcorn.net> References: <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> <20170809174827.GQ8146@mournblade.imrryr.org> <20170809183310.GU8146@mournblade.imrryr.org> <6050C765-D3FB-4037-930A-43FE00A5CB89@dukhovni.org> <20170810174656.GX8146@mournblade.imrryr.org> <62416269-a781-0642-f339-5f5ebbbb4146@bluepopcorn.net> <20170810230738.GE8146@mournblade.imrryr.org> <80d8938a-2b27-9ba9-985c-54c688b215fe@bluepopcorn.net> From: Daniel Margolis Date: Thu, 10 Aug 2017 19:14:09 -0700 Message-ID: To: Jim Fenton Cc: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11c15c166358a1055670de11" Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 02:14:14 -0000 --001a11c15c166358a1055670de11 Content-Type: multipart/alternative; boundary="001a11c15c165cf578055670de4b" --001a11c15c165cf578055670de4b Content-Type: text/plain; charset="UTF-8" Right. It has no real impact on the state machine (so to speak) but makes it possible for the recipient to remove the TXT record immediately, should they desire. I'm open to feedback from other people. This still seems weird to me--mostly aesthetically--in the sense that a "none" policy is still a policy but a non-existent TXT record is not a TXT record, so it sort of violates my assumption that if you have a valid policy you have a TXT record. But this is mostly aesthetics, so feedback is welcome. On Thu, Aug 10, 2017 at 4:36 PM, Jim Fenton wrote: > On 8/10/17 4:07 PM, Viktor Dukhovni wrote: > > > > Under that condition, there's no need to wait to remove the TXT > > record, removal of the record (being a change in the record) will > > in this variant of the design trigger a refresh, and the sending > > MTA will see a "none" policy and proceed to promptly flush it. > > > That's the part I didn't get: that an NXDOMAIN or NODATA response was > also considered to be a record change that triggers a refresh. Thanks. > That isn't immediately obvious because the lack of a TXT record when you > don't already have a policy cached inhibits fetch of the policy. > > -Jim > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a11c15c165cf578055670de4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Right. It has no real impact on the state machine (so to s= peak) but makes it possible for the recipient to remove the TXT record imme= diately, should they desire.=C2=A0

I'm open to feedb= ack from other people. This still seems weird to me--mostly aesthetically--= in the sense that a "none" policy is still a policy but a non-exi= stent TXT record is not a TXT record, so it sort of violates my assumption = that if you have a valid policy you have a TXT record. But this is mostly a= esthetics, so feedback is welcome.=C2=A0

On Thu, Aug 10, 2017 at 4:36 PM, Jim Fen= ton <fenton@bluepopcorn.net> wrote:
On 8/10/17 4:07 PM, Viktor Dukhovni wrote:=
>
> Under that condition, there's no need to wait to remove the TXT > record, removal of the record (being a change in the record) will
> in this variant of the design trigger a refresh, and the sending
> MTA will see a "none" policy and proceed to promptly flush i= t.
>
That's the part I didn't get: that an NXDOMAIN or NODATA res= ponse was
also considered to be a record change that triggers a refresh. Thanks.
That isn't immediately obvious because the lack of a TXT record when yo= u
don't already have a policy cached inhibits fetch of the policy.

-Jim

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--001a11c15c165cf578055670de4b-- --001a11c15c166358a1055670de11 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMK8x525biWylzaTdKMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTE4NDIxNVoXDTE3MTAx ODE4NDIxNVowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwhqodpCO7YNSzRIz9ahzJEd2Fmnm1g9pYE2GUs5S8c6Jh JLiZkF4+kTvQVptWmuoWxWqgeIJcqZKozIYoNl06ecCUcCSo/61I+QeD061Vfl9SemzDYrK9IJ5i fsx9sXOD+c20D4Lef7F0wC9azTDs36EwgEDBcLKUef5/Y/n3TDPth8kllj0cKBitt1MC2Il95W7a MyESYucDAH7gSG/dIOGNUaIh+vLLMtRvDQVRfveOum2uUf52bF3rywDJ32dvPCDVsRJHWuhBUfaP shyNiw4d/NzDjMdc504m+GABUpF9r8203gWdhHMxPyeDIzeV7wujWEZ19c0jOcFwdpupAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFB8LoXS3E+322ae/sSMWqyi4zefEMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCeAGD8kMXY iuahwdAzZ8iUfQSAM9M8Q1JPN+jXR6gcJXagqqdjHep1KcrhYx4xvhAUurzdH0AtzjdHuS1OKOj4 OYaMUtjuSYQ6SfFdpkM6K/Ih9IklpIV4BynT4/8D6WROz5f+sQGMf22geoCWbRUsBZv7GgMIWg+1 w6F7FiSFR7NKTBRZS4y/SHv0LCtC12JHyyVQrbxrjXy2tIcrhKC0DhToxe4s9aIA/kauGUSGXyLa U55gCBKpReCTtn1b4aQIwJp9aj0wDzfqs88hyIkWKDUMW7VP+Wdk9y6qUpKwbSN9pIu3m3UmjZC7 6923PlCyPXBkAIcLrTExf7wVn9lpMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBhX54cU5J23A/c 6V244VMUckMEtfhzI8WJWDAPaxIHMTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MTEwMjE0MTBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAiG+IQcS3guHD7foRxEP2sjBoXmHIqXed wZ1bJjWqbX1TR/P4zqdl9lp3C8q6ThCKmIrlR+WFPNLYWKc2KHiBF6swqRJculvu3JW1RGfcpSJt RfIVkb9HU4Hw3qgMraRf8VqMjtfqcct+0GuKE93/gYldZPorn10U4Ur0VkfqDNeDaza5m21402M5 qIbWtdpQBPwD9ONlrRFNza4AiSsVPuxiAN0kokj/fbzjU8pWW7H27DLQvpixERJXpkpwegsCJUYm ZX+bFHyE7sj3BrR4DkCSNgbrYfHxIshkI3M6KOU50oOeY4OZZuVwe6SLxErPm1+v9uOU7Z04fpMb PaeMFA== --001a11c15c166358a1055670de11-- From nobody Fri Aug 11 10:30:38 2017 Return-Path: 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 CE46F1324EA for ; Fri, 11 Aug 2017 10:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IBvMmxBR31tS for ; Fri, 11 Aug 2017 10:30:34 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914421324DF for ; Fri, 11 Aug 2017 10:30:34 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id t86so18351243pfe.2 for ; Fri, 11 Aug 2017 10:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+0h20RXfaiH9xw6aNxz5CbQX5ZmiuQrne6RO5MkWq4s=; b=ATv5SSDU1tBMEEkOH4sCan31EiOsTRKu07arNJY/EmNSObeTWw5AxzPIF8/7zfJQoL GKqo16ROKERiP70xmbbXBlhaLV21VyrM20yjHdjU8W+4yLeyxUeQOl5Sfyzvtf/wP/hd Ssx7Rb0vRh6DGFWilCsFO9tR2RJ6UdYHortwB+HtqECWz2fwam4YF/4BLju8TIQO83OL zRfzHLlFwymmrYoEvl3VVI3mV6uExWPuCOED47gR8xUMzN0p2slNei/EyQkEUBEw1I6j +Z0thk1RGDtTCdBRVB9CHXUn4oDC4Q4IScGHjGhYh6UyzKFkVUJ7IWY5Ect9WZrqTSgc G65A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+0h20RXfaiH9xw6aNxz5CbQX5ZmiuQrne6RO5MkWq4s=; b=B2AwqzdF4aXuIAJGbxuiIPtHI3aRXjgyxJ/DiJai8+AzqGMIKn8LDWsb6KMXiaUWfg TpMZN6pS4fgSoliSolBING62yGlvRS+wbgMeFaNgSjaB1WVr15MkPvJJGBN8dZRnQvCV bOisDDLWg0YKZdG0wcHonpE68axjzvfcuzNUb/iies+7JLwe1uqUUWBBnjNq/jFFbQYB QGiGyhePA28ppZaG/rI9W71brcPDnHqUd8drRbaaqATSoezoSHFgbCSN3TK2PZm+IKGu J+F0Fs7Te7c4jOFsinh0WaMTI0oIV5Uig2OnFrUwILjU14U/1sZEEiFTiDozizp9fHyY dddw== X-Gm-Message-State: AHYfb5hvtx92mG0LnM+m4FwRHSkUQfTzyVsr7VLzRBi3A1NANswK+vGy WXlUVQtJEL15DXs333jJ/ECX3omqGA== X-Received: by 10.99.97.6 with SMTP id v6mr16201312pgb.254.1502472634097; Fri, 11 Aug 2017 10:30:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.2 with HTTP; Fri, 11 Aug 2017 10:30:33 -0700 (PDT) In-Reply-To: References: <24ecb63305ed43bc8ee0564d5cd18b69@PACDCEX19.cable.comcast.com> From: David Illsley Date: Fri, 11 Aug 2017 18:30:33 +0100 Message-ID: To: "Brotman, Alexander" Cc: "uta@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0ccb2ea3e52205567dabdb" Archived-At: Subject: Re: [Uta] Updated TLSRPT Draft (v07) X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 17:30:37 -0000 --94eb2c0ccb2ea3e52205567dabdb Content-Type: text/plain; charset="UTF-8" Additionally, I've just noticed that the rua field in TLSRPT is unlike DMARC, and is a single URL, not a comma-separated list. In my experience deploying DMARC, it's been useful to feed reports to multiple systems. If that's an oversight, rather than an explicit decision, I'd be keen on TLSRPT matching DMARC, and supporting a list. Cheers, David On Wed, Aug 2, 2017 at 9:15 AM, David Illsley wrote: > A couple of minor comments: > 1. Section 3 includes: > "A URI specifying the endpoint to which aggregate information about > policy failures should be sent" and "When sending failure reports via SMTP" > This might imply that reports should only be sent when a failure is > experienced, whereas I believe the intention is for this to be like DMARC > where reporting is sent when messages are exchanged even if there are no > policy failures. > This could be clarified with the above changed to: > "A URI specifying the endpoint to which aggregate information about > policy validation results should be sent" and "When sending aggregate > reports via SMTP" > > 2. Appendix 2: Example JSON Report - the JSON has a few syntax problems: > - A , is required after the "summary" object > - A " is required to close the result-type property in the third failure > - A " is required to close the receiving-mx-hostname in the third failure > > HTH > David > > > On Mon, Jul 31, 2017 at 6:35 PM, Brotman, Alexander < > Alexander_Brotman@comcast.com> wrote: > >> Hello Folks, >> >> We attempted to incorporate the feedback from Alexey and Chris as best we >> could, and we believe we have addressed each of their concerns either via >> the updated draft or via the mailing list. The period for the WGLC is >> nearly over, and we wanted to try to provide an interim/updated draft for >> any final review. Thank you for any comments. >> >> -- >> Alex Brotman >> Sr. Engineer, Anti-Abuse >> Comcast >> >> >> _______________________________________________ >> Uta mailing list >> Uta@ietf.org >> https://www.ietf.org/mailman/listinfo/uta >> > > --94eb2c0ccb2ea3e52205567dabdb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Additionally, I've just noticed that the rua fiel= d in TLSRPT is unlike DMARC, and is a single URL, not a comma-separated lis= t. In my experience deploying DMARC, it's been useful to feed reports t= o multiple systems. If that's an oversight, rather than an explicit dec= ision, I'd be keen on TLSRPT matching DMARC, and supporting a list.
Cheers,
David
On Wed, Aug 2, 2017 at 9:15 AM, David Illsley = <davidillsley@gmail.com> wrote:
A couple of minor comments:
1. S= ection 3 includes:
=C2=A0 "A URI specifying the endpoint= to which aggregate information about policy failures should be sent" = and "When sending failure reports via SMTP"
This m= ight imply that reports should only be sent when a failure is experienced, = whereas I believe the intention is for this to be like DMARC where reportin= g is sent when messages are exchanged even if there are no policy failures.=
This could be clarified with the above changed to:
=C2= =A0"A URI specifying the endpoint to which aggregate information about= =20 policy validation results should be sent" and "When sending aggre= gate reports via=20 SMTP"

2. Appendix 2: Example JSON Report - th= e JSON has a few syntax problems:
=C2=A0- A , is required after t= he "summary" object
=C2=A0- A " is required to clo= se the result-type property in the third failure
=C2=A0- A "= is required to close the receiving-mx-hostname in the third failure

HTH
David


On Mon, Jul 31, 2017 at 6:35 PM, Brotman, Alexander <Al= exander_Brotman@comcast.com> wrote:
Hello Folks,

We attempted to incorporate the feedback from Alexey and Chris as best we c= ould, and we believe we have addressed each of their concerns either via th= e updated draft or via the mailing list.=C2=A0 The period for the WGLC is n= early over, and we wanted to try to provide an interim/updated draft for an= y final review.=C2=A0 Thank you for any comments.

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast


_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


--94eb2c0ccb2ea3e52205567dabdb-- From nobody Tue Aug 15 10:04:25 2017 Return-Path: X-Original-To: uta@ietf.org Delivered-To: uta@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D4A132143; Tue, 15 Aug 2017 10:04:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: uta@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150281666342.21069.12808915586909042227@ietfa.amsl.com> Date: Tue, 15 Aug 2017 10:04:23 -0700 Archived-At: Subject: [Uta] I-D Action: draft-ietf-uta-mta-sts-08.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 17:04:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications WG of the IETF. Title : SMTP MTA Strict Transport Security (MTA-STS) Authors : Daniel Margolis Mark Risher Binu Ramakrishnan Alexander Brotman Janet Jones Filename : draft-ietf-uta-mta-sts-08.txt Pages : 20 Date : 2017-08-15 Abstract: SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections, and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-uta-mta-sts-08 https://datatracker.ietf.org/doc/html/draft-ietf-uta-mta-sts-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-mta-sts-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 15 10:04:43 2017 Return-Path: X-Original-To: uta@ietf.org Delivered-To: uta@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B0C132398; Tue, 15 Aug 2017 10:04:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: uta@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150281667771.21036.3537636324107400513@ietfa.amsl.com> Date: Tue, 15 Aug 2017 10:04:37 -0700 Archived-At: Subject: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-08.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 17:04:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications WG of the IETF. Title : SMTP TLS Reporting Authors : Daniel Margolis Alexander Brotman Binu Ramakrishnan Janet Jones Mark Risher Filename : draft-ietf-uta-smtp-tlsrpt-08.txt Pages : 23 Date : 2017-08-15 Abstract: A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE [RFC6698], and MTA-STS (TODO: Add ref). These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attackers and diagnose unintentional misconfigurations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-uta-smtp-tlsrpt-08 https://datatracker.ietf.org/doc/html/draft-ietf-uta-smtp-tlsrpt-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-tlsrpt-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 15 10:15:01 2017 Return-Path: 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 4807213228D for ; Tue, 15 Aug 2017 10:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wsLz9ahYXVao for ; Tue, 15 Aug 2017 10:14:58 -0700 (PDT) Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (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 CDA3F132143 for ; Tue, 15 Aug 2017 10:14:57 -0700 (PDT) X-AuditID: 44571fa7-c51ff7000002609a-21-59932c0fc3cb Received: from PACDCEX20.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 4C.65.24730.01C23995; Tue, 15 Aug 2017 13:14:56 -0400 (EDT) Received: from PACDCEX19.cable.comcast.com (24.40.1.142) by PACDCEX20.cable.comcast.com (24.40.1.143) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 15 Aug 2017 13:14:55 -0400 Received: from PACDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8304]) by PACDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8304%19]) with mapi id 15.00.1293.002; Tue, 15 Aug 2017 13:14:54 -0400 From: "Brotman, Alexander" To: "uta@ietf.org" Thread-Topic: New revisions: MTA-STS & TLSRPT Thread-Index: AdMV6UGwqyIKUEBQQDysIYaSOMZlUg== Date: Tue, 15 Aug 2017 17:14:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.115.73.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA11TaWwTRxTW7K6dTeKBZY3tYQmBLKQCcjRU/Kg4oiABQvxAEaJFRqB042xi N77ktSHhEBGHgIhwhUMYECHEpI0jRVxSWkIAU1AOEJcFtEKIgmlDADWcJRLXrHcd1vzZffN9 7833vTczNMmeTOVoh9sv+tyCk9enUbMX8xl5TG69tSAczfu+59J6UATmNTUNEsVgSdqMMtHp WC76vi38Kc3eeOwG5e3QV7UfuK2rAbt1tSCVRsxUFL3SRdWCNJplfifQvV/P6dQFQL9dbFQX 3QDtaXysl0v0zDT0/NMmUo5HMlmo7/1/KbWApo3MRHThRYkC56Gu3oOEEuejvkPheCnFZKPd 0UspcgyZ+agh/C6eAxgz+r+nNR6TjAX9FTtMKO4Y1NRxjVRiE3ry6KPqugCdDnVSSpyFOgd+ IZXaXNRw5qVeiXPQsSNPSUVrBOreH1PzLejiH+26HcAU1MgFNeVBTXlQU94AqBaQ6RVsZTaX 3RPwF0zJtwmlTjHf5nHZBMkv/0+A+JmMbW4HZ/ctiwCGBrwBPhxXb2V1wnKp2hUBlTTBm2Dj 1V1Wdlipp6zaLkj2El/AKUr8SPhwEs6EQ3BpwFnJc3BuDkaNQ6hbXCE5RT++BHwmjG3CG1mG OCkgeR02hycglQR8zghANIm3vfwMJ8EyoXql6PMoYhEwmqZ4C1yVs97KMhWCX6wURa/oS7Ar aJpH0DUZK4/wiRViVbnD6U/QuG7QgbdktEzc7Bg4YdcOK2vWEhq/WXBpK6Y5Lf21ZYJOjYAK 2oB918vyUPIKLslRoUobYSADo4YEGpcdBavkVDYBaiTHwJbN2Ko5QSXL9YCdgF43cOo1QZ8K nsbf1raO1wRLuT1ukbPAJfJ5MHKpPeAeap8zw3B2nZUdriFkG1wGDMm4SYN/ccKNg6sLN1rZ URo22UziQfcDG743RvhU7smAn/uX7lm4VwbTVTDePIJb4sekYpreM2Cn3LtJZZLV+vGQCTzk qHyDoOQX/NohF8qFhgSqDrlIBtkEmDTkWcqQVSpZiasB5X0Puo1bU/jp2+vXbRsIPSu6lpf5 zauun82LT8x3zbxpnBiS7kw407ZgcM47NBjtOHCX/ff+rb+bjy8MLfqT613Y0ns9fU/6jXzT sit1uYfh1g9j1zR89/bHC/2xmrZVPxSff1N+NPyivbhp/P3Y+Try7bS60tDlq9SG7GbT7Un/ rL2zr5enJLswZTLpk4TP0qKjZEYFAAA= Archived-At: Subject: [Uta] New revisions: MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 17:14:59 -0000 Hello folks, We just uploaded new versions of these drafts. For MTA-STS, the major chan= ge is the K/V is now in the main tree, and some ABNF cleanups. We're still= working on incorporating some feedback from late last week. For TLSRPT, w= e've tried to incorporate feedback from the group. We altered the informat= ional/normative references, declared the JSON body to be the authoritative = source if there is a discrepancy, and DKIM. It didn't seem we reached a goo= d consensus on the Headers/Subject/Filename, so the subject format is now a= RECOMMEND. The Headers are now a MUST, and also a SHOULD for DKIM signing.= We also added David's request to allow for multiple RUAs. We look forward to any feedback that you might be able to provide. -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast From nobody Tue Aug 15 17:40:08 2017 Return-Path: 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 3017E1323C1 for ; Tue, 15 Aug 2017 17:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 18wj5v7mwOMX for ; Tue, 15 Aug 2017 17:40:05 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DFA21323AC for ; Tue, 15 Aug 2017 17:40:05 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id x191so12702880qka.5 for ; Tue, 15 Aug 2017 17:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=36sBQs50cbgPOwvcJU5GlHgd3v3gOXxRUPbR1By6F/8=; b=Ohh8sbSspXjW1HTYe6WayrVKs+trtf8DL9kYd6WaDm5VLktCDmbi4qdZBB9cN8/Czl 2pFZ2YOCTGLIwunaY78uZ+x8EjBox4Wo513AILKn11GsR+GW2+1N+qALMU9vVH0B2drI YLjNF0qS5VLaLQYVrNPdQ/+rxzwdu+HiAINejIyrlh4fBMF13oK7z9nwhebS0UN87a66 m0g9Da0KFNvTNqZ9KKsQ08Z7Soc9KMYEO9lp/ZwxbC2mg0+eYWaB8r0EWqCZWADAkGXW SwWxMQ1b/hdCzRw1Akf7hHRj4YC6/KkLHKq2AVTF8wJuVIfiyJ4aHgNTLVsdPYeBxA2J igng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=36sBQs50cbgPOwvcJU5GlHgd3v3gOXxRUPbR1By6F/8=; b=J9NYBeXitfcEEQXRO/5gEBJxLNfNWPZ9CqYzSIAo88L9iWx+EbE0emXIOI6FBffY1i R2yIZeBi0XpiWp9VJ3or2sKhhFHAENuCPM19pLpzjAGUJPtNSfKwoKPb2dK0Ei97chtJ T2KkuKXRWHRNlMNOarA3tjQ7Zia2aRR9CGt9HsCAGzANxUayIyT83QK8NKa+9y5olJWn NhUVnzhaCsacLjkYXfVUypDM9Epa14cLa7hBYaGelNr7DyA/joNw0iRUtpNv0vnPCGat 7ycasX/GdGnGO5/zABZBdFscAHcoRfcPjuPMnYCmMRaXJkkSNsP1Qs7k5xUfkj16ao32 tP4A== X-Gm-Message-State: AHYfb5gRcK86GKVrfF+r6jiBGdLf6lZIs6dhs4knefcKPNx46sE7ODqP 5Gj0GqyKk0grXFPUBoLAXZKQb9Xa0bhZ X-Received: by 10.55.91.135 with SMTP id p129mr5637qkb.32.1502844003861; Tue, 15 Aug 2017 17:40:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.23.84 with HTTP; Tue, 15 Aug 2017 17:39:43 -0700 (PDT) From: Ayke van Laethem Date: Wed, 16 Aug 2017 02:39:43 +0200 Message-ID: To: uta@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Uta] Expired/sold domains with a long max_age policy X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 00:40:07 -0000 I see a potential issue with very long max_age rules. Consider that the domain name example.org is sold to someone else, but the previous max_age in the policy was set at 10 years and various hosts (e.g. gmail.com) have sent email to example.org and thus have a cached policy. So if the new owner of example.org decides to add email, they *have to* also implement STARTTLS with the given MX hosts in the previous policy (which will often be impossible due to moving to a different email provider), or publish a new MTA-STS policy. If they don't know MTA-STS was used before, sending email will not work from some domains, without a clear signal as to why this is the case. Note that setting up MTA-STS requires some effort above simply setting up email itself (setting up STARTTLS, setting up a new mta-sts domain, obtaining a certificate, serving a new policy file). It is also not like HSTS: with HSTS the only requirement is enabling HTTPS, but with MTA-STS many more things need to be configured to override or adhere to a cached policy. My suggestion would be to add to the description of max_age that long durations may not always be desirable. Another option is to limit max_age to one year, similar to how HTTP used to limit caching to one year [1][2]. Also see [3]. This is not a perfect solution, but it will reduce the size of the problem. [1]: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.3 [2]: https://tools.ietf.org/html/rfc7234#section-5.3 [3]: https://github.com/mrisher/smtp-sts/blob/master/mta-sts.md#denial-of-service From nobody Tue Aug 15 23:06:52 2017 Return-Path: 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 B5F891252BA for ; Tue, 15 Aug 2017 23:06:51 -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] 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 dJX2jrA1rrxX for ; Tue, 15 Aug 2017 23:06:50 -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 E61171241F5 for ; Tue, 15 Aug 2017 23:06:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 635CF7A330A; Wed, 16 Aug 2017 06:06:48 +0000 (UTC) Date: Wed, 16 Aug 2017 06:06:48 +0000 From: Viktor Dukhovni To: uta@ietf.org Message-ID: <20170816060648.GA8146@mournblade.imrryr.org> Reply-To: uta@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Uta] Expired/sold domains with a long max_age policy X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 06:06:52 -0000 On Wed, Aug 16, 2017 at 02:39:43AM +0200, Ayke van Laethem wrote: > I see a potential issue with very long max_age rules. Consider that > the domain name example.org is sold to someone else, but the previous > max_age in the policy was set at 10 years and various hosts (e.g. > gmail.com) have sent email to example.org and thus have a cached > policy. > > So if the new owner of example.org decides to add email, they *have > to* also implement STARTTLS with the given MX hosts in the previous > policy (which will often be impossible due to moving to a different > email provider), or publish a new MTA-STS policy. If they take over the domain, they presumably also take over DNS. If they don't intent to implement STS, they will not publish the TXT record, which is a change in the TXT record, and thus any cached policy should trigger a refresh attempt. For that refresh attempt to cause the policy to be flushed there would actually need to be an HTTPS server serving a "none" policy. > If they don't know > MTA-STS was used before, sending email will not work from some > domains, without a clear signal as to why this is the case. Yes, the new domain owner would have to know that the domain had STS< or just publish a "none" policy in case there was a previous policy in place. The difficulty is of course how long such a "none" policy should be in place. For this to be a manageable duration, there should be a maximum "max_age" that sending systems accept, with any higher values truncated to that maximum. > Another option is to limit max_age to one year, similar to how HTTP > used to limit caching to one year [1][2]. Also see [3]. This is not a > perfect solution, but it will reduce the size of the problem. Yes, with the limit imposed by each sender and a "SHOULD NOT" on publishing max_age beyond that limit for receiving domains. -- Viktor. From nobody Wed Aug 16 01:07:35 2017 Return-Path: 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 35AB9132518 for ; Wed, 16 Aug 2017 01:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 fJF4k7S5aKFr for ; Wed, 16 Aug 2017 01:07:30 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3CF1321A8 for ; Wed, 16 Aug 2017 01:07:30 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id 76so14202809ith.0 for ; Wed, 16 Aug 2017 01:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Ya8ApYlgYRQsGpojXHwOa9Wh1Ncc+HX/zoMA/CHsEhM=; b=HN0j5sf6rAEAViK33/VxUsNMOWwTn36LtCj9nrj424URzw50ah6KTifzh1abXnCjCL rumwezuDOHFD8qO8H3ueA1T8ctCI96WZ6wCudKZfW+CjPqWrc+tw9yTf7zwyMRx5kls9 4ElxqboRHwlelonZKb0oI2i6sjsvgJBtFUapjOahVma/so+quuQF/tan+2LzyCzYqhrQ thvdblikzSe5DzKC9nC3Uti5lE/RvyebyhTeoER7jLmQ+rWCer/Pq91n9NpDUiuLWpOj PCfx1g8yEBoxag+zeFRI1A9+Ocf7TaN2VjROZedYLgAwNaXq82r1a6OjapmBmLmAMehC 3UBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Ya8ApYlgYRQsGpojXHwOa9Wh1Ncc+HX/zoMA/CHsEhM=; b=c9NCfOrkCDGVQSykM4RW/HC37NL9yT2Czcz476i2L4vq+5fXCBzvxzmHd/qi6imQ3F X4gZ5UmzwLMTJHTqVYVyt5keu+FZx0BDXaBRpqI4FLyYQluFSAwPEb2i/XVZSHpvWeTG D+UTA24SRab1We+6earvE8k5nKDx+3Ngva651XqaJNQuD8zSb1gMrvCC8y79/nss00gf qx2xWEsg77Qr2547xxjvzJ3E1g7kbUrRAqAxiM5vpg3tLrrTlngWEfO0wkfbF9Qr43o6 wmdixUPdYh7wNlFsmpl81v9X57+9wVR5hbJBGN8PO1pw+kltRtbYcw4xCi7ZItZC7Lcf L2vQ== X-Gm-Message-State: AHYfb5hHgNlzYocgw3/2bu7kf9o0JPEuzJtXkvOxlFWsNwodXuRPC0vq H2KOP16bp3NigCGe2u+s/6kqO3TMnEhufKY= X-Received: by 10.36.211.201 with SMTP id n192mr1204608itg.96.1502870849337; Wed, 16 Aug 2017 01:07:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.159 with HTTP; Wed, 16 Aug 2017 01:07:28 -0700 (PDT) In-Reply-To: <20170816060648.GA8146@mournblade.imrryr.org> References: <20170816060648.GA8146@mournblade.imrryr.org> From: Daniel Margolis Date: Wed, 16 Aug 2017 10:07:28 +0200 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11499ff625f40c0556da6308" Archived-At: Subject: Re: [Uta] Expired/sold domains with a long max_age policy X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 08:07:33 -0000 --001a11499ff625f40c0556da6308 Content-Type: multipart/alternative; boundary="001a11499ff61ed7b30556da633d" --001a11499ff61ed7b30556da633d Content-Type: text/plain; charset="UTF-8" I'm OK with a one-year SHOULD NOT. Realistically, though, that year could still be painful; as Viktor said, there's always the opt-out option (but, yes, you have to get a certificate, set up DNS, etc). I would liken this more to HPKP than HSTS; HPKP, unlike STS, has (as far as I can tell) no workable opt-out mechanism; if someone pins a leaf certificate that the new domain owner doesn't have, the new domain owner is screwed until/unless the policy expires. I'm not saying that's in any way a mitigation of STS having some similar issues, though I'm also not personally aware of HPKP being abused like so in the wild. (Then again, HPKP adoption appears to be fairly minimal, so this has less chance of happening by accident.) On Wed, Aug 16, 2017 at 8:06 AM, Viktor Dukhovni wrote: > On Wed, Aug 16, 2017 at 02:39:43AM +0200, Ayke van Laethem wrote: > > > I see a potential issue with very long max_age rules. Consider that > > the domain name example.org is sold to someone else, but the previous > > max_age in the policy was set at 10 years and various hosts (e.g. > > gmail.com) have sent email to example.org and thus have a cached > > policy. > > > > So if the new owner of example.org decides to add email, they *have > > to* also implement STARTTLS with the given MX hosts in the previous > > policy (which will often be impossible due to moving to a different > > email provider), or publish a new MTA-STS policy. > > If they take over the domain, they presumably also take over DNS. > If they don't intent to implement STS, they will not publish the > TXT record, which is a change in the TXT record, and thus any cached > policy should trigger a refresh attempt. > > For that refresh attempt to cause the policy to be flushed there > would actually need to be an HTTPS server serving a "none" policy. > > > If they don't know > > MTA-STS was used before, sending email will not work from some > > domains, without a clear signal as to why this is the case. > > Yes, the new domain owner would have to know that the domain had > STS< or just publish a "none" policy in case there was a previous > policy in place. The difficulty is of course how long such a "none" > policy should be in place. For this to be a manageable duration, > there should be a maximum "max_age" that sending systems accept, > with any higher values truncated to that maximum. > > > Another option is to limit max_age to one year, similar to how HTTP > > used to limit caching to one year [1][2]. Also see [3]. This is not a > > perfect solution, but it will reduce the size of the problem. > > Yes, with the limit imposed by each sender and a "SHOULD NOT" on publishing > max_age beyond that limit for receiving domains. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a11499ff61ed7b30556da633d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm OK with a one-year SHOULD NOT. Realistically, thou= gh, that year could still be painful; as Viktor said, there's always th= e opt-out option (but, yes, you have to get a certificate, set up DNS, etc)= .=C2=A0

I would liken this more to HPKP than HSTS; HPKP,= unlike STS, has (as far as I can tell) no workable opt-out mechanism; if s= omeone pins a leaf certificate that the new domain owner doesn't have, = the new domain owner is screwed until/unless the policy expires. I'm no= t saying that's in any way a mitigation of STS having some similar issu= es, though I'm also not personally aware of HPKP being abused like so i= n the wild. (Then again, HPKP adoption appears to be fairly minimal, so thi= s has less chance of happening by accident.)=C2=A0

On Wed, Aug 16, 2017 at 8:06 A= M, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">On Wed, Aug 16, 2017 at 02:3= 9:43AM +0200, Ayke van Laethem wrote:

> I see a potential issue with very long max_age rules. Consider that > the domain name example.org is sold to someone else, but the previous
> max_age in the policy was set at 10 years and various hosts (e.g.
> gmai= l.com) have sent email to example.org and thus have a cached
> policy.
>
> So if the new owner of example.org decides to add email, they *have
> to* also implement STARTTLS with the given MX hosts in the previous > policy (which will often be impossible due to moving to a different > email provider), or publish a new MTA-STS policy.

If they take over the domain, they presumably also take over DNS. If they don't intent to implement STS, they will not publish the
TXT record, which is a change in the TXT record, and thus any cached
policy should trigger a refresh attempt.

For that refresh attempt to cause the policy to be flushed there
would actually need to be an HTTPS server serving a "none" policy= .

> If they don't know
> MTA-STS was used before, sending email will not work from some
> domains, without a clear signal as to why this is the case.

Yes, the new domain owner would have to know that the domain had
STS< or just publish a "none" policy in case there was a previ= ous
policy in place.=C2=A0 The difficulty is of course how long such a "no= ne"
policy should be in place.=C2=A0 For this to be a manageable duration,
there should be a maximum "max_age" that sending systems accept,<= br> with any higher values truncated to that maximum.

> Another option is to limit max_age to one year, similar to how HTTP > used to limit caching to one year [1][2]. Also see [3]. This is not a<= br> > perfect solution, but it will reduce the size of the problem.

Yes, with the limit imposed by each sender and a "SHOULD NOT&qu= ot; on publishing
max_age beyond that limit for receiving domains.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--001a11499ff61ed7b30556da633d-- --001a11499ff625f40c0556da6308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMK8x525biWylzaTdKMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTE4NDIxNVoXDTE3MTAx ODE4NDIxNVowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwhqodpCO7YNSzRIz9ahzJEd2Fmnm1g9pYE2GUs5S8c6Jh JLiZkF4+kTvQVptWmuoWxWqgeIJcqZKozIYoNl06ecCUcCSo/61I+QeD061Vfl9SemzDYrK9IJ5i fsx9sXOD+c20D4Lef7F0wC9azTDs36EwgEDBcLKUef5/Y/n3TDPth8kllj0cKBitt1MC2Il95W7a MyESYucDAH7gSG/dIOGNUaIh+vLLMtRvDQVRfveOum2uUf52bF3rywDJ32dvPCDVsRJHWuhBUfaP shyNiw4d/NzDjMdc504m+GABUpF9r8203gWdhHMxPyeDIzeV7wujWEZ19c0jOcFwdpupAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFB8LoXS3E+322ae/sSMWqyi4zefEMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCeAGD8kMXY iuahwdAzZ8iUfQSAM9M8Q1JPN+jXR6gcJXagqqdjHep1KcrhYx4xvhAUurzdH0AtzjdHuS1OKOj4 OYaMUtjuSYQ6SfFdpkM6K/Ih9IklpIV4BynT4/8D6WROz5f+sQGMf22geoCWbRUsBZv7GgMIWg+1 w6F7FiSFR7NKTBRZS4y/SHv0LCtC12JHyyVQrbxrjXy2tIcrhKC0DhToxe4s9aIA/kauGUSGXyLa U55gCBKpReCTtn1b4aQIwJp9aj0wDzfqs88hyIkWKDUMW7VP+Wdk9y6qUpKwbSN9pIu3m3UmjZC7 6923PlCyPXBkAIcLrTExf7wVn9lpMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBnKjsr+/wbcudL hD6gsCnBq6AQfZHZ5G//oBR1Jet5TDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MTYwODA3MjlaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAFfKkh1hhtDOUaJrVw0KgI9jR2I8GvQDk wb1Dktp4JhEIPXt5sK74jjPHdjvjum6kf3eWKTwiVrSVw5b6rMc2b+/lZorBQvpaGRLhXxlTgOAj zPbxAJEuMRF0p9GPJYPqUlU6l0dNVXtre+xhHKmxFI/CrPsX+WTazdPr4gefhWlKXjCXdYZeqP3j gSKA71PCfn/f79QEmBR+o+SgS+LpmO2ATKnOEgNsTVTkx0/2/4D9EOfxZhmTT8vSiNSCz5Yh4unz zX9MH17IMk/hgIv8wkelWfntI/8tNVtqqJ90Rf/C7KtgjeqhVpbEiWveE/3RNEUAEIkK4KRMtlEW oHYaOw== --001a11499ff625f40c0556da6308-- From nobody Wed Aug 16 12:14:32 2017 Return-Path: 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 C66111326AE for ; Wed, 16 Aug 2017 12:14:31 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhcloos.com 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 yrO9uQZOwSzD for ; Wed, 16 Aug 2017 12:14:30 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (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 EEA1A1323A8 for ; Wed, 16 Aug 2017 12:14:29 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 2D56E1E04D; Wed, 16 Aug 2017 19:14:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1502910869; bh=dpMUezZ16nksDqgDMIiE9vrNpQdXdsZr1kJNbld3qyU=; h=From:To:Subject:In-Reply-To:References:Date:From; b=Iua8Jivhuy/uK5PxK6wfFJVF+ljwIJtw9bUZouivD/FPzzD7ssbQx26x9GJjTb0KA swJiWJNdLqYdrF9fixvdpoRpdWg1ZWiyqfApUXKeaqk2JDRkE9YFC6bhj8VssbR0aV C/xtzjQyQcrkOQxEDzUb+9A/LGnrLoAB1gUgkpBXzcLbqV6ht2B5BW5Jkf4yWvSWU2 9UYySQpRtFKerIcvZK6ns5TVxnUZ3Luql9o7gPNDtVNuThsiKSnguX3aR76yFf4yqx CVsnHo2gHa8J3b2/pbjAl1bIQPm8zJKtHTj7h7MXPdXtWalx7H0a7lr+GcxHnuErzG y29PFd8XbbJ9A== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 8B75F107AC445; Wed, 16 Aug 2017 19:12:58 +0000 (UTC) From: James Cloos To: uta@ietf.org In-Reply-To: <150281667771.21036.3537636324107400513@ietfa.amsl.com> (internet-drafts's message of "Tue, 15 Aug 2017 10:04:37 -0700") References: <150281667771.21036.3537636324107400513@ietfa.amsl.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2017 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 16 Aug 2017 15:12:58 -0400 Message-ID: Lines: 19 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:170816:uta@ietf.org::aLr8iGxi23uscCdO:0000S3zWH Archived-At: Subject: Re: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-08.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 19:14:32 -0000 One thought: The https section should specify a recomendation of what the web site should return when it sees a POST, and what if anything the generator should do if the web site replies that the report is not to spec. Ie, bad syntax or bad contents or the like. It probably should be json and could be as simple as {true} or {false}. Any uri which just accepts reports w/o trying to verify would then be expected to give the ok reply. OTOH, if the reporters SHOULDN'T care at all about whether the uri accepted its report, and should just drop the socket as soon as the packets are ACKed, then the document should specify that. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Sun Aug 20 05:25:16 2017 Return-Path: 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 C83521321A8 for ; Sun, 20 Aug 2017 05:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 pDzqCR7DYgs0 for ; Sun, 20 Aug 2017 05:25:11 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65514132125 for ; Sun, 20 Aug 2017 05:25:11 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id 1so9848424ioy.2 for ; Sun, 20 Aug 2017 05:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=i/NceXtDn4jwHQEu3RrPtzAmbL1Lutra0wUDpYwpnnw=; b=b7DQ0ZjaMGdbi0MyRQu4mx+Clf4mHeh+aiN6YLnqr+EkYbQwrcDPOWPpOHgXcox71S zigodogLzQKKMgo6DGslDb558tIq5hm/XY1MHlEa0Nvv6oNLNJN+/M4XM8YizDqjJzO9 g1P3xbleDAoPcVbmaXk/6JeoUeA5aKORG2ScvjqAZgpeCVdvuyRk0mKhN6FRL/Tmd3t4 qo84tJB4FDWDsdvDOZaN4+YSESKLbcdowldO/0xtC39oWtjXFEFWwvkgLDAv7o/Xn3ES RwikrSQQwmKOB3YIe+RR3ewm/NssY4q6ZED8SAcGhkd4Jh/R+PbegyPOgKh7UnG7dtl7 Fspg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=i/NceXtDn4jwHQEu3RrPtzAmbL1Lutra0wUDpYwpnnw=; b=VIFerws0bJ4+l611BSGrb3i30KtDTBxh144neAenmdNJVXCx+lALM4fCfFrNg2BxMm xWLGmKu95BQX0hUpaf9e/f8oBvLXc2GkJIcNiOO/6yiTjUJZEVjyJMZ3X++qBomEHluy 4p7UD72ZM4L1IlbgueV+sMkewhpZEtnqSVIz47SZvYB55Z3go2SsnM5FBIIz7gTmPbv1 zRTgyBf58dIoTU2su+hHq4unm2ebmjpy2FxN34pn39kmyno1hzv6g0XshilgyP7uVWm6 nyAhhMGqf+ptyM5wwLeARoEJY4EuWBaCb/JwKr4e6WZ7Y72AUa+gdx69rOFozL7TBDt5 hW9g== X-Gm-Message-State: AHYfb5gvee9JMe1o/6ETyxR1P0bsZ6VL5vWfn26eZ0JycU/T8H2OmJgO BZ925ysDZTcrn/54eEYrNUwQX3KNof0MIW0= X-Received: by 10.107.3.143 with SMTP id e15mr14120077ioi.308.1503231910081; Sun, 20 Aug 2017 05:25:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.159 with HTTP; Sun, 20 Aug 2017 05:25:09 -0700 (PDT) From: Daniel Margolis Date: Sun, 20 Aug 2017 14:25:09 +0200 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113eb3560c03f805572e7451" Archived-At: Subject: [Uta] MTA-STS and HTTP cache control X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 12:25:14 -0000 --001a113eb3560c03f805572e7451 Content-Type: multipart/alternative; boundary="001a113eb3560488e105572e7463" --001a113eb3560488e105572e7463 Content-Type: text/plain; charset="UTF-8" For the policy caching, we deliberately chose not to use HTTP Cache-Control headers and, instead, use "max_age" in the response body because it avoids the case where someone is hosting a policy on a general purpose HTTP endpoint that has some other cache settings than they are aware of. (For example, I may have an existing website at www.example.com, and I choose to redirect policy.example.com to www.example.com; I may, additionally, have a site-wide setting for Cache-Control that I do not have the ability to change.) However, by the same logic, it's unclear to me if we should specify to implementors what their client behavior should be with respect to Cache-Control--should they honor it as per RFC 7234? Should they never cache? As-is, it's up to the sender to cache or not cache (as with any HTTP client), and thus policy publishers have to be a little careful and remember that during a forced policy refresh the sender may see an old policy file up until the Cache-Control forces them not to cache it. It seems somewhat easier to me to simply specify that HTTP caching should never be used (i.e. aside from the long-lived policy cache). Any objections? --001a113eb3560488e105572e7463 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For the policy caching, we deliberately chose not to = use HTTP Cache-Control headers and, instead, use "max_age" in the= response body because it avoids the case where someone is hosting a policy= on a general purpose HTTP endpoint that has some other cache settings than= they are aware of. (For example, I may have an existing website at www.example.com, and I choose to redirect <= a href=3D"http://policy.example.com">policy.example.com to www.example.com; I may, additionally, have a sit= e-wide setting for Cache-Control that I do not have the ability to change.)= =C2=A0

However, by the same logic, it's un= clear to me if we should specify to implementors what their client behavior= should be with respect to Cache-Control--should they honor it as per RFC 7= 234? Should they never cache?

As-is, it's up t= o the sender to cache or not cache (as with any HTTP client), and thus poli= cy publishers have to be a little careful and remember that during a forced= policy refresh the sender may see an old policy file up until the Cache-Co= ntrol forces them not to cache it.

It seems somewh= at easier to me to simply specify that HTTP caching should never be used (i= .e. aside from the long-lived policy cache). Any objections?
--001a113eb3560488e105572e7463-- --001a113eb3560c03f805572e7451 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMK8x525biWylzaTdKMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTE4NDIxNVoXDTE3MTAx ODE4NDIxNVowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwhqodpCO7YNSzRIz9ahzJEd2Fmnm1g9pYE2GUs5S8c6Jh JLiZkF4+kTvQVptWmuoWxWqgeIJcqZKozIYoNl06ecCUcCSo/61I+QeD061Vfl9SemzDYrK9IJ5i fsx9sXOD+c20D4Lef7F0wC9azTDs36EwgEDBcLKUef5/Y/n3TDPth8kllj0cKBitt1MC2Il95W7a MyESYucDAH7gSG/dIOGNUaIh+vLLMtRvDQVRfveOum2uUf52bF3rywDJ32dvPCDVsRJHWuhBUfaP shyNiw4d/NzDjMdc504m+GABUpF9r8203gWdhHMxPyeDIzeV7wujWEZ19c0jOcFwdpupAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFB8LoXS3E+322ae/sSMWqyi4zefEMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCeAGD8kMXY iuahwdAzZ8iUfQSAM9M8Q1JPN+jXR6gcJXagqqdjHep1KcrhYx4xvhAUurzdH0AtzjdHuS1OKOj4 OYaMUtjuSYQ6SfFdpkM6K/Ih9IklpIV4BynT4/8D6WROz5f+sQGMf22geoCWbRUsBZv7GgMIWg+1 w6F7FiSFR7NKTBRZS4y/SHv0LCtC12JHyyVQrbxrjXy2tIcrhKC0DhToxe4s9aIA/kauGUSGXyLa U55gCBKpReCTtn1b4aQIwJp9aj0wDzfqs88hyIkWKDUMW7VP+Wdk9y6qUpKwbSN9pIu3m3UmjZC7 6923PlCyPXBkAIcLrTExf7wVn9lpMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBqDCjmcQGAZT42 S804cFNFJnXfDjsU57rxd7BqszUSvDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MjAxMjI1MTBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAmLaluoiT7186cMmp5R/jncPEwJEF+l+t cRRiWKbF0GmO1BNNfiLlT6JzBfQBCPB5JJOlLOnX/epSAxdld5O4U0Q5Ykq5URMebMzr1GLwneqa 9lVIAlmBQGwxfCn5RzIhkuASCVbVIHWgWqAsreFpEymxixt1b7ICoOHgSe4zB6Z1+A5BlobR+TDg LkVNcfM87WKTdkjQgM4R1UWgvGLcQtnJ/zOOThXaFKojvl+Xn1JlcKcc8PttL3dxlIqdRczC+GjN 98MOocbGMA57R4BJuYEjJPW7BFs/JYokarF0Z3KixBVGwF56VYxvDEijIwrgF/068PPIDHV6JkTZ Gc/2bQ== --001a113eb3560c03f805572e7451-- From nobody Sun Aug 20 06:28:08 2017 Return-Path: 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 0136513202D for ; Sun, 20 Aug 2017 06:28:08 -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] 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 sZRhLoUh2Eta for ; Sun, 20 Aug 2017 06:28:06 -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 37B8F126B6D for ; Sun, 20 Aug 2017 06:28:06 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (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 9974F7A330D for ; Sun, 20 Aug 2017 13:28:04 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Sun, 20 Aug 2017 09:28:08 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: <3F351A4F-6BFB-48FF-94B0-949AFE355606@dukhovni.org> References: To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] MTA-STS and HTTP cache control X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 13:28:08 -0000 > On Aug 20, 2017, at 8:25 AM, Daniel Margolis = wrote: >=20 > It seems somewhat easier to me to simply specify that HTTP caching = should never be used (i.e. aside from the long-lived policy cache). Any = objections? None, indeed I think that given explicit application-level caching via max-age, one MUST NOT pay attention to HTTP cache control. --=20 Viktor. From nobody Sun Aug 20 10:08:56 2017 Return-Path: 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 214BA132661 for ; Sun, 20 Aug 2017 10:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 IgDqRc7NK_Hd for ; Sun, 20 Aug 2017 10:08:52 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7D71321A4 for ; Sun, 20 Aug 2017 10:08:52 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id p141so4073825iop.3 for ; Sun, 20 Aug 2017 10:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=1ywaIlZEaSQ8W8XW7rF7C/6Hx29hFXqmZJZRbg+MlhE=; b=ipkHsDGCSb6jIQiTa2AufAFCnoIRmjlYasEvjDBH0+1zB5inSQgm6B7VP5gfK7Fbi9 79aG7e9eEFh3j9895ZQuiQ7XBjqL74whqee21bh+Jcr9a+Luo2a2HWUFob802EguxZFv Gn6JizbpIhJLRGlLrH2s6X/IE6CQbIr6j2it54p+rJ5Jg7wFnexb0L4V7m7hJDRRogtx xjEa2zHBCwfyspETwijzsZtPMFxizjhTLvQfm+pywfVwDyMe1YNtlWUILShAYOnEN513 F0X3JtApIGImS6AiZlFzvqu62q//F1tbwhuTYu9+q6mMai5DAuaMxwjAHJTgUTRdyctj HKFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=1ywaIlZEaSQ8W8XW7rF7C/6Hx29hFXqmZJZRbg+MlhE=; b=ovXtbJMhEAHHSCLuQjgrbnZNxVq9wFMjG1SA5/xWVDpysVSqkC4QEgOI+ShSivEhDh 5jDhFE7Cc2m1wNnnDY4WpxyRSdgE348SviUKAp06AGBGWQr9BunA+XfO4daTdp6hcl21 am9102lC4Los3FF69YuGeLKm4gy5xfdkhS8R7vtwUc/R8nBblZXviRJdnlD+XiuO1Z1j Aeh0CKkAw1ToRTEXaNpxJX5b72tr26BCvwCIXv/oyRASdrANArDRwi/4eSYMfnE85QKd JGo8PEbmyWlZMGY9mgjtHlm0NII4gczO8ODbeBWVf8E1s0CQGB6AKXQGkxNvY7wI0ovY ICRQ== X-Gm-Message-State: AHYfb5gOvARdy/lODmjPZ7UTy1QZs+7GMFI6WzzYFs/J7oT9l428VGj4 7rVQbGCVdE3DGVnHXqQkKZ5pCDkndR5VwU2hsg== X-Received: by 10.107.197.195 with SMTP id v186mr3236047iof.300.1503248931037; Sun, 20 Aug 2017 10:08:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.159 with HTTP; Sun, 20 Aug 2017 10:08:49 -0700 (PDT) In-Reply-To: <3F351A4F-6BFB-48FF-94B0-949AFE355606@dukhovni.org> References: <3F351A4F-6BFB-48FF-94B0-949AFE355606@dukhovni.org> From: Daniel Margolis Date: Sun, 20 Aug 2017 19:08:49 +0200 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c188d56940bb80557326ab9" Archived-At: Subject: Re: [Uta] MTA-STS and HTTP cache control X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 17:08:55 -0000 --94eb2c188d56940bb80557326ab9 Content-Type: multipart/alternative; boundary="94eb2c188d568bdbe50557326a91" --94eb2c188d568bdbe50557326a91 Content-Type: text/plain; charset="UTF-8" Policies fetched via HTTPS are only valid if the HTTP response code is 200 (OK). HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as specified in RFC7234) MUST NOT be used. On Sun, Aug 20, 2017 at 3:28 PM, Viktor Dukhovni wrote: > > > On Aug 20, 2017, at 8:25 AM, Daniel Margolis > wrote: > > > > It seems somewhat easier to me to simply specify that HTTP caching > should never be used (i.e. aside from the long-lived policy cache). Any > objections? > > None, indeed I think that given explicit application-level > caching via max-age, one MUST NOT pay attention to HTTP > cache control. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --94eb2c188d568bdbe50557326a91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Policies fetched via HTTPS are only valid if the HTTP resp= onse code is 200 (OK).
HTTP 3xx redirects MUST NOT be followed, and HTTP= caching (as specified in
RFC7234) MUST NOT be used.


On Sun, Aug 20, 2017 at 3:28 PM, Vikt= or Dukhovni <ietf-dane@dukhovni.org> wrote:

> On Aug 20, 2017, at 8:25 AM, Daniel Margolis <dmargolis@google.com> wrote:
>
> It seems somewhat easier to me to simply specify that HTTP caching sho= uld never be used (i.e. aside from the long-lived policy cache). Any object= ions?

None, indeed I think that given explicit application-level
caching via max-age, one MUST NOT pay attention to HTTP
cache control.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--94eb2c188d568bdbe50557326a91-- --94eb2c188d56940bb80557326ab9 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMK8x525biWylzaTdKMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTE4NDIxNVoXDTE3MTAx ODE4NDIxNVowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwhqodpCO7YNSzRIz9ahzJEd2Fmnm1g9pYE2GUs5S8c6Jh JLiZkF4+kTvQVptWmuoWxWqgeIJcqZKozIYoNl06ecCUcCSo/61I+QeD061Vfl9SemzDYrK9IJ5i fsx9sXOD+c20D4Lef7F0wC9azTDs36EwgEDBcLKUef5/Y/n3TDPth8kllj0cKBitt1MC2Il95W7a MyESYucDAH7gSG/dIOGNUaIh+vLLMtRvDQVRfveOum2uUf52bF3rywDJ32dvPCDVsRJHWuhBUfaP shyNiw4d/NzDjMdc504m+GABUpF9r8203gWdhHMxPyeDIzeV7wujWEZ19c0jOcFwdpupAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFB8LoXS3E+322ae/sSMWqyi4zefEMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCeAGD8kMXY iuahwdAzZ8iUfQSAM9M8Q1JPN+jXR6gcJXagqqdjHep1KcrhYx4xvhAUurzdH0AtzjdHuS1OKOj4 OYaMUtjuSYQ6SfFdpkM6K/Ih9IklpIV4BynT4/8D6WROz5f+sQGMf22geoCWbRUsBZv7GgMIWg+1 w6F7FiSFR7NKTBRZS4y/SHv0LCtC12JHyyVQrbxrjXy2tIcrhKC0DhToxe4s9aIA/kauGUSGXyLa U55gCBKpReCTtn1b4aQIwJp9aj0wDzfqs88hyIkWKDUMW7VP+Wdk9y6qUpKwbSN9pIu3m3UmjZC7 6923PlCyPXBkAIcLrTExf7wVn9lpMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCDEcV8PvkUZNu4 G2L9n0MO6Y7YvG2Dv4MMHjjrO4szSzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MjAxNzA4NTFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAcR4q9/r67a4AQO4FqADDFxMOAReHp2+m m+6/hiSTqT0t8skMyEoZyYQxi7YeIa5qNXUQ8pUTmoX1JevYvhbfQwRJ/0YRsgHNgz325q/u1Zf8 /DiWzRJj2e4rvROWP7byrHDB2U0P8z6LIWfmd2IcOi4UmgotEQrG1NOpaDFInuqzELzuymhnwHfG K62v3d0Zi8qO9h/ad+t+Ba6ohoNCDLbX3JesL9X2fcjRLbcUeFXtFWkiYt5ud/yC2DNb4hpzvCNb NCzm5F+FcLL5TXTGZXJ7FSjC01xtcBkG81MdCHIpj6bNOCI0DRf+M3YKTpOmx72CnYOXy4aU1oZX vfgINA== --94eb2c188d56940bb80557326ab9-- From nobody Sun Aug 20 10:17:26 2017 Return-Path: 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 3634113263F for ; Sun, 20 Aug 2017 10:17:24 -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] 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 MpJjPjHqDV4x for ; Sun, 20 Aug 2017 10:17:22 -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 B0FB31321EC for ; Sun, 20 Aug 2017 10:17:22 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (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 E215F7A330D for ; Sun, 20 Aug 2017 17:17:21 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Sun, 20 Aug 2017 13:17:26 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: References: <3F351A4F-6BFB-48FF-94B0-949AFE355606@dukhovni.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] MTA-STS and HTTP cache control X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 17:17:24 -0000 > On Aug 20, 2017, at 1:08 PM, Daniel Margolis = wrote: >=20 > Policies fetched via HTTPS are only valid if the HTTP response code is = 200 (OK). > HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as = specified in > RFC7234) MUST NOT be used. I forget, is non-support of redirects intended to simplify the policy = retrieval code at the sending MTA , or is it a security concern? I am all for = making the service accessible to bare-bones HTTPS implementations, and so am = not asking for redirect support, just wanted to check the motivation... Perhaps = the rationale should be stated in the draft? --=20 Viktor. From nobody Sun Aug 20 10:24:29 2017 Return-Path: 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 A9C1E13263F for ; Sun, 20 Aug 2017 10:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 O2gFRLo6S5xP for ; Sun, 20 Aug 2017 10:24:25 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94AC81321EC for ; Sun, 20 Aug 2017 10:24:25 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id 76so24117591ith.0 for ; Sun, 20 Aug 2017 10:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XUkMG1Akf5x+Xg9XNvOiscVuKA31z+YLg0gIVpZNnW4=; b=gp1L61vZf7VGloiNrIo+B+6tCSTJLCEDpO2M01c9/GrYVLW0rtNvaGLXs3S4Is1sIL DJIKoOQa68IT3Qd7vpmNv/zFwWRL8ICp3K0xWmVLHw5DPKBPe69e9bF0zdDsI5dcf+D6 3PQo1QxLFD+PWlNak8rzBKkoWPpqEr+VHdmp1UBT1GAPg6/jfRB+SNSt1A5T8I+i+6ii dv0HihFyBhAec99c8qXEaqGWbFE9YSnbN0tELxOXBBTFQbLjOWZj5h2w8LHCRnJnBycJ hl0aUY4vnwWoZyHokCHGGPmOEOXZ43Yf/ddKpbjVD5n/lg+1eMmWy4rqASOHxmRkEaVC kq1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XUkMG1Akf5x+Xg9XNvOiscVuKA31z+YLg0gIVpZNnW4=; b=on7YPs96hHgaYlMDn1tQec9MbsKn/s1Lg1dMOY6BE9t0TBNltj8M+MR/hrGE1Drvf/ cMEpMH6M/g2MX/ns5R0S6UYFdoVjrzKcmlC9cSI64+ZNtEYLHLgy0hAM+/5gIwZxxlwL leEVZpeN+Pe4dBvQ82wB27upECklFTj14xZFeItajwBlpbQXijC2Wl/kq+K/iVRhVD5v rZj/hf5+hwBCq0MSBdfdNXGawPWS5CDI4rByXpYA1J4SOLg8rE9mU3UMRhAv3CyPfHBy +1A/JlGc89483+r2upMO3d2rdJ97pj7LVAPL/dLJoQOmbwXdqUlILTYZ7lyvKacXIcgg RtOg== X-Gm-Message-State: AHYfb5hJ6D71tDl+mk+6DC6g3+ycPVqcAKyYDyFUbsf20C+em8AB7YMc jY6PU+wFR/dV2Ox3AJm6HNluY7LRFfPDUKc= X-Received: by 10.36.204.198 with SMTP id x189mr4244844itf.124.1503249864233; Sun, 20 Aug 2017 10:24:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.159 with HTTP; Sun, 20 Aug 2017 10:24:23 -0700 (PDT) From: Daniel Margolis Date: Sun, 20 Aug 2017 19:24:23 +0200 Message-ID: To: uta@ietf.org, Binu Ramakrishnan Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0602fe32ea03055732a251" Archived-At: Subject: [Uta] 302 redirects (was "MTA-STS and HTTP cache control") X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 17:24:28 -0000 --94eb2c0602fe32ea03055732a251 Content-Type: multipart/alternative; boundary="94eb2c0602fe2b2642055732a261" --94eb2c0602fe2b2642055732a261 Content-Type: text/plain; charset="UTF-8" So, the *motivation* for this was simplification: if you allow 302s, you have to specify a bit more clearly what the behavior is for things like a 302 to a HTTP URI, max redirect depth, etc. In truth, though, I've never been super happy with the prohibition on 302s, since it seems to make policy delegation (i.e. "My MX points to Microsoft; use their policy as well") easier than having your mail provider also host a policy for you using SNI. I could personally be convinced that we *should* allow 302s. I seem to recall Binu felt more strongly in the converse, though, so I will let him chime in and maybe correct me. ;) On Sun, Aug 20, 2017 at 7:17 PM, Viktor Dukhovni wrote: > > > On Aug 20, 2017, at 1:08 PM, Daniel Margolis > wrote: > > > > Policies fetched via HTTPS are only valid if the HTTP response code is > 200 (OK). > > HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as specified > in > > RFC7234) MUST NOT be used. > > I forget, is non-support of redirects intended to simplify the policy > retrieval > code at the sending MTA , or is it a security concern? I am all for making > the service accessible to bare-bones HTTPS implementations, and so am not > asking > for redirect support, just wanted to check the motivation... Perhaps the > rationale > should be stated in the draft? > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --94eb2c0602fe2b2642055732a261 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, the motivation=C2=A0for this was simplification= : if you allow 302s, you have to specify a bit more clearly what the behavi= or is for things like a 302 to a HTTP URI, max redirect depth, etc.=C2=A0
In truth, though, I've never been super happy with th= e prohibition on 302s, since it seems to make policy delegation (i.e. "= ;My MX points to Microsoft; use their policy as well") easier than hav= ing your mail provider also host a policy for you using SNI. I could person= ally be convinced that we should=C2=A0allow 302s. I seem to recall B= inu felt more strongly in the converse, though, so I will let him chime in = and maybe correct me. ;)

On Sun, Aug 20, 2017 at 7:17 PM, Viktor Dukhovni <ietf-d= ane@dukhovni.org> wrote:

> On Aug 20, 2017, at 1:08 PM, Daniel Margolis <dmargolis@google.com> wrote:
>
> Policies fetched via HTTPS are only valid if the HTTP response code is= 200 (OK).
> HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as specifie= d in
> RFC7234) MUST NOT be used.

I forget, is non-support of redirects intended to simplify the polic= y retrieval
code at the sending MTA , or is it a security concern?=C2=A0 I am all for m= aking
the service accessible to bare-bones HTTPS implementations, and so am not a= sking
for redirect support, just wanted to check the motivation...=C2=A0 Perhaps = the rationale
should be stated in the draft?

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--94eb2c0602fe2b2642055732a261-- --94eb2c0602fe32ea03055732a251 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMK8x525biWylzaTdKMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTE4NDIxNVoXDTE3MTAx ODE4NDIxNVowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwhqodpCO7YNSzRIz9ahzJEd2Fmnm1g9pYE2GUs5S8c6Jh JLiZkF4+kTvQVptWmuoWxWqgeIJcqZKozIYoNl06ecCUcCSo/61I+QeD061Vfl9SemzDYrK9IJ5i fsx9sXOD+c20D4Lef7F0wC9azTDs36EwgEDBcLKUef5/Y/n3TDPth8kllj0cKBitt1MC2Il95W7a MyESYucDAH7gSG/dIOGNUaIh+vLLMtRvDQVRfveOum2uUf52bF3rywDJ32dvPCDVsRJHWuhBUfaP shyNiw4d/NzDjMdc504m+GABUpF9r8203gWdhHMxPyeDIzeV7wujWEZ19c0jOcFwdpupAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFB8LoXS3E+322ae/sSMWqyi4zefEMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCeAGD8kMXY iuahwdAzZ8iUfQSAM9M8Q1JPN+jXR6gcJXagqqdjHep1KcrhYx4xvhAUurzdH0AtzjdHuS1OKOj4 OYaMUtjuSYQ6SfFdpkM6K/Ih9IklpIV4BynT4/8D6WROz5f+sQGMf22geoCWbRUsBZv7GgMIWg+1 w6F7FiSFR7NKTBRZS4y/SHv0LCtC12JHyyVQrbxrjXy2tIcrhKC0DhToxe4s9aIA/kauGUSGXyLa U55gCBKpReCTtn1b4aQIwJp9aj0wDzfqs88hyIkWKDUMW7VP+Wdk9y6qUpKwbSN9pIu3m3UmjZC7 6923PlCyPXBkAIcLrTExf7wVn9lpMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCB9qJws9kM7kROj 9Fojrs0VbHc6A9OmoiAr5E6BQrqURDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MjAxNzI0MjRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAWKjzEOJ6918oWbdAg1kmC9bqp/AedlDa uhtcBX/4ECFfTIth1UitwfYfy51Jqn1rJE9rG5ZGp4OkPj/yrhBJGLXgP2NXv5tPtOVBLrrsP21W q45X+qQoSvo0oBxyIDvUYIddY/UhZRH/FDSTMs2zTrw9lzWRMEVd8w06UMjrgLRFkr2hlBWg/sw0 0cCryzBuNpzz+OvNbJ0lng7A2MByKZ/wzs0fSGXApjD+7fr//xIh7sVEoPnysPeJP3lugeqGxv2R nkIiq2dDH7PhjHFfkn+PBwx8Pn8ghmSJ5uFnTSEj94bvHJzvuOOKP4//ioZ+9kZpFMSJSrqW/zC/ ifMfgQ== --94eb2c0602fe32ea03055732a251-- From nobody Mon Aug 21 11:46:54 2017 Return-Path: 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 A1F12132A86 for ; Mon, 21 Aug 2017 11:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.31 X-Spam-Level: X-Spam-Status: No, score=0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 0GHWpmIDcNDg for ; Mon, 21 Aug 2017 11:46:50 -0700 (PDT) Received: from sonic301-48.consmr.mail.sg3.yahoo.com (sonic301-48.consmr.mail.sg3.yahoo.com [106.10.242.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53C3132AA0 for ; Mon, 21 Aug 2017 11:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1503341177; bh=/FHHhoFtVuCprO9nqhZFksPWvfLW+pvBEvccNBsZ6DA=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=MQaozGaMigCrD4acvOwKtuX8OdXLw+tq5VS3sEZd1i8boFQaudL+DN3SLagST1vtASGiWq2X8Ebq6xRMtaGfRRVJwPQTBDOXfvt8c/+oxa6x2n/MAiqbCIaIbEz/IJVIjFaYok7859LwvEc/CSOa1je8p3yJguxw0PKAZpe/DGbWZB8E4eZV3EzCoSRlVoO0JUpOMG75NsRwhq6yiJh2fC3KAocK0pi32EEoyRsqGZBTC75QMHQM5yzH3JN2dCin/fiTiREUO/IBTi+2OWHwl3RapHvewWkt3JF8G+GkZebAishaXKVyn6/vN/82JFBA0b55YrlzQACy4uiDbhYIPA== X-YMail-OSG: YTc.pgcVM1nNiUI4R7brkWgCoQeykaOUBgVoPoa4OSktsTrAWxgd2Wfg98QaLfD KL3EupbSxT8FlNqbIbsxpciyHunKTcyGqnOsbzz7yCB4o1G9kg3Xk6SWUaAVlInN.mWBVVh7ma48 FwESjosyjt784TAltUG6.xcCjo3BE64Is5HAnAesKYl9cY4Nbol4Vp31W_Lx83qBJ_MlE5Ii5Odk wx5Y8NvNjDzZMPwNsWFm91R7YWIrA0DQMon_pKQdhlMZQti7K5q7pmGMsILWS3O2MFQH8okL8R9T SN2RcVtssuJN_PlG97w71aAsGvPQEewZwJ6VuVv.awOTSVr_5UQdcEdMMuXi65__y9JxIp9bQeSm gFb1zoxV5Om.IbSZ2iM4vH6_AVkr3hggKKlC548LVTvPmB6_OD04YruM14rDLBjOcJz9sNx7HADl 2IhbqSFgXG.XubzPxythLuGHP211wcFCvIGAxQ14O7Bh2jRt_Kox2rNP7o2UbT88YUIBS3OrZm5v RsCvyMUWCTDOdxv7l_FQ- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.sg3.yahoo.com with HTTP; Mon, 21 Aug 2017 18:46:17 +0000 Date: Mon, 21 Aug 2017 18:42:16 +0000 (UTC) From: Binu Ramakrishnan Reply-To: Binu Ramakrishnan To: Daniel Margolis , "uta@ietf.org" Message-ID: <1871090724.2618057.1503340936142@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2618056_392428065.1503340936139" X-Mailer: WebService/1.1.10391 YahooMailNeo Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8 Archived-At: Subject: Re: [Uta] 302 redirects (was "MTA-STS and HTTP cache control") X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 18:46:53 -0000 ------=_Part_2618056_392428065.1503340936139 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My understanding is the primary purpose of a 3xx redirect is policy delegat= ion. For example my MX points to Microsoft, so use their policy. This is ce= rtainly useful, however in my opinion it is less compelling use case becaus= e of the following observation: In case of 3rd party provider model, the provider is required to host an HT= TPS endpoint for every hosted domain, whether for doing a 3xx redirect or s= erving a policy. Since we need HTTPS endpoint for every domain, why not ser= ve the policy itself? If the argument is to have one policy file shared by = all domains, then as a provider, you may serve a shared file or reverse pro= xy the policy file from the right server. >From a security angle, by not supporting 3xx redirect, I think we simplifie= d the policy retrieval and have one less thing to worry about (in spec and = implementation). Thanks,-binu From: Daniel Margolis To: uta@ietf.org; Binu Ramakrishnan =20 Sent: Sunday, 20 August 2017 10:24 AM Subject: 302 redirects (was "MTA-STS and HTTP cache control") =20 So, the motivation=C2=A0for this was simplification: if you allow 302s, you= have to specify a bit more clearly what the behavior is for things like a = 302 to a HTTP URI, max redirect depth, etc.=C2=A0 In truth, though, I've never been super happy with the prohibition on 302s,= since it seems to make policy delegation (i.e. "My MX points to Microsoft;= use their policy as well") easier than having your mail provider also host= a policy for you using SNI. I could personally be convinced that we should= =C2=A0allow 302s. I seem to recall Binu felt more strongly in the converse,= though, so I will let him chime in and maybe correct me. ;) On Sun, Aug 20, 2017 at 7:17 PM, Viktor Dukhovni w= rote: > On Aug 20, 2017, at 1:08 PM, Daniel Margolis wrote= : > > Policies fetched via HTTPS are only valid if the HTTP response code is 20= 0 (OK). > HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as specified i= n > RFC7234) MUST NOT be used. I forget, is non-support of redirects intended to simplify the policy retri= eval code at the sending MTA , or is it a security concern?=C2=A0 I am all for m= aking the service accessible to bare-bones HTTPS implementations, and so am not a= sking for redirect support, just wanted to check the motivation...=C2=A0 Perhaps = the rationale should be stated in the draft? -- =C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor. ______________________________ _________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/ listinfo/uta =20 ------=_Part_2618056_392428065.1503340936139 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My understanding is the primary purpose o= f a 3xx redirect is policy delegation. For example my MX points to Microsof= t, so use their policy. This is certainly useful, however in my opinion it = is less compelling use case because of the following observation:
=

In case of 3rd= party provider model, the provider is required to host an HTTPS endpoint f= or every hosted domain, whether for doing a 3xx redirect or serving a polic= y. Since we need HTTPS endpoint for every domain, why not serve the policy = itself? If the argument is to have one policy file shared by all domains, t= hen as a provider, you may serve a shared file or reverse proxy the policy = file from the right server.

From a security angle, by not supporting 3xx redirect, I= think we simplified the policy retrieval and have one less thing to worry = about (in spec and implementation).

Thanks,
-binu

=
From: Daniel Margolis <dmargolis@google.com>
= To: uta@ietf.org; Binu Ra= makrishnan <prbinu@yahoo.com>
Sent: Sunday, 20 August 2017 10:24 AM
Subject: 302 redirects (was "MTA-STS and HTT= P cache control")

So, the motivation for this was sim= plification: if you allow 302s, you have to specify a bit more clearly what= the behavior is for things like a 302 to a HTTP URI, max redirect depth, e= tc. 

In truth, though, I've never = been super happy with the prohibition on 302s, since it seems to make polic= y delegation (i.e. "My MX points to Microsoft; use their policy as well") e= asier than having your mail provider also host a policy for you using SNI. = I could personally be convinced that we should allow 302s. I se= em to recall Binu felt more strongly in the converse, though, so I will let= him chime in and maybe correct me. ;)

On Su= n, Aug 20, 2017 at 7:17 PM, Viktor Dukhovni <ietf-dane@dukhovni.org<= /a>> wrote:

> On Aug 20, 2017, at 1:08 PM, Daniel Margolis <dmargolis@= google.com> wrote:
>
> Policies fetched via HTTPS are only valid if the HTTP response code is= 200 (OK).
> HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as specifie= d in
> RFC7234) MUST NOT be used.

I forget, is non-support of redirects intended to simplify the polic= y retrieval
code at the sending MTA , or is it a security concern?  I am all for m= aking
the service accessible to bare-bones HTTPS implementations, and so am not a= sking
for redirect support, just wanted to check the motivation...  Perhaps = the rationale
should be stated in the draft?

--
        Viktor.

______________________________ _________________
Uta mailing list
Uta@= ietf.org
https://www.iet= f.org/mailman/ listinfo/uta



=
------=_Part_2618056_392428065.1503340936139-- From nobody Mon Aug 21 12:47:47 2017 Return-Path: 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 E085A132719 for ; Mon, 21 Aug 2017 12:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 lQXWAFZOw_G2 for ; Mon, 21 Aug 2017 12:47:43 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4119F13271F for ; Mon, 21 Aug 2017 12:47:43 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id o196so9466427ioe.0 for ; Mon, 21 Aug 2017 12:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=95I/m0sPD7mWpwn1mMKZMH7D9sJ8HFqccegRVdGW4N0=; b=K5gWOLsujnWi3Hywqu4BQLQB8t9+PLvMA4hVgmMUgE20iBznKEku24yhCc8JuLbfsc sS7mkXuAoUu1B+ez+BJNeYm0jCDaixJDm1FQMK9pkO7PeVgYZ/OCkJvTsSWR2jVbVByN PdesvryWxDHG3v6Kzoa1YDP0lVJ2yK5P+v28thw7cDSlcitMPCqsYjHqVPvBYD127+EI EW2rYiCBr12Pw76ybZYy82QNTcsIQ8Lj+nAJOIH3ici0n+6a96e6EJVm4LV7BY0vrE3U bnkVkBadJGxuHQCEAwItrhh4sWRzmHLtrNx2RiQJc9nlBNAIK0sv/xkG8B8YZdIJ/OvQ H4lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=95I/m0sPD7mWpwn1mMKZMH7D9sJ8HFqccegRVdGW4N0=; b=ucK577KQcIWZZPCJudsv5xqbq5sOH57IoJHsAz4Dzj4a0olkLhMcm9etA951v7mIfm cnAPtLkJ+HHli+rZtnlD9qG3zdmF7P9dek/a349U66fEWTq2h4h5gIY4sIo9Mpgo2aj1 jYLaPZMKpy85zi8mhG1P565hetk46cTaAPxu/Gq4LqorCfOd7r8xMxYMjyoLZEZwnv6g WAURSMYHpF8wUD5wl9o3SIXTOY5QNdcp+pQBnR7OTkcuWSJJrutmTva2mvGKPXIfQdw4 gsqTBUERpQXTFSfYhU654eoSs59oOjYCbImBkQDX283ZtVefgI80ncn/89eOd/j1foOB HNnA== X-Gm-Message-State: AHYfb5jO+H0gdi7JIebeW9j8kDV6MFbUTroASS4frUaT6dZdOK2YidSL 38+gJCIKoq6q4I2xCC4zYHl82amoIX9K X-Received: by 10.107.43.88 with SMTP id r85mr2402344ior.177.1503344862100; Mon, 21 Aug 2017 12:47:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.159 with HTTP; Mon, 21 Aug 2017 12:47:41 -0700 (PDT) In-Reply-To: <1871090724.2618057.1503340936142@mail.yahoo.com> References: <1871090724.2618057.1503340936142@mail.yahoo.com> From: Daniel Margolis Date: Mon, 21 Aug 2017 21:47:41 +0200 Message-ID: To: Binu Ramakrishnan Cc: "uta@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11395e9e83ab2d055748c067" Archived-At: Subject: Re: [Uta] 302 redirects (was "MTA-STS and HTTP cache control") X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 19:47:46 -0000 --001a11395e9e83ab2d055748c067 Content-Type: multipart/alternative; boundary="001a11395e9e7bd265055748c02f" --001a11395e9e7bd265055748c02f Content-Type: text/plain; charset="UTF-8" My point was that if you host on Microsoft, you could have https://policy.example.com <-- cert for example.com, 302s to policy.microsoft.com https://policy.microsoft.com <-- cert for microsoft.com This way you don't have to give Microsoft your cert and they don't have to set up SNI--but conversely, you have to set up your own 302 redirector. Some users may prefer this to SNI, but I don't know if it's worth the complexity it introduces. I do agree this brings nice simplicity. *shrug* I'm open to feedback on this. I never felt strongly about either direction. Dan On Mon, Aug 21, 2017 at 8:42 PM, Binu Ramakrishnan wrote: > My understanding is the primary purpose of a 3xx redirect is policy > delegation. For example my MX points to Microsoft, so use their policy. > This is certainly useful, however in my opinion it is less compelling use > case because of the following observation: > > In case of 3rd party provider model, the provider is required to host an > HTTPS endpoint for every hosted domain, whether for doing a 3xx redirect or > serving a policy. Since we need HTTPS endpoint for every domain, why not > serve the policy itself? If the argument is to have one policy file shared > by all domains, then as a provider, you may serve a shared file or reverse > proxy the policy file from the right server. > > From a security angle, by not supporting 3xx redirect, I think we > simplified the policy retrieval and have one less thing to worry about (in > spec and implementation). > > Thanks, > -binu > > ------------------------------ > *From:* Daniel Margolis > *To:* uta@ietf.org; Binu Ramakrishnan > *Sent:* Sunday, 20 August 2017 10:24 AM > *Subject:* 302 redirects (was "MTA-STS and HTTP cache control") > > So, the *motivation* for this was simplification: if you allow 302s, you > have to specify a bit more clearly what the behavior is for things like a > 302 to a HTTP URI, max redirect depth, etc. > > In truth, though, I've never been super happy with the prohibition on > 302s, since it seems to make policy delegation (i.e. "My MX points to > Microsoft; use their policy as well") easier than having your mail provider > also host a policy for you using SNI. I could personally be convinced that > we *should* allow 302s. I seem to recall Binu felt more strongly in the > converse, though, so I will let him chime in and maybe correct me. ;) > > On Sun, Aug 20, 2017 at 7:17 PM, Viktor Dukhovni > wrote: > > > > On Aug 20, 2017, at 1:08 PM, Daniel Margolis > wrote: > > > > Policies fetched via HTTPS are only valid if the HTTP response code is > 200 (OK). > > HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as specified > in > > RFC7234) MUST NOT be used. > > I forget, is non-support of redirects intended to simplify the policy > retrieval > code at the sending MTA , or is it a security concern? I am all for making > the service accessible to bare-bones HTTPS implementations, and so am not > asking > for redirect support, just wanted to check the motivation... Perhaps the > rationale > should be stated in the draft? > > -- > Viktor. > > ______________________________ _________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/ listinfo/uta > > > > > > --001a11395e9e7bd265055748c02f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 21, 2017 at 8:42 PM, Binu Ramakrishnan = <prbinu@yahoo.com<= /a>> wrote:
My understanding is the primary purpose of a 3xx redirect is p= olicy delegation. For example my MX points to Microsoft, so use their polic= y. This is certainly useful, however in my opinion it is less compelling us= e case because of the following observation:

<= div id=3D"m_-7536084232016401492yui_3_16_0_ym19_1_1502904853786_155969" dir= =3D"ltr">In case of 3rd party provider model, the provider is required to h= ost an HTTPS endpoint for every hosted domain, whether for doing a 3xx redi= rect or serving a policy. Since we need HTTPS endpoint for every domain, wh= y not serve the policy itself? If the argument is to have one policy file s= hared by all domains, then as a provider, you may serve a shared file or re= verse proxy the policy file from the right server.

From a security angle, by not supporting 3xx redirect, I think w= e simplified the policy retrieval and have one less thing to worry about (i= n spec and implementation).

Thanks,
-binu

= From: Daniel Margolis <<= a href=3D"mailto:dmargolis@google.com" target=3D"_blank">dmargolis@google.c= om>
To: uta@ietf.org; Binu Ramakrish= nan <prbinu@yahoo.= com>
Sent: Sunda= y, 20 August 2017 10:24 AM
Subject:= 302 redirects (was "MTA-STS and HTTP cache control")<= br>

So, the motivation=C2=A0for this was simplification: if you allow 302= s, you have to specify a bit more clearly what the behavior is for things l= ike a 302 to a HTTP URI, max redirect depth, etc.=C2=A0

In truth, thou= gh, I've never been super happy with the prohibition on 302s, since it = seems to make policy delegation (i.e. "My MX points to Microsoft; use = their policy as well") easier than having your mail provider also host= a policy for you using SNI. I could personally be convinced that we sho= uld=C2=A0allow 302s. I seem to recall Binu felt more strongly in the co= nverse, though, so I will let him chime in and maybe correct me. ;)

On Sun, Aug 20, 2017 at 7:17 PM, Vikto= r Dukhovni <ietf-dane@dukhovni.org> wrote:

> On Aug 20, 2017, at 1:08 PM, Daniel Margolis <dmargolis@google.com>= wrote:
>
> Policies fetched via HTTPS are only valid if the HTTP response code is= 200 (OK).
> HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as specifie= d in
> RFC7234) MUST NOT be used.

I forget, is non-support of redirects intended to simplify the polic= y retrieval
code at the sending MTA , or is it a security concern?=C2=A0 I am all for m= aking
the service accessible to bare-bones HTTPS implementations, and so am not a= sking
for redirect support, just wanted to check the motivation...=C2=A0 Perhaps = the rationale
should be stated in the draft?

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

______________________________ _________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/ listinfo/uta



<= /div>
--001a11395e9e7bd265055748c02f-- --001a11395e9e83ab2d055748c067 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMK8x525biWylzaTdKMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTE4NDIxNVoXDTE3MTAx ODE4NDIxNVowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwhqodpCO7YNSzRIz9ahzJEd2Fmnm1g9pYE2GUs5S8c6Jh JLiZkF4+kTvQVptWmuoWxWqgeIJcqZKozIYoNl06ecCUcCSo/61I+QeD061Vfl9SemzDYrK9IJ5i fsx9sXOD+c20D4Lef7F0wC9azTDs36EwgEDBcLKUef5/Y/n3TDPth8kllj0cKBitt1MC2Il95W7a MyESYucDAH7gSG/dIOGNUaIh+vLLMtRvDQVRfveOum2uUf52bF3rywDJ32dvPCDVsRJHWuhBUfaP shyNiw4d/NzDjMdc504m+GABUpF9r8203gWdhHMxPyeDIzeV7wujWEZ19c0jOcFwdpupAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFB8LoXS3E+322ae/sSMWqyi4zefEMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCeAGD8kMXY iuahwdAzZ8iUfQSAM9M8Q1JPN+jXR6gcJXagqqdjHep1KcrhYx4xvhAUurzdH0AtzjdHuS1OKOj4 OYaMUtjuSYQ6SfFdpkM6K/Ih9IklpIV4BynT4/8D6WROz5f+sQGMf22geoCWbRUsBZv7GgMIWg+1 w6F7FiSFR7NKTBRZS4y/SHv0LCtC12JHyyVQrbxrjXy2tIcrhKC0DhToxe4s9aIA/kauGUSGXyLa U55gCBKpReCTtn1b4aQIwJp9aj0wDzfqs88hyIkWKDUMW7VP+Wdk9y6qUpKwbSN9pIu3m3UmjZC7 6923PlCyPXBkAIcLrTExf7wVn9lpMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDCqbNbJLbDtnLK gsh83WK4dC4KALyOgNP8Itnv5UbcrDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MjExOTQ3NDJaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAfNprLoCwnhIBHl+7qKnYMCJCRLCRAMqY aRUBoqaKU2yJ56ikQ8J8JpfPOnFOHMp0U5KJQwwfg8IGySwyAWGNFUWUzfNI62ieXePdHuxvNDVr C5u9+O3RkNnvSMDX1b6hUZgopLtGopsWPR3JEirJvum84ijshVuAsECVQkEDdUTRSeJ6D3rnP3OG /gGAmLy+YwmHIQ4yd3Ggr+uNoTn1evE0L4EhbV6UOiBNgJPFBxrwacpJQgMg4Lgf1OARUcAntjfb RxL9GTKwaNsQVUFPJYoASkguF/zZ5KuuEON9T1Yx9kcfFqDo+v1oSTnRV/NeDaN0OS+Mcd7Cptsv dmEiMg== --001a11395e9e83ab2d055748c067--

= On Tue, Aug 8, 2017 at 10:20 PM, Viktor Dukhovni <ietf-dane@dukhovni.= org> wrote:

> On Aug 8, 2017, at 6:24 PM, Daniel Margolis <dmargolis@google.com> wrote:
>
> mode=3Dnone still requires period refresh via HTTPS.=C2=A0 So it fails= the
> requirement to be able to erase all trace of STS.
>
> How do you mean? You have to continue to serve this policy until all o= ther previously served policies have expired; past that point you can turn = it down at will.

No.=C2=A0 That's the point, you can't generally just turn it= out at
will without some care, or else risk creating refresh failures
during a transition period.

Sorry, can = you give an example? As I stated before:

> (D), I believe, is i= nvariant in all implementations: any hypothetical
> "removal&quo= t; flow *will* involve serving the "removal" signal (whatever it<= br>> is--a max_age=3D0 policy or anything else) until the last point in = time the
> *old* policy was served + that policy's max_age. So (D= ) does not
> distinguish between different "removal" option= s.

The time period during which a domain who opts out of STS must pu= blish the "opt out" signal--regardless of how it is expressed--is= the same in all possible implementations of any opt-out signal.
=C2=A0
When a "none" policy is cached, it is still a policy and still subject to periodic refresh, perhaps you're suggesting to use
"none" as a synonym for "max_age=3D0" that still leaves= us with
a usable cache time, in which case are free to use NODATA/NXDOMAIN
as that TTL is no longer requires.

I'm = not entirely sure I understand you. To be clear, my point was that "mo= de=3Dnone" can be an indicator of "don't check anything again= st this policy." The rest--policy caching--still applies as normal.=C2= =A0
=C2=A0
So the new process would be:

* Publish a "none" policy with a comparatively short "max_ag= e".

Call the above time "t0&q= uot;.
=C2=A0
* Remove the TXT record.

Call this time= "t1."

Note that this step (removal of t= he TXT record) can only safely be done once any previously published= =C2=A0policies are expired. Normally this would require that =C2=A0"t1= > t0 + previous_max_age" (though of course it's possible for <= i>previous-previous policies=C2=A0to have been published with overlappi= ng max_ages).
=C2=A0
* After some time (all previous policies expire) remove the
=C2=A0 "none" policy.

This ca= n also happen at "t1", if the above is observed.
=C2=A0=
Now the clients can:

=C2=A0 =C2=A0* Cache policies with empty id (not otherwise valid)
=C2=A0 =C2=A0 =C2=A0when TXT lookup returns NXDOMAIN/NODATA.=C2=A0 Except =C2=A0 =C2=A0 =C2=A0when policy mode is "none" in which case the = cache
=C2=A0 =C2=A0 =C2=A0is immediately flushed, and stays that way unless
=C2=A0 =C2=A0 =C2=A0the TXT reappears at some point.=C2=A0 Refresh per max_= age
=C2=A0 =C2=A0 =C2=A0and proactive update attempt cycle.

=C2=A0 =C2=A0* When "none" is seen with a "TXT" id, cac= he that as
=C2=A0 =C2=A0 =C2=A0indicated, but if TXT disappears at any time, flush
=C2=A0 =C2=A0 =C2=A0the policy then.

This seems to work better than "max_age =3D 0".=C2=A0 However, th= e
same cannot be said of "report", which has no clean transition to policy removal, as dropping the TXT record still leads to
policy refresh with no end in sight, while a suddenly missing
policy (404 and the like) is not defined (deliberately IIRC
and likely correctly) to mean policy removal.

I don't understand this statement. If you have a cached policy w= hich has expired and there is no TXT record, why would you be refreshing th= e policy at all?=C2=A0
=C2=A0

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

--001a1143cecc6b73970556541264-- --001a1143cecc78f6f60556541226 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMK8x525biWylzaTdKMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTE4NDIxNVoXDTE3MTAx ODE4NDIxNVowJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwhqodpCO7YNSzRIz9ahzJEd2Fmnm1g9pYE2GUs5S8c6Jh JLiZkF4+kTvQVptWmuoWxWqgeIJcqZKozIYoNl06ecCUcCSo/61I+QeD061Vfl9SemzDYrK9IJ5i fsx9sXOD+c20D4Lef7F0wC9azTDs36EwgEDBcLKUef5/Y/n3TDPth8kllj0cKBitt1MC2Il95W7a MyESYucDAH7gSG/dIOGNUaIh+vLLMtRvDQVRfveOum2uUf52bF3rywDJ32dvPCDVsRJHWuhBUfaP shyNiw4d/NzDjMdc504m+GABUpF9r8203gWdhHMxPyeDIzeV7wujWEZ19c0jOcFwdpupAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFB8LoXS3E+322ae/sSMWqyi4zefEMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCeAGD8kMXY iuahwdAzZ8iUfQSAM9M8Q1JPN+jXR6gcJXagqqdjHep1KcrhYx4xvhAUurzdH0AtzjdHuS1OKOj4 OYaMUtjuSYQ6SfFdpkM6K/Ih9IklpIV4BynT4/8D6WROz5f+sQGMf22geoCWbRUsBZv7GgMIWg+1 w6F7FiSFR7NKTBRZS4y/SHv0LCtC12JHyyVQrbxrjXy2tIcrhKC0DhToxe4s9aIA/kauGUSGXyLa U55gCBKpReCTtn1b4aQIwJp9aj0wDzfqs88hyIkWKDUMW7VP+Wdk9y6qUpKwbSN9pIu3m3UmjZC7 6923PlCyPXBkAIcLrTExf7wVn9lpMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDUpIlsG4Rspotx ZzYOSMGuf9RSV5g3pLL3v7LZayx9ejAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MDkxNTUyNTBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAWYQDy7svMb15yOX2OT8we0ixRc+hnG8J 6FC2ybY5zQkeZlJzlb+HxxxORnl5xjBwXwhE4RZATAvn4VzPtGt/e7bOj3GIOTH0NmrXY/dF5wkS algVLe1n1MvsYqmk5GpkrAFepwiuZ3zahKFJdGwqo++jAcLwoF0hEUEOMwsBUV0NGYDNiVZYlQMJ 0W7eGNe5oDVLgnPu8mkHhvBTWkESjhKieFUtr/ltSiSA0nfWw8p1xlGCi13USWFBH1o+qkHXsUDH GDkT9D6i8rs+C5xASqQ6wXRPHh7oYyJB3vJaYXyyb/Wy+GEZXGbdbS7N9vVF7PwIES3XbRgPBUeY xW+1GQ== --001a1143cecc78f6f60556541226-- From nobody Wed Aug 9 10:02:28 2017 Return-Path: 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 8A9FC132021 for ; Wed, 9 Aug 2017 10:02:22 -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, SPF_PASS=-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 zy9Jkn4LI8JK for ; Wed, 9 Aug 2017 10:02:20 -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 093BA132440 for ; Wed, 9 Aug 2017 10:02:18 -0700 (PDT) Received: from splunge.local (73-93-154-248-static.hfc.comcastbusiness.net [73.93.154.248] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v79H2GUu002894 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 9 Aug 2017 10:02:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1502298138; bh=iJ4OulwCTOvxkNbnIU1YIejPMZU64AFhBFhNJIEimkM=; h=Subject:To:References:From:Date:In-Reply-To; b=ONEtubuElKNj9w8K+ZcDLNDCdeIJaN8V32hgInDu4t9CdnbRg+MwGbwowRECzg1Hv 5mQaLr74vXNnovO0Mt881cYW3/ZcNr7RhtolIq867uWcdytjN8j1W0psHb7NBs4gHj rCttMj1RmWArJiN7z8nG7svl3gRf8W3jaPE/pqng= To: uta@ietf.org References: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> <8d9f92ea-6cea-1828-0f4b-3487240a81bd@bluepopcorn.net> <6c1546c6-69e0-1d2e-1084-5013f7241073@isode.com> From: Jim Fenton Message-ID: <98a4f421-80ec-409d-3c1b-3530a7f9df1f@bluepopcorn.net> Date: Wed, 9 Aug 2017 10:02:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <6c1546c6-69e0-1d2e-1084-5013f7241073@isode.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 17:02:22 -0000 On 8/9/17 6:33 AM, Alexey Melnikov wrote: > Hi, > > (As a participant) > > > On 09/08/2017 14:07, Brotman, Alexander wrote: >> Jim, >> >> To be clear, you'd like to remove the headers (5.3) and filename >> (5.1) sections, and have all the filtering based solely on the >> subject that is specified in 5.3? > I don't think Jim made a convincing argument for removing new header > fields. From my personal experience writing IMAP based applications > that search for this information (e.g. to search and process "all > reports from a particular domain") is easier with new header fields > than doing a search on a Subject which has complicated structure. This > has nothing to do with whether the same mailbox receives multiple > types of email messages, this is still a useful functionality if a > particular mailbox receives only TLSRPT reports. > > As per my followup discussion with Jim libraries for generating > messages need to be able to add new header fields anyway. If people > have real world experience about whether this is problematic, I would > like to hear it. > > > Regarding filenames - I am ambivalent. If you need this information > somewhere, you will need to define new header fields as well. I'll leave it up to the rough consensus of the WG. But my expectation is that the vast majority of TLSRPT mail will be directed to addresses only used for that purpose, and then piped directly into an agent that does something with them -- probably stuff the data into a database, which is then used to generate composite reports for the domain. IMAP won't be involved at all, and filtering will be done only by database lookups. If the same information from the body of the report is also contained in new header fields, message subject, or attachment filename, the specification needs to be clear about what happens when they don't agree: does the recipient discard reports that are inconsistent, and if not, which values are used? IMO, it's more straightforward to keep this simple and have the information in only one place. > >> And relating to "draft-ietf-dnsop-attrleaf", could you clarify >> that a bit? Are you asking me to request an alteration of the >> attrleaf document after TLSRPT has been created? > (As Area Director) > Yes. Depending on which documents gets to IESG first, the last one > should include the information. +1. Or if attrleaf goes first, TLSRPT requests an entry in the registry that attrleaf created. -Jim From nobody Wed Aug 9 10:48:33 2017 Return-Path: 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 542861243F3 for ; Wed, 9 Aug 2017 10:48:31 -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] 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 TjMoVrhCGRBf for ; Wed, 9 Aug 2017 10:48:29 -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 4B62B13245F for ; Wed, 9 Aug 2017 10:48:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E3B967A3309; Wed, 9 Aug 2017 17:48:27 +0000 (UTC) Date: Wed, 9 Aug 2017 17:48:27 +0000 From: Viktor Dukhovni To: uta@ietf.org Message-ID: <20170809174827.GQ8146@mournblade.imrryr.org> Reply-To: uta@ietf.org References: <149874228049.6468.6647983832951662733@ietfa.amsl.com> <20170807215520.GM8146@mournblade.imrryr.org> <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> <20170808172002.GN8146@mournblade.imrryr.org> <20170808210631.GO8146@mournblade.imrryr.org> <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 17:48:31 -0000 On Wed, Aug 09, 2017 at 08:52:48AM -0700, Daniel Margolis wrote: > The time period during which a domain who opts out of STS must publish the > "opt out" signal--regardless of how it is expressed--is the same in all > possible implementations of any opt-out signal. Yes, but "report" is NOT an opt-out signal. It is a policy that is subject to further cache refresh. Please describe how you think one correctly phases out a "report" policy without causing apparent policy refresh failures at a sending domain? > > When a "none" policy is cached, it is still a policy and still > > subject to periodic refresh, perhaps you're suggesting to use > > "none" as a synonym for "max_age=0" that still leaves us with > > a usable cache time, in which case are free to use NODATA/NXDOMAIN > > as that TTL is no longer requires. > > I'm not entirely sure I understand you. To be clear, my point was that > "mode=none" can be an indicator of "don't check anything against this > policy." The rest--policy caching--still applies as normal. No, with "none" the policy refresh can stop (and cache flushed) as soon as NXDOMAIN/NODATA is seen for the TXT lookup. The same is not true for "report", to avoid downgrade attacks. > I don't understand this statement. If you have a cached policy which has > expired and there is no TXT record, why would you be refreshing the policy > at all? Because the TXT record presence/absense is *insecure* (no DNSSEC or else we'd be doing DANE!). Therefore the TXT record must ONLY be used: 1. To signal initial policy presence when none is cached. 2. To signal expedited policy refresh when the id changes. 3. [New] To signal policy removal when the policy is "none" and the TXT record "disappears". 4. [New] Conversely to signal policy removal when the policy transitions to "none" and was cached in the absence of a TXT record (still absent). It seems that safe policy removal and cache refresh downgrade resistance needs more discussion to avoid implementation errors. Mere removal of the TXT record is *not* sufficient to stop policy refresh. Recall that policy refresh will typically happen before the policy is expired (more robust continuity) and must not at that time be subject to DNS downgrade. When a policy is refreshed. It will be stored for the advertised max_age even if the TXT record is missing. If a policy just vanishes without a secure signal that it is being removed, that looks like an attack, unless you want to use 404 as a secure policy removal signal (last I asked that was not the case). -- Viktor. From nobody Wed Aug 9 11:14:23 2017 Return-Path: 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 0B3B6132474 for ; Wed, 9 Aug 2017 11:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 X4Vb36Gt5RYS for ; Wed, 9 Aug 2017 11:14:19 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ABE6132448 for ; Wed, 9 Aug 2017 11:14:19 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id 76so1845485ith.0 for ; Wed, 09 Aug 2017 11:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=JYCEKWOOHEnIlIskS8l2dvLnEGqwVjCMhwOsrQ+r0nM=; b=GXXDsaLKZKQB+kFlZxaO3e/U/Z3JCcU0GW8xZdyiJRVFMwMEraELI9Wdj4P5LcboQ7 qJXV6gnCj7n5QfoWpWL/QQHgh288fLTYdkTGbroGBdMMUrEv2eeI9L4+J1v0/byMQUEQ 9dQLLTYeStt0YnOpN/HYqf9gayr7H/6xJYiwEh1icDtftkwM6LsCgCRjI0KNFK1yjw9W vUPSiTHlN8/B6FfkSng1lBSI4ZUY0B10SV7k+7wLqa+84IDJHoZNpgW+FiwJKHH4cb4Y kdiT7kKJnoQHiyl/dYCAy3PKaMxYHGQkSCee80Npf9AITlpbnFYO3PA5pxiS6kk4cIMN oWcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=JYCEKWOOHEnIlIskS8l2dvLnEGqwVjCMhwOsrQ+r0nM=; b=Tio+DtNqJZxMXoIAxWpUJVoByRRrp45kC0d+vgvI8nu3FUSNLd095JvKJLflF7zMIo TaeCAQVBA+Xy6kDEdWWZmIDoOOSKMi2qyvJzeGv38FZePDHdICAIi4vDOUxlbPbXSYnR pq1O+lIQwmMbEJ+tBwi5z97Xi15GOsgNUCsUxlZdMewOA2GqAc8JkcwMq7URSRVqoo3Y qRjIlrSDN/xGKuk83KsK7QSHXwCMLFG5KV7QhUKmNQmt04uhw/W3X+z/Po7iekcDMRK4 UfRhMOB8tzTuQSICksydq2nNePJqWSUVFF5Zgy5XWeyBa8C1ZIdySyXya5moQxovmIbM UdRg== X-Gm-Message-State: AHYfb5gjoHUDbBYr8MiLcaoH1x3VtQMJvKyHy8NE5mdFx46ff5wA9cKQ E3/mu+KtIciHnmNlRo/c30Z8aEtuICAFRTM= X-Received: by 10.36.211.201 with SMTP id n192mr8111475itg.96.1502302458170; Wed, 09 Aug 2017 11:14:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.159 with HTTP; Wed, 9 Aug 2017 11:14:16 -0700 (PDT) In-Reply-To: <20170809174827.GQ8146@mournblade.imrryr.org> References: <149874228049.6468.6647983832951662733@ietfa.amsl.com> <20170807215520.GM8146@mournblade.imrryr.org> <20170808143018.m6zqnapcnkiushfq@LK-Perkele-VII> <20170808172002.GN8146@mournblade.imrryr.org> <20170808210631.GO8146@mournblade.imrryr.org> <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> <20170809174827.GQ8146@mournblade.imrryr.org> From: Daniel Margolis Date: Wed, 9 Aug 2017 11:14:16 -0700 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11499ff6655f050556560cc6" Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal. X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 18:14:22 -0000 --001a11499ff6655f050556560cc6 Content-Type: multipart/alternative; boundary="001a11499ff65df8da0556560c9c" --001a11499ff65df8da0556560c9c Content-Type: text/plain; charset="UTF-8" On Wed, Aug 9, 2017 at 10:48 AM, Viktor Dukhovni wrote: > On Wed, Aug 09, 2017 at 08:52:48AM -0700, Daniel Margolis wrote: > > > The time period during which a domain who opts out of STS must publish > the > > "opt out" signal--regardless of how it is expressed--is the same in all > > possible implementations of any opt-out signal. > > Yes, but "report" is NOT an opt-out signal. It is a policy that > is subject to further cache refresh. Please describe how you > think one correctly phases out a "report" policy without causing > apparent policy refresh failures at a sending domain? > "Report" is not an opt-out signal, but not for the reason you say: a "report" policy still generates TLSRPT reports on failure, and thus is not a true opt-out. It does not, however, result in any change to refresh behavior. Whether a sender has a cached policy has no impact on their behavior with respect to refreshes, does it? > > > When a "none" policy is cached, it is still a policy and still > > > subject to periodic refresh, perhaps you're suggesting to use > > > "none" as a synonym for "max_age=0" that still leaves us with > > > a usable cache time, in which case are free to use NODATA/NXDOMAIN > > > as that TTL is no longer requires. > > > > I'm not entirely sure I understand you. To be clear, my point was that > > "mode=none" can be an indicator of "don't check anything against this > > policy." The rest--policy caching--still applies as normal. > > No, with "none" the policy refresh can stop (and cache flushed) as > soon as NXDOMAIN/NODATA is seen for the TXT lookup. The same is > not true for "report", to avoid downgrade attacks. > That's not true; once a policy expires, it can be flushed from the cache (as it can no longer safely be used). > > I don't understand this statement. If you have a cached policy which has > > expired and there is no TXT record, why would you be refreshing the > policy > > at all? > > Because the TXT record presence/absense is *insecure* (no DNSSEC > or else we'd be doing DANE!). Therefore the TXT record must ONLY > be used: > > 1. To signal initial policy presence when none is cached. > 2. To signal expedited policy refresh when the id changes. > 3. [New] To signal policy removal when the policy is "none" > and the TXT record "disappears". > 4. [New] Conversely to signal policy removal when the policy > transitions to "none" and was cached in the absence of a > TXT record (still absent). > Can you point to what language in the current draft suggests that the behavior with respect to policy refreshing differs if you have a cached policy versus if you do not? I am still not understanding what difference you see here. Mere removal of the TXT record is *not* sufficient to stop policy > refresh. Recall that policy refresh will typically happen > before the policy is expired (more robust continuity) and must > not at that time be subject to DNS downgrade. I believe this is your mistake. While I agree that one should try to refresh a policy prior to expiration, "refresh a policy" means checking the TXT record. Your first sentence ("mere removal of the TXT record...") does not follow from your second sentence. There's zero security advantage in ignoring the TXT record and going straight to HTTPS, since HTTPS also relies upon the (insecure) DNS resolution. As a result, it makes no real sense to refresh the policy if the TXT does not say to do it. A sender who implements this will appear to be compliant with the draft--there's no real harm from doing this, aside from maybe excessive HTTPS requests--but there's no great reason to do this unless you think attackers can only attack the TXT record and not the CNAME/A for the policy host. > When a policy > is refreshed. It will be stored for the advertised max_age > even if the TXT record is missing. > > If a policy just vanishes without a secure signal that it is > being removed, that looks like an attack, unless you want to > use 404 as a secure policy removal signal (last I asked that > was not the case). > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a11499ff65df8da0556560c9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 9, 2017 at 10:48 AM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:
On Wed, Aug 09, 2017 at 08:52:48AM -0700, Daniel Margolis wrote:

> The time period during which a domain who opts out of STS must publish= the
> "opt out" signal--regardless of how it is expressed--is the = same in all
> possible implementations of any opt-out signal.

Yes, but "report" is NOT an opt-out signal.=C2=A0 It is a = policy that
is subject to further cache refresh.=C2=A0 Please describe how you
think one correctly phases out a "report" policy without causing<= br> apparent policy refresh failures at a sending domain?
=
"Report" is not an opt-out signal, but not for the= reason you say: a "report" policy still generates TLSRPT reports= on failure, and thus is not a true opt-out.=C2=A0

It does not, however, result in any change to refresh behavior. Whether a = sender has a cached policy has no impact on their behavior with respect to = refreshes, does it?
=C2=A0
> > When a "none" policy is cached, it is still a policy an= d still
> > subject to periodic refresh, perhaps you're suggesting to use=
> > "none" as a synonym for "max_age=3D0" that st= ill leaves us with
> > a usable cache time, in which case are free to use NODATA/NXDOMAI= N
> > as that TTL is no longer requires.
>
> I'm not entirely sure I understand you. To be clear, my point was = that
> "mode=3Dnone" can be an indicator of "don't check a= nything against this
> policy." The rest--policy caching--still applies as normal.

No, with "none" the policy refresh can stop (and cache flu= shed) as
soon as NXDOMAIN/NODATA is seen for the TXT lookup.=C2=A0 The same is
not true for "report", to avoid downgrade attacks.

That's not true; once a policy expires, it can be= flushed from the cache (as it can no longer safely be used).
=C2= =A0
> I don't understand this statement. If you have a cached policy whi= ch has
> expired and there is no TXT record, why would you be refreshing the po= licy
> at all?

Because the TXT record presence/absense is *insecure* (no DNSSEC
or else we'd be doing DANE!).=C2=A0 Therefore the TXT record must ONLY<= br> be used:

=C2=A0 =C2=A0 1.=C2=A0 To signal initial policy presence when none is cache= d.
=C2=A0 =C2=A0 2.=C2=A0 To signal expedited policy refresh when the id chang= es.
=C2=A0 =C2=A0 3.=C2=A0 [New] To signal policy removal when the policy is &q= uot;none"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and the TXT record "disappears".
=C2=A0 =C2=A0 4.=C2=A0 [New] Conversely to signal policy removal when the p= olicy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 transitions to "none" and was cached = in the absence of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TXT record (still absent).

Can you point to what language in the current draft suggest= s that the behavior with respect to policy refreshing differs if you have a= cached policy versus if you do not? I am still not understanding what diff= erence you see here.=C2=A0

Mere removal of the TXT record is *not* sufficient to stop policy
refresh.=C2=A0 Recall that policy refresh will typically happen
before the policy is expired (more robust continuity) and must
not at that time be subject to DNS downgrade.=C2=A0

I believe this is your mistake. While I agree that one should try = to refresh a policy prior to expiration, "refresh a policy" means= checking the TXT record.=C2=A0

Your first sentenc= e ("mere removal of the TXT record...") does not follow from your= second sentence.=C2=A0

There's zero security = advantage in ignoring the TXT record and going straight to HTTPS, since HTT= PS also relies upon the (insecure) DNS resolution. As a result, it makes no= real sense to refresh the policy if the TXT does not say to do it. A sende= r who implements this will appear to be compliant with the draft--there'= ;s no real harm from doing this, aside from maybe excessive HTTPS requests-= -but there's no great reason to do this unless you think attackers can = only attack the TXT record and not the CNAME/A for the policy host.
=C2=A0
When a policy
is refreshed.=C2=A0 It will be stored for the advertised max_age
even if the TXT record is missing.

If a policy just vanishes without a secure signal that it is
being removed, that looks like an attack, unless you want to
use 404 as a secure policy removal signal (last I asked that
was not the case).


--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta