From nobody Sun Apr 2 14:35: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 DB461126B7F for ; Sun, 2 Apr 2017 14:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 AJO6sF08AggQ for ; Sun, 2 Apr 2017 14:35:55 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3161292F4 for ; Sun, 2 Apr 2017 14:35:54 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D68B720A8E; Sun, 2 Apr 2017 17:35:53 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Sun, 02 Apr 2017 17:35:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=Khtx7rvIWOw8IFZRYF yNk8vdrZLLg2tOngBkbiX/AMw=; b=Q3uxWMV6C2t3V185m2DHOHDWQVP8OapBrM cJZnaWtlk+KKxoeBJ08+SYg9Y3uBcgCv/by0w/qPjRC9vIv8xcSpcSANTh8srzvL V+BEmxBSZiTq24rF/hDP2xzf4bFLQ4629/mD0qaHR0YTHRZDp0Xl0/XKhqxV5iJN 9KfysE4pd4qzMB7+435GrGmGzzAwEsrOimGmyWW4UaXwRTwpuEBVDe/jVfFfkE7y pTlF4xasICg0ReUIVklGKjBnFMAZUmEG16U8eebEnhK46ZBmppRg7HVaquLgs6Ot dBK+yd3UaCKjNIJbkNIoz3quxCI3zlcv59/AcCqzP1+A/298ZE1w== X-ME-Sender: X-Sasl-enc: 4k4K2izNxfenc0lzvitVxf5a0VDS5dSyle3tTDXAAESU 1491168953 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 8FD1F2436B; Sun, 2 Apr 2017 17:35:53 -0400 (EDT) To: uta@ietf.org From: Keith Moore Message-ID: <5978a631-11d5-ff65-d1ba-d446a7af3b20@network-heretics.com> Date: Sun, 2 Apr 2017 17:35:52 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Uta] BCP portion of draft-ietf-email-deep / relaxing MSP requirements 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, 02 Apr 2017 21:35:57 -0000 After thinking about this a bit, it seems to me that if any portions of draft-ietf-email-deep should be BCP, it's those that describe requirements for MSPs. Those are indeed practice, not protocol. In the interest of expediency, I'd be fine with making those portions of MUA-STS non-normative and keeping them in the same document. I'd also be happy to separate that out into a separate BCP document, though it would take a bit longer. But if we do that, I'd really like to get consensus on the technical bits of MUA-STS first. Also, based on input from the Fastmail folks in Chicago, I think it makes sense to relax the MSP requirements somewhat. The goal of MUA-STS is to get all MUA-server links robustly encrypted. Different MSPs can quite reasonably choose different ways of doing this, based on whatever works for their operations and customers. If an MSP does this by some other means than the MUA-STS protocol extensions, the goal is still met. Keith From nobody Mon Apr 3 02:23: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 8B65B129613 for ; Mon, 3 Apr 2017 02:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 wGiA_7V-Zrye for ; Mon, 3 Apr 2017 02:23:33 -0700 (PDT) Received: from out.mail.ec.europa.eu (out.mail.ec.europa.eu [147.67.11.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDEFB1295E9 for ; Mon, 3 Apr 2017 02:23:30 -0700 (PDT) Received: from S-DC-EMP016-E.net1.cec.eu.int (158.167.3.15) by S-DC-EDG039-Z.rcnet.cec.eu.int (147.67.11.11) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 3 Apr 2017 11:23:37 +0200 Received: from S-DC-EMP005-J.net1.cec.eu.int (158.167.2.166) by S-DC-EMP016-E.net1.cec.eu.int (158.167.3.15) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 3 Apr 2017 11:23:27 +0200 Received: from S-DC-ESTE03-B.net1.cec.eu.int ([169.254.2.152]) by S-DC-EMP005-J.net1.cec.eu.int ([158.167.2.166]) with mapi id 14.03.0301.000; Mon, 3 Apr 2017 11:23:27 +0200 From: To: Thread-Topic: [Uta] General question on draft-ietf-uta-mta-sts-03 Thread-Index: AQHSqTcY8jps5Nhu0EGU3v8+sjq0sKGtMv4AgAG4C9k= Date: Mon, 3 Apr 2017 09:23:27 +0000 Message-ID: <2DB01F3A9898AE41BB3266315D9FDA2704902BE2@S-DC-ESTE03-B.net1.cec.eu.int> References: <2DB01F3A9898AE41BB3266315D9FDA2704902822@S-DC-ESTE03-B.net1.cec.eu.int>, In-Reply-To: Accept-Language: en-GB, fr-LU, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.167.189.38] Content-Type: multipart/alternative; boundary="_000_2DB01F3A9898AE41BB3266315D9FDA2704902BE2SDCESTE03Bnet1c_" MIME-Version: 1.0 Archived-At: Subject: Re: [Uta] General question on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 09:23:37 -0000 --_000_2DB01F3A9898AE41BB3266315D9FDA2704902BE2SDCESTE03Bnet1c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >The point is not to allow larger policy bodies but rather to leverage exis= ting authentication of HTTPS server certificates. We want some form of auth= entication for two reasons: > >1. We want it to be relatively hard to induce a DoS (as discussed in "Secu= rity Considerations"); requiring a policy to be authenticated helps mitigat= e that risk slightly. (Otherwise we're creating a variant of the inject-a-b= ad-MX-record DoS but with a really >long TTL!) > >2. More importantly, we want to allow recipient domains to update a policy= on demand, outside of expirations, so that they can signal a new MX is tru= sted (and similar). > >The authentication mechanism need not be HTTPs, and in fact when I started= drafting this originally I suggested we just stick the policy + signature = + cert chain in a DNS record--but that implies big DNS records, and that pe= ople figure out how to fetch >and validate them plus the whole cert chain, = and ultimately, using HTTPS just seemed a lot easier and well-understood th= an that. > >Hopefully that makes sense, but I will note that there are some slight rel= evancies for the parallel thread going on about SAN vs MX host matching--na= mely that the motivator for HTTPS (to leverage well-understood existing pro= tocols) is also an argument >for host matching, as Alberto has pointed out. > >Dan First of all, thank you for the quick answer. And I hope you don't mind sen= ding my thoughts to the list. Regarding the policy validation, would't the use of DNSSEC fix both the val= idation and update on demand problem? The TTL would allow you to control ho= w often the DNS record needs to be refreshed, and the max_age could tell th= e client MTAs how often to fetch the policy. I guess it is a question of wh= at is more complex? deploying DNSSEC or adding an HTTPS service. I hope I a= m not getting too much out of topic, asking about DNSSEC. In the SAN vs MX discussion, if I'm not wrong, the discussion is either to = use the mx parameter from the policy to filter MX hostnames, or to use it t= o filter against the SAN within the certificate received. Since the section= 4.2 (https://tools.ietf.org/html/draft-ietf-uta-mta-sts-03#section-4.2) de= fines that "... presented by the receiving MX MUST be valid for the MX host= name and chain to a root CA that is trusted by the sending MTA ...", the re= sult of any of the two options would be the same (we assume that an attacke= r cannot forge a certificate that would pass certificate validation). But, using the mx parameter to filter the MX records, would create somehow = an alternative way of discovering the list of MX for a domain, why would I = fetch the MX records from the DNS, if I know that the valid list is in the = mx parameter of the MTA-STS policy? Therefore I think that using the mx parameter to filter against the SAN lis= t would be a better option. Finally, about the use of JSON or pairs of values to describe the policy, I= think that if the use of JSON has to be an added complication for implemen= ting the MTA-STS, it is better to use pairs of values. So far the policy is= not that complex. The JSON format can be added in future versions when the= policy description become more complex. Gerard Draper Gil --_000_2DB01F3A9898AE41BB3266315D9FDA2704902BE2SDCESTE03Bnet1c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>The point is not to allow larger policy bodies but rat= her to leverage existing authentication of HTTPS server certificates. We wa= nt some form of authentication for two reasons:
>
>1. We want it to be relatively hard to induce a DoS (a= s discussed in "Security Considerations"); requiring a policy to = be authenticated helps mitigate that risk slightly. (Otherwise we're creating a variant of the inject-a-bad-MX-record DoS but = with a really >long TTL!)
>
>2. More importantly, we want to allow recipient domain= s to update a policy on demand, outside of expirations, so that they can si= gnal a new MX is trusted (and similar). 
>
>The authentication mechanism need not be HTTPs, and in= fact when I started drafting this originally I suggested we just stick the= policy + signature + cert chain in a DNS record--but that implies big DNS records, and that people figure out how t= o fetch >and validate them plus the whole cert chain, and ultimately, us= ing HTTPS just seemed a lot easier and well-understood than that. 
>
>Hopefully that makes sense, but I will note that there= are some slight relevancies for the parallel thread going on about SAN vs = MX host matching--namely that the motivator for HTTPS (to leverage well-understood existing protocols) is also an argu= ment >for host matching, as Alberto has pointed out. =
>
>Dan

First of all, thank you for the quick answer. And I hope y= ou don't mind sending my thoughts to the list.

Regarding the policy validation, would't the use of DNSSEC= fix both the validation and update on demand problem? The TTL would allow = you to control how often the DNS record needs to be refreshed, and the max_age could tell the client MTAs how ofte= n to fetch the policy. I guess it is a question of what is more complex? de= ploying DNSSEC or adding an HTTPS service. I hope I am not getting too much= out of topic, asking about DNSSEC. 

In the SAN vs MX discussion, if I'm not wrong, the discuss= ion is either to use the mx parameter from the policy to filter MX hostname= s, or to use it to filter against the SAN within the certificate received. Since the section 4.2 (https://tools.= ietf.org/html/draft-ietf-uta-mta-sts-03#section-4.2) defines that "...= presented by the receiving MX MUST be valid for the MX hostname and chain = to a root CA that is trusted by the sending MTA ...", the result of any of the two options would be the same (we = assume that an attacker cannot forge a certificate that would pass certific= ate validation).
But, using the mx parameter to filter the MX records, woul= d create somehow an alternative way of discovering the list of MX for a dom= ain, why would I fetch the MX records from the DNS, if I know that the valid list is in the mx parameter of the = MTA-STS policy?  
Therefore I think that using the mx parameter to filter ag= ainst the SAN list would be a better option.

Finally, about the use of JSON or pairs of values to descr= ibe the policy, I think that if the use of JSON has to be an added complica= tion for implementing the MTA-STS, it is better to use pairs of values. So far the policy is not that complex. T= he JSON format can be added in future versions when the policy description = become more complex. 

Gerard Draper Gil

--_000_2DB01F3A9898AE41BB3266315D9FDA2704902BE2SDCESTE03Bnet1c_-- From nobody Mon Apr 3 06:39: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 98CF912869B for ; Mon, 3 Apr 2017 06:39: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 pLEHJcGIuElh for ; Mon, 3 Apr 2017 06:39:00 -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 7E7611286CA for ; Mon, 3 Apr 2017 06:39:00 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (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 282EF7A330A for ; Mon, 3 Apr 2017 13:38:59 +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: <2DB01F3A9898AE41BB3266315D9FDA2704902BE2@S-DC-ESTE03-B.net1.cec.eu.int> Date: Mon, 3 Apr 2017 09:38:58 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: References: <2DB01F3A9898AE41BB3266315D9FDA2704902822@S-DC-ESTE03-B.net1.cec.eu.int> <2DB01F3A9898AE41BB3266315D9FDA2704902BE2@S-DC-ESTE03-B.net1.cec.eu.int> To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] General question on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 13:39:02 -0000 > On Apr 3, 2017, at 5:23 AM, = wrote: >=20 > Regarding the policy validation, would't the use of DNSSEC fix both = the > validation and update on demand problem? Quite so, but with DNSSEC you don't need STS, just use DANE. > In the SAN vs MX discussion, if I'm not wrong, the discussion is > either to use the mx parameter from the policy to filter MX > hostnames, or to use it to filter against the SAN within the > certificate received. Yes, possibly renamed if ceases to be an MX hostname filter. > Since the section 4.2 = (https://tools.ietf.org/html/draft-ietf-uta-mta-sts-03#section-4.2) = defines that "... presented by the receiving MX MUST be valid for the MX = hostname and chain to a root CA that is trusted by the sending MTA ...", = the result of any of the two options would be the same (we assume that = an attacker cannot forge a certificate that would pass certificate = validation). That text would also change if the policy admits other matching names. > But, using the mx parameter to filter the MX records, would create > somehow an alternative way of discovering the list of MX for a domain, No, it is an authenticated cached *filter* on the data obtained from DNS, and supports wildcards, which means that you don't actually get the MX hostnames from the policy. --=20 Viktor. From nobody Mon Apr 3 12:00: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 1BA941294E1 for ; Mon, 3 Apr 2017 12:00:57 -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 udtuxWx9bFWQ for ; Mon, 3 Apr 2017 12:00:53 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 26D78129505 for ; Mon, 3 Apr 2017 12:00:48 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id l7so81685109ioe.3 for ; Mon, 03 Apr 2017 12:00:48 -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=cy3JiQnXT4wXvZotWLjGHvFSRqVqrJrSV4j0iFu0cL8=; b=bnJfFHsMzXdAjk8l3/VVqY5We0lexU51Y8bhmXd5zLP/zb7LD6n0JYJEJVz+nwXhKO 8/Ae0ZvNcx3TowGXBIA42TgMMi90GlM/HuALEIAkxsu6dWPQNQitSoe5phpP4Q6iKgb4 72aZPTKGvk9SHzd7GFF0+DLk60K2GpzKmc1MKdJD1Cth2pu26DVsDAAUXa5WChzIqr1j vPdLnHeGPcfkJWyCtG9Uz11lo3GOlaEleR+KCQJvTuSBHG56omaavp3YW4El5DzG059j DAR1CMZFv9XmDHZVQp6pzyXzQOHv1L5uGxJlOujrXgbjIYXeje8ig8X6efebdXwvIeNi 1EYA== 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=cy3JiQnXT4wXvZotWLjGHvFSRqVqrJrSV4j0iFu0cL8=; b=S3Auird2nwh6Q6dX50u/+3iGYPDNm6rC6kLdyP8RetFr9ab3OloupAxU68r4Ptflg9 6PPDqosbSHE76KgIJvCg9dim4l2fZHOpKFhvwz6njD2EgPGTcOuBpVsOWeBB3TXKNYeZ HwGm+KE6aoQn0uwG4FWy4JnAmKKslFYD+cZlJcBUg8N+Huf++WhQAdkdtryarwwHa9v9 E41ZmiPwyFZKWSlAtvAVJshBdQVnW9ZCB47Dc2uKg87JjjKGT13oUM6jNDBM1ZLB+nCQ xCPmhRwn1GYIWLwR6NZwpER3W8nyQ/LM5Yj2YTT8QmVqMVDt/RQsNloC+tWKwUwb6ETQ Qevg== X-Gm-Message-State: AFeK/H2ofXKJ/NRtag73g6A0oUxi6GpzpX231XI+Xytc2kfp4UR0tX4TzariOLfRILYq37w8PsGHyg7xAhUrAZ0E X-Received: by 10.107.172.134 with SMTP id v128mr19947246ioe.49.1491246046795; Mon, 03 Apr 2017 12:00:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.39.215 with HTTP; Mon, 3 Apr 2017 12:00:45 -0700 (PDT) In-Reply-To: <20170330105556.GR11426@blitiri.com.ar> References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> <20170326205218.GN11426@blitiri.com.ar> <92500952-2A50-4508-8686-03CDBF72485D@dukhovni.org> <20170330105556.GR11426@blitiri.com.ar> From: Daniel Margolis Date: Mon, 3 Apr 2017 21:00:45 +0200 Message-ID: To: Alberto Bertogli Cc: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1148d5d4f1a594054c47c6b2" Archived-At: Subject: Re: [Uta] MTA-STS-03 review 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, 03 Apr 2017 19:00:57 -0000 --001a1148d5d4f1a594054c47c6b2 Content-Type: multipart/alternative; boundary=001a1148d5d4e5378b054c47c6e2 --001a1148d5d4e5378b054c47c6e2 Content-Type: text/plain; charset=UTF-8 Very fair points. I may be overstating the significance of being able to use a non-matching certificate (and I don't think it's awful to force implementors to have a cert that matches their hostname, either; this seems to me to not be a terribly painful prerequisite). But I think the cost of doing custom matching is low, too. You're right that there's some cognitive load in having it match in a non-standard way, but in fact in practice it will almost always be the same: because most people will use certs that have a SAN that matches the hostname, writing an 'mx' pattern to match the hostname will inherently match the cert, too! So for deployers this is not all that easy to get wrong, and for MTA developers they should just read the pseudocode in the appendix of the RFC, I think. What I said at the UTA meeting in person was that we seem to be haggling over things (this, the JSON-vs-key-value-pair thing) which, while not insignificant, are somewhat less critical than major architectural or fundamental questions, which makes me think we should just decide these--some of them perhaps somewhat arbitrarily--and move ahead. I don't have strong opinions on either of these points, but the consensus seemed to be mostly in favor of the SAN approach at UTA. On Thu, Mar 30, 2017 at 12:55 PM, Alberto Bertogli wrote: > On Mon, Mar 27, 2017 at 10:55:06PM +0200, Daniel Margolis wrote: > > To the matching point, I share the concern about people having to write > > their own cert matching code, but I think there are a few arguments for > it: > > > > 1. I believe if we restrict wildcards to the "full" leftmost label (i.e. > *. > > example.com is valid, but mail*.example.com or mail.*.example.com are > not) > > and we do the same in the certs (which RFC6125 seems to allow us to > > define), wildcard matching is a simple "x ends with y or y ends with x" > > comparison, so is in fact trivial to implement. > > Agreed, but it still carries some hidden complexity. > > For example, how does this interact with SNI? e.g what name would the > client pick to give to the server in the TLS negotiation? > > > > 2. It seems (and I suspect this was part of Viktor's motivation) to match > > nicely with https://tools.ietf.org/html/rfc7672#section-3.2.2, which if > I > > read it correctly leaves the door open to a certificate matching the > > nexthop domain rather than the MX hostname; by requiring MX hostname > > matches in STS we would break that behavior. > > Yes, my reading from that reference is that the nexthop domain can be > used to match as well. > > > > I think #2 is a pretty compelling point. > > It is definitely a point, but I'm not sure it's that compelling (sorry > Viktor!). > > There's, AFAIK, no very clear and well defined way to do certificate > matching for MTA-to-MTA TLS connections, and this RFC is a chance to fix > that. > > For better or worse, HTTPS is the most widely deployed TLS usage in the > world, and has gone through years of all kinds of production exposure. > The certificates are validated has been thoroughly reviewed and is well > documented and understood. > > Differring from that, and adding complexity to how SMTP does TLS > validation based on a particular section of RFC 7672 which, as far as I > know (and please correct me if I'm wrong) is not widely deployed and > hasn't got nearly as much production exposure, seems to me to be risky, > and is IMHO not worth it. > > Bringing SMTP certificate validation in line with how HTTPS does it > would not only simplify (some) implementations, but make deployments > easier, reduce the cognitive load and learning curve for folks running > their own servers, and benefit from all the existing analysis and also > the future improvements in the area (e.g. certificate revocation, > certificate transparency improvements, etc.). > > Very few existing deployments would be affected, as I don't think many > are relying on using [DANE+certificate for the next hop but not the MX > name]. > > > Note, in case it's not clear, that I'm not advocating for the removal of > the MX list from the policy, but to keep it as in the current draft > (i.e. use it as a filter mechanism, and then do TLS validation on the > resulting MX name). > > All this said, I don't want to drag my point along or interfere with the > normal flow of things. I much appreciate your thoughtful replies, and if > you don't find my arguments convicing, I understand :) > > Thanks a lot! > Alberto > > > PS: As an example of a related RFC that is AFAIK not widely deployed, > and which I think most popular deployments violate, is RFC 7817 "Updated > TLS Server Identity Check Procedure for Email-Related Protocols". > > It applies to POP3, IMAP and SMTP submission (excludes MTA-to-MTA), and > specifies that servers must have certificates not only for the host name > used to access them (e.g. imap.example.net) but also to the top level > domain used for email addresses (example.net in this case): > https://tools.ietf.org/html/rfc7817#section-6 > > Neither gmail.com, yahoo.com, live.com or outlook.com imap, pop3 or smtp > submission do this (but in fairness, hotmail.com does). > --001a1148d5d4e5378b054c47c6e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Very fair points. I may be overstating the significance of= being able to use a non-matching certificate (and I don't think it'= ;s awful to force implementors to have a cert that matches their hostname, = either; this seems to me to not be a terribly painful prerequisite).=C2=A0<= div>
But I think the cost of doing custom matching is low, to= o. You're right that there's some cognitive load in having it match= in a non-standard way, but in fact in practice it will almost always be th= e same: because most people will use certs that have a SAN that matches the= hostname, writing an 'mx' pattern to match the hostname will inher= ently match the cert, too! So for deployers this is not all that easy to ge= t wrong, and for MTA developers they should just read the pseudocode in the= appendix of the RFC, I think.=C2=A0

What I said a= t the UTA meeting in person was that we seem to be haggling over things (th= is, the JSON-vs-key-value-pair thing) which, while not insignificant, are s= omewhat less critical than major architectural or fundamental questions, wh= ich makes me think we should just decide these--some of them perhaps somewh= at arbitrarily--and move ahead.=C2=A0

I don't = have strong opinions on either of these points, but the consensus seemed to= be mostly in favor of the SAN approach at UTA.=C2=A0

<= div>

On Thu, Mar 30, 2017 at 12:55 PM, Alberto Bertogli <= ;albertito@bl= itiri.com.ar> wrote:
On Mon, Mar 27, 2017 at 10:55:06PM +0200, Daniel Margolis wrote:=
> To the matching point, I share the concern about people having to writ= e
> their own cert matching code, but I think there are a few arguments fo= r it:
>
> 1. I believe if we restrict wildcards to the "full" leftmost= label (i.e. *.
> ex= ample.com is valid, but mail*.example.com or mail.*.example.com are not)
> and we do the same in the certs (which RFC6125 seems to allow us to > define), wildcard matching is a simple "x ends with y or y ends w= ith x"
> comparison, so is in fact trivial to implement.

Agreed, but it still carries some hidden complexity.

For example, how does this interact with SNI? e.g what name would the
client pick to give to the server in the TLS negotiation?


> 2. It seems (and I suspect this was part of Viktor's motivation) t= o match
> nicely with https://tools.ietf.org/html/r= fc7672#section-3.2.2, which if I
> read it correctly leaves the door open to a certificate matching the > nexthop domain rather than the MX hostname; by requiring MX hostname > matches in STS we would break that behavior.

Yes, my reading from that reference is that the nexthop domain can b= e
used to match as well.


> I think #2 is a pretty compelling point.

It is definitely a point, but I'm not sure it's that compell= ing (sorry
Viktor!).

There's, AFAIK, no very clear and well defined way to do certificate matching for MTA-to-MTA TLS connections, and this RFC is a chance to fix that.

For better or worse, HTTPS is the most widely deployed TLS usage in the
world, and has gone through years of all kinds of production exposure.
The certificates are validated has been thoroughly reviewed and is well
documented and understood.

Differring from that, and adding complexity to how SMTP does TLS
validation based on a particular section of RFC 7672 which, as far as I
know (and please correct me if I'm wrong) is not widely deployed and hasn't got nearly as much production exposure, seems to me to be risky,=
and is IMHO not worth it.

Bringing SMTP certificate validation in line with how HTTPS does it
would not only simplify (some) implementations, but make deployments
easier, reduce the cognitive load and learning curve for folks running
their own servers, and benefit from all the existing analysis and also
the future improvements in the area (e.g. certificate revocation,
certificate transparency improvements, etc.).

Very few existing deployments would be affected, as I don't think many<= br> are relying on using [DANE+certificate for the next hop but not the MX
name].


Note, in case it's not clear, that I'm not advocating for the remov= al of
the MX list from the policy, but to keep it as in the current draft
(i.e. use it as a filter mechanism, and then do TLS validation on the
resulting MX name).

All this said, I don't want to drag my point along or interfere with th= e
normal flow of things. I much appreciate your thoughtful replies, and if you don't find my arguments convicing, I understand :)

Thanks a lot!
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alberto


PS: As an example of a related RFC that is AFAIK not widely deployed,
and which I think most popular deployments violate, is RFC 7817 "Updat= ed
TLS Server Identity Check Procedure for Email-Related Protocols".

It applies to POP3, IMAP and SMTP submission (excludes MTA-to-MTA), and
specifies that servers must have certificates not only for the host name used to access them (e.g. imap.example.net) but also to the top level
domain used for email addresses (example.net in this case):
https://tools.ietf.org/html/rfc7817#section-6<= br>
Neither g= mail.com, yahoo.com, live.com or outlook.com imap, pop3 or smtp
submission do this (but in fairness, hotmail.com does).

--001a1148d5d4e5378b054c47c6e2-- --001a1148d5d4f1a594054c47c6b2 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCfzXQrm/u5x+4k 80jx5HSuouxmNzNAcT4VagB2VDn/UzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA0MDMxOTAwNDdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAMguIU74jCfCMVAzJmwL/9G0jBTvxrQVk fWFlsAHi/t5PZ6kzxqZOs3Qx7f8vFhRyyQJOQrYYSlL5dMPooLTyBHpAvJONFlsGH3Y9i6j+H6yW H15NNZcMnHNs0hCGw/hzyZfAj14EkGhTiQ9HNarvhOHkj5QMV2plHwPj9xKfjU62TSpg/ibxTnVg jA5cn29jXVEsr9awkZ0fvQIFE3+nb7gjN9y1ywdGAM4zuVNuZKznZaH4A5xuSXo8RmLftvMXxBi4 aCgKZNkcQl8GLyWyscZu1QjQVNHJq8Dyg0gFh8alATnLqHhw60bP6mPfxdsjQOtNDUX51DCUUbyy KHz5gg== --001a1148d5d4f1a594054c47c6b2-- From nobody Mon Apr 3 12:35: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 2F7121294C7 for ; Mon, 3 Apr 2017 12:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MARKETING_PARTNERS=0.001] autolearn=no 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 EODHvC0jW0AJ for ; Mon, 3 Apr 2017 12:35:32 -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 4DCDA127419 for ; Mon, 3 Apr 2017 12:35:32 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 19DD27A330D; Mon, 3 Apr 2017 19:35:31 +0000 (UTC) Date: Mon, 3 Apr 2017 19:35:31 +0000 From: Viktor Dukhovni To: uta@ietf.org Message-ID: <20170403193531.GO25754@mournblade.imrryr.org> Reply-To: uta@ietf.org References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> <20170326205218.GN11426@blitiri.com.ar> <92500952-2A50-4508-8686-03CDBF72485D@dukhovni.org> <20170330105556.GR11426@blitiri.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170330105556.GR11426@blitiri.com.ar> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Uta] MTA-STS-03 review 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, 03 Apr 2017 19:35:34 -0000 On Thu, Mar 30, 2017 at 11:55:56AM +0100, Alberto Bertogli wrote: > > 2. It seems (and I suspect this was part of Viktor's motivation) to match > > nicely with https://tools.ietf.org/html/rfc7672#section-3.2.2, which if I > > read it correctly leaves the door open to a certificate matching the > > nexthop domain rather than the MX hostname; by requiring MX hostname > > matches in STS we would break that behavior. > > Yes, my reading from that reference is that the nexthop domain can be > used to match as well. > > > I think #2 is a pretty compelling point. > > It is definitely a point, but I'm not sure it's that compelling (sorry > Viktor!). > > There's, AFAIK, no very clear and well defined way to do certificate > matching for MTA-to-MTA TLS connections, and this RFC is a chance to fix > that. Well, the prior practice, since at least 2007 in Exchange, and 2005 in Postfix, is to match the destination domain, rather than the MX hostname (which obtained from DNS MX lookup was not secure). This is used for bilaterally coordinated "secure-channel" TLS "tunnels" between partner sites. > Differring from that, and adding complexity to how SMTP does TLS > validation based on a particular section of RFC 7672 which, as far as I > know (and please correct me if I'm wrong) is not widely deployed and > hasn't got nearly as much production exposure, seems to me to be risky, > and is IMHO not worth it. Well, RFC7672 did not create this feature from thin air. The reason it appears in RFC7672 is to support existing practice. It is true that non-opportunistic TLS was not especially common in SMTP (due to lack of scalability), but it was used. A site that has the destination domain in the certificate can support both DANE and secure-channel mandatory TLS. > Bringing SMTP certificate validation in line with how HTTPS Analogies between HTTPS and TLS for SMTP are often misleading if not outright damaging. So having differences is somewhat of a feature. > Note, in case it's not clear, that I'm not advocating for the removal of > the MX list from the policy, but to keep it as in the current draft > (i.e. use it as a filter mechanism, and then do TLS validation on the > resulting MX name). > > All this said, I don't want to drag my point along or interfere with the > normal flow of things. I much appreciate your thoughtful replies, and if > you don't find my arguments convicing, I understand :) That, unfortunately, means modifying the complex MX host selection code in the MTA, which up till now has been quite separate from TLS authentication. I would really like to avoid touching the MX processing loop, and implement TLS policy strictly in the TLS handshake layer. -- Viktor. From nobody Mon Apr 3 13:53: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 45604128C83 for ; Mon, 3 Apr 2017 13:53:06 -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, MARKETING_PARTNERS=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 228bCNtZItos for ; Mon, 3 Apr 2017 13:53:03 -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 5AAAA126FB3 for ; Mon, 3 Apr 2017 13:53:03 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id a140so18160472ita.0 for ; Mon, 03 Apr 2017 13:53: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; bh=rvI0iLP7347w3d6yllpEAgUMi4XDsHR1Mg0t9V5yIjM=; b=DzPptlm5bWM6sLFHnSMPoYXmNYeWy5LzZ/yVIDEUE4w6xOGlw5A+5Khoe4LaLueLuD KdHUmbEg81DmDXAak70JDcLg8BO50jdcZ1x+YhSi07kj+Kg9J7C6TiNWjSS7hUx/m1Lo MpDfz1t2LzDII4/oPuDwrn+JW6cPfsRAIaaH9GOKOYuvnVV7TvEjmx931hmwN3OYv0xD IuIkIQXREw7sty9OKjVdigCvfygPeZ+BdnKcD3Hy1tqB8dPjb3JN8EJWo1DkUXlk3p8B sRNIP0AVPDJ0tvROt0vQglJ4rB6qKv8zf3kzQPMsbfNP3LnUo6amZxXP5Lql/atB7q+U W2ng== 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=rvI0iLP7347w3d6yllpEAgUMi4XDsHR1Mg0t9V5yIjM=; b=AksBh74FeYOcEmz/Hcsknyya9ViZNdN4ORX2/Gzpc4PGc+jNMbXBEh3VrXaQLIcpNS NJJwVmrdF/mMZQtt/vKiUxz5VBhBrUiTsjKXEFVEffACS802NWUBdqz07o6fUDrlAOVY 9yz3JfAo6yW8dXrIEmavHEz37nwdijEB9vSOL0mswH2lJnVnJqlni7GQNn1gbuMdjA/B qLS/Lkt+HEzPJl0u4/aiO8d8XgtxUU3fzacKHXsRcmav80EqaEmLjHfvIbg+8Il8XMtf 3BsPOzNMZzyBYE9sFmjiLW/R+yh56vJb8Z5VzK6UtPtAcmWeNkMsY5DulCzp3udvT+wo 4EwQ== X-Gm-Message-State: AFeK/H2NLty4oEwSiIYykcS8PCSPdghTsShi+HC4LmgtSU1lAPf089Ot xTbSLyi0+qh5OQDlPzDT/w3cezkODTVWbdBDWA== X-Received: by 10.36.115.146 with SMTP id y140mr4216051itb.21.1491252782025; Mon, 03 Apr 2017 13:53:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.39.215 with HTTP; Mon, 3 Apr 2017 13:53:00 -0700 (PDT) In-Reply-To: <20170403193531.GO25754@mournblade.imrryr.org> References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> <20170326205218.GN11426@blitiri.com.ar> <92500952-2A50-4508-8686-03CDBF72485D@dukhovni.org> <20170330105556.GR11426@blitiri.com.ar> <20170403193531.GO25754@mournblade.imrryr.org> From: Daniel Margolis Date: Mon, 3 Apr 2017 22:53:00 +0200 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11443bc2627958054c495851" Archived-At: Subject: Re: [Uta] MTA-STS-03 review 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, 03 Apr 2017 20:53:06 -0000 --001a11443bc2627958054c495851 Content-Type: multipart/alternative; boundary=001a11443bc2582912054c4958a2 --001a11443bc2582912054c4958a2 Content-Type: text/plain; charset=UTF-8 > > That, unfortunately, means modifying the complex MX host selection > code in the MTA, which up till now has been quite separate from > TLS authentication. I would really like to avoid touching the MX > processing loop, and implement TLS policy strictly in the TLS > handshake layer. To rathole very slightly on this--and not looking at the Postfix code specifically, say--I don't really understand this point. In hypothetical pseudocode, your MX is going to be doing something like this: for candidate in mx_list: if try_to_send(candidate): success = True break And in the cert validation (or DANE validation or anything else) step, we modify "try_to_send()" to close the connection and return False if the cert validation fails, no? So your point seems to be that the MX selection logic must be modified to support the MX matching approach: for candidate in filter_mx_list(mx_list): # etc Right? But why would you not simply modify "try_to_send()" to check the hostname against the policy (same as it would check the cert SANs or CN against the policy)? I'm not trying to get too into the pseudocode since this is a vast oversimplification, but I'm afraid I don't understand the distinction you are drawing between modifying candidate selection and modifying cert validation. Can you explain a little more? Thanks. On Mon, Apr 3, 2017 at 9:35 PM, Viktor Dukhovni wrote: > On Thu, Mar 30, 2017 at 11:55:56AM +0100, Alberto Bertogli wrote: > > > > 2. It seems (and I suspect this was part of Viktor's motivation) to > match > > > nicely with https://tools.ietf.org/html/rfc7672#section-3.2.2, which > if I > > > read it correctly leaves the door open to a certificate matching the > > > nexthop domain rather than the MX hostname; by requiring MX hostname > > > matches in STS we would break that behavior. > > > > Yes, my reading from that reference is that the nexthop domain can be > > used to match as well. > > > > > I think #2 is a pretty compelling point. > > > > It is definitely a point, but I'm not sure it's that compelling (sorry > > Viktor!). > > > > There's, AFAIK, no very clear and well defined way to do certificate > > matching for MTA-to-MTA TLS connections, and this RFC is a chance to fix > > that. > > Well, the prior practice, since at least 2007 in Exchange, and 2005 > in Postfix, is to match the destination domain, rather than the MX > hostname (which obtained from DNS MX lookup was not secure). > > This is used for bilaterally coordinated "secure-channel" TLS > "tunnels" between partner sites. > > > Differring from that, and adding complexity to how SMTP does TLS > > validation based on a particular section of RFC 7672 which, as far as I > > know (and please correct me if I'm wrong) is not widely deployed and > > hasn't got nearly as much production exposure, seems to me to be risky, > > and is IMHO not worth it. > > Well, RFC7672 did not create this feature from thin air. The reason > it appears in RFC7672 is to support existing practice. It is true > that non-opportunistic TLS was not especially common in SMTP (due > to lack of scalability), but it was used. > > A site that has the destination domain in the certificate can > support both DANE and secure-channel mandatory TLS. > > > > Bringing SMTP certificate validation in line with how HTTPS > > Analogies between HTTPS and TLS for SMTP are often misleading if > not outright damaging. So having differences is somewhat of a > feature. > > > Note, in case it's not clear, that I'm not advocating for the removal of > > the MX list from the policy, but to keep it as in the current draft > > (i.e. use it as a filter mechanism, and then do TLS validation on the > > resulting MX name). > > > > All this said, I don't want to drag my point along or interfere with the > > normal flow of things. I much appreciate your thoughtful replies, and if > > you don't find my arguments convicing, I understand :) > > That, unfortunately, means modifying the complex MX host selection > code in the MTA, which up till now has been quite separate from > TLS authentication. I would really like to avoid touching the MX > processing loop, and implement TLS policy strictly in the TLS > handshake layer. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a11443bc2582912054c4958a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That, unfortunately, means modifying the complex M= X host selection
code in the MTA= , which up till now has been quite separate from
TLS authentication.=C2=A0 I would really like to avoid tou= ching the MX
processing loop, an= d implement TLS policy strictly in the TLS
handshake layer.

To rathole ve= ry slightly on this--and not looking at the Postfix code specifically, say-= -I don't really understand this point.=C2=A0

In hypo= thetical pseudocode, your MX is going to be doing something like this:

for candidate in mx_list:
=C2=A0 if try_to_s= end(candidate):
=C2=A0 =C2=A0 success =3D True
=C2=A0 = =C2=A0 break

And in the cert validation (or DANE v= alidation or anything else) step, we modify "try_to_send()" to cl= ose the connection and return False if the cert validation fails, no?
=

So your point seems to be that the MX selection logic m= ust be modified to support the MX matching approach:

for candidate in filter_mx_list(mx_list):
=C2=A0 =C2=A0# etc

Right? But why would you not simply modify "tr= y_to_send()" to check the hostname against the policy (same as it woul= d check the cert SANs or CN against the policy)?=C2=A0

=
I'm not trying to get too into the pseudocode since this is a vast= oversimplification, but I'm afraid I don't understand the distinct= ion you are drawing between modifying candidate selection and modifying cer= t validation. Can you explain a little more?=C2=A0

Thanks.=C2=A0
=C2=A0=C2=A0

On Mon, Apr 3, 2017 at 9:35 PM, Viktor Dukh= ovni <ietf-dane@dukhovni.org> wrote:
On Thu, Mar 30, 2017 at 11:55:56AM +0100, = Alberto Bertogli wrote:

> > 2. It seems (and I suspect this was part of Viktor's motivati= on) to match
> > nicely with https://tools.ietf.org/html/<= wbr>rfc7672#section-3.2.2, which if I
> > read it correctly leaves the door open to a certificate matching = the
> > nexthop domain rather than the MX hostname; by requiring MX hostn= ame
> > matches in STS we would break that behavior.
>
> Yes, my reading from that reference is that the nexthop domain can be<= br> > used to match as well.
>
> > I think #2 is a pretty compelling point.
>
> It is definitely a point, but I'm not sure it's that compellin= g (sorry
> Viktor!).
>
> There's, AFAIK, no very clear and well defined way to do certifica= te
> matching for MTA-to-MTA TLS connections, and this RFC is a chance to f= ix
> that.

Well, the prior practice, since at least 2007 in Exchange, and 2005<= br> in Postfix, is to match the destination domain, rather than the MX
hostname (which obtained from DNS MX lookup was not secure).

This is used for bilaterally coordinated "secure-channel" TLS
"tunnels" between partner sites.

> Differring from that, and adding complexity to how SMTP does TLS
> validation based on a particular section of RFC 7672 which, as far as = I
> know (and please correct me if I'm wrong) is not widely deployed a= nd
> hasn't got nearly as much production exposure, seems to me to be r= isky,
> and is IMHO not worth it.

Well, RFC7672 did not create this feature from thin air.=C2=A0 The r= eason
it appears in RFC7672 is to support existing practice.=C2=A0 =C2=A0It is tr= ue
that non-opportunistic TLS was not especially common in SMTP (due
to lack of scalability), but it was used.

A site that has the destination domain in the certificate can
support both DANE and secure-channel mandatory TLS.


> Bringing SMTP certificate validation in line with how HTTPS

Analogies between HTTPS and TLS for SMTP are often misleading if
not outright damaging.=C2=A0 So having differences is somewhat of a
feature.

> Note, in case it's not clear, that I'm not advocating for the = removal of
> the MX list from the policy, but to keep it as in the current draft > (i.e. use it as a filter mechanism, and then do TLS validation on the<= br> > resulting MX name).
>
> All this said, I don't want to drag my point along or interfere wi= th the
> normal flow of things. I much appreciate your thoughtful replies, and = if
> you don't find my arguments convicing, I understand :)

That, unfortunately, means modifying the complex MX host selection code in the MTA, which up till now has been quite separate from
TLS authentication.=C2=A0 I would really like to avoid touching the MX
processing loop, and implement TLS policy strictly in the TLS
handshake layer.

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

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

--001a11443bc2582912054c4958a2-- --001a11443bc2627958054c495851 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAct1RNqVga2TPQ nRIjw2gAv0XrADWo3fLQyIshhBfEvzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA0MDMyMDUzMDJaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEADELWO/dQ8ldIhk57cVOJWkKdcsPYU0/S Dj1R/Ix5YqpMFdsl38Ji2/ssoNK86Qolu9W0m8PqnAjed/fgvzUp/m4PWx3HVFdUnVMJsCOR9brZ 4lxPQDnVmWZYvQht/bnelOQ1leJyW0VDQS+TFzykMMQO9IAMnnR/eHheDuEydEj55lJTtHDYpMfQ CvI5KyuixWIMAgQMYuB10qDR7JnPWPH85EkgJealDb6/SQ6m2pRm2KR6klMCKDsnAOTIF2W4zNcd YJ+gC2QwK1TjY4ZgbAqzg+pXFEhF3MUf4Dg7uhVO7clT6W72heyjcAZ8DP+j3GRYBa9Pz7+b8LL8 4fHmOA== --001a11443bc2627958054c495851-- From nobody Mon Apr 3 14:05:21 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 5073D128CD5 for ; Mon, 3 Apr 2017 14:05:19 -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 dKPuj-hKH5bK for ; Mon, 3 Apr 2017 14:05:17 -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 5A1B51243F3 for ; Mon, 3 Apr 2017 14:05:17 -0700 (PDT) Received: from [172.31.30.48] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 87C747A330A for ; Mon, 3 Apr 2017 21:05:16 +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: Mon, 3 Apr 2017 17:05:15 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> <20170326205218.GN11426@blitiri.com.ar> <92500952-2A50-4508-8686-03CDBF72485D@dukhovni.org> <20170330105556.GR11426@blitiri.com.ar> <20170403193531.GO25754@mournblade.imrryr.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] MTA-STS-03 review 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, 03 Apr 2017 21:05:19 -0000 > On Apr 3, 2017, at 4:53 PM, Daniel Margolis = wrote: >=20 > In hypothetical pseudocode, your MX is going to be doing something = like this: >=20 > for candidate in mx_list: > if try_to_send(candidate): > success =3D True > break Yes, but with an initial step to prune the MX list when the sending host is a member of that list... And of course dealing with multi-recipient messages, ... > And in the cert validation (or DANE validation or anything else) step, > we modify "try_to_send()" to close the connection and return False if > the cert validation fails, no? When authentication is required and fails, all recipients tempfail, and the next candidate MX is tried (ignoring details of what "next host" = means when MX hosts have multiple IP addresses). > So your point seems to be that the MX selection logic must be modified > to support the MX matching approach: The draft suggests filtering the MX host list first, and then looping over the remaining hosts. > for candidate in filter_mx_list(mx_list): > # etc As above. > Right? But why would you not simply modify "try_to_send()" > to check the hostname against the policy (same as it would > check the cert SANs or CN against the policy)? One could defer the hostname validation, but if it is really just an MX hostname filter, and not a certificate filter, then there would be a futile connection to the host, and a TLS handshake, before the TLS layer discovers that the MX hostname is a priori forbidden by the STS policy. > I'm afraid I don't understand the distinction you are drawing > between modifying candidate selection and modifying cert > validation. Can you explain a little more? If the policy restricts the acceptable content of the MX RRset in DNS, then one ought to avoid connections to "forged" MX hosts, which requires changes to the MX selection loop. If the policy restricts the acceptable names in the MX host certificate, then MX selection remains unaffected, and one tempfails connections where the peer certificate fails to validate (for any of a set of reasons, including name check failure). --=20 Viktor. From nobody Tue Apr 4 00:24: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 0DA52127071 for ; Tue, 4 Apr 2017 00:24:11 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ozHr8pl38f2l for ; Tue, 4 Apr 2017 00:24:08 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 1E44212420B for ; Tue, 4 Apr 2017 00:24:08 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id l7so89936065ioe.3 for ; Tue, 04 Apr 2017 00:24:08 -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=2d8qW5okcw7Kg+6gmAIAWt6gzgqzuwZd1D75FHsgGdU=; b=bn073oJvkwG/nujSGNXNggWJ0eydVqOHG1V/e+uEmwnm+KZjm+7T7AODrB67MkdGyg nnBUskSBlESWpKHaiYs0/TNAVQwRbcv6auq3KWV2LMR0Tz+ulOn2cwyp/Wu2Mk5Vkg2O 6Jlyw8N6oXmk5n7/IWhbqxRdg+xl00+Pwyu5H8SH/1m3T7x8/l53QxBAb0xJljLaQTvz 66TqVkyqOeWwVuohKfsPHvAy1Pax2QBGmKc1aWZ7UaYM4YDRrkAmLZjF/8xxa+O5y0jw 4C/eFMrHFR0CrCmCu7TZ6AyIQyjhN2MQKojiBJedQHnHF1lKp+Mb6+KKvo7yWW7pxLmJ GLmA== 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=2d8qW5okcw7Kg+6gmAIAWt6gzgqzuwZd1D75FHsgGdU=; b=FbfjWyA4Q80I6WmX8gvaOqIAgv5iSrt+kYm2PCvEK9t70+Km4/LgSey9FtZzNnT2gg U1O+FWD389XAk2t20Fnz4+dz2KN2apHqutRjru9vB0hLV4y3hH0s+aYroyMp3XfHLJNv g93fWvZouv5Inh/lQE9bHWNwJojaCnOPtJD2luJt96ZNTML16jy/PstvYlqIQcLGuqpg izXCnL2+XVW6QwBN3D48UmONJa5nMz7JdAGljigwOO6uc60l1bn9UdK1M6cG4CTv/3J/ HzEAHcAasfzvNwkZxHIntj12CuS6gKms9P0GuD+AhxG6070amksQuCd8asnGFPhvjcD7 LekQ== X-Gm-Message-State: AFeK/H36LtG0ZI4p6mKZJ+w1bWOMohdh2JkmOmvlGIQWepod+6mLo2L6wyrE9DSKWUh4KkHoYMZjQyjtfi0Bt1ht X-Received: by 10.107.6.211 with SMTP id f80mr19761550ioi.96.1491290646634; Tue, 04 Apr 2017 00:24:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.39.215 with HTTP; Tue, 4 Apr 2017 00:24:05 -0700 (PDT) In-Reply-To: References: <4C0807DA-4852-4DAC-80ED-8A25371CFFAA@dukhovni.org> <20170326205218.GN11426@blitiri.com.ar> <92500952-2A50-4508-8686-03CDBF72485D@dukhovni.org> <20170330105556.GR11426@blitiri.com.ar> <20170403193531.GO25754@mournblade.imrryr.org> From: Daniel Margolis Date: Tue, 4 Apr 2017 09:24:05 +0200 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113fb930491d92054c522988" Archived-At: Subject: Re: [Uta] MTA-STS-03 review 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, 04 Apr 2017 07:24:11 -0000 --001a113fb930491d92054c522988 Content-Type: multipart/alternative; boundary=001a113fb930406d2f054c5229f9 --001a113fb930406d2f054c5229f9 Content-Type: text/plain; charset=UTF-8 > > If the policy restricts the acceptable content of the MX RRset > in DNS, then one ought to avoid connections to "forged" MX hosts, > which requires changes to the MX selection loop. Pseudocode in the draft notwithstanding, a compliant implementation *may* connect to the "wrong" MX hosts if it wants to. That was my only point. The draft suggests pre-filtering for efficiency's sake only--when MX host validation is used, hosts can be determined to be invalid before the connection, so we can avoid the slightly wasteful step of connecting. But of course they can be invalid only after connection, too (if they have a valid hostname but an invalid cert), so obviously we cannot consider connecting to the "wrong" host to be some kind of security issue (and it is not). Like I said, this is mostly a digression, since we've already adopted the SAN-validation approach in the Github (and it should be in the next draft, unless I hear major objections, per the seeming consensus at the UTA meeting). But I believe this pro/con is largely a red herring. On Mon, Apr 3, 2017 at 11:05 PM, Viktor Dukhovni wrote: > > > On Apr 3, 2017, at 4:53 PM, Daniel Margolis > wrote: > > > > In hypothetical pseudocode, your MX is going to be doing something like > this: > > > > for candidate in mx_list: > > if try_to_send(candidate): > > success = True > > break > > Yes, but with an initial step to prune the MX list when the sending host > is a member of that list... And of course dealing with multi-recipient > messages, ... > > > And in the cert validation (or DANE validation or anything else) step, > > we modify "try_to_send()" to close the connection and return False if > > the cert validation fails, no? > > When authentication is required and fails, all recipients tempfail, and > the next candidate MX is tried (ignoring details of what "next host" means > when MX hosts have multiple IP addresses). > > > So your point seems to be that the MX selection logic must be modified > > to support the MX matching approach: > > The draft suggests filtering the MX host list first, and then looping > over the remaining hosts. > > > for candidate in filter_mx_list(mx_list): > > # etc > > As above. > > > Right? But why would you not simply modify "try_to_send()" > > to check the hostname against the policy (same as it would > > check the cert SANs or CN against the policy)? > > One could defer the hostname validation, but if it is really > just an MX hostname filter, and not a certificate filter, > then there would be a futile connection to the host, and > a TLS handshake, before the TLS layer discovers that the > MX hostname is a priori forbidden by the STS policy. > > > I'm afraid I don't understand the distinction you are drawing > > between modifying candidate selection and modifying cert > > validation. Can you explain a little more? > > If the policy restricts the acceptable content of the MX RRset > in DNS, then one ought to avoid connections to "forged" MX hosts, > which requires changes to the MX selection loop. > > If the policy restricts the acceptable names in the MX host > certificate, then MX selection remains unaffected, and one > tempfails connections where the peer certificate fails to > validate (for any of a set of reasons, including name check > failure). > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a113fb930406d2f054c5229f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If the policy restricts the acceptable content of = the MX RRset
in DNS, then one ou= ght to avoid connections to "forged" MX hosts,
which requires changes to the MX selection loop.

Pseudocode in the draft notwithstandi= ng, a compliant implementation may=C2=A0connect to the "wrong&q= uot; MX hosts if it wants to. That was my only point.=C2=A0

<= /div>
The draft suggests pre-filtering for efficiency's sake only--= when MX host validation is used, hosts can be determined to be invalid befo= re the connection, so we can avoid the slightly wasteful step of connecting= . But of course they can be invalid only after connection, too (if they hav= e a valid hostname but an invalid cert), so obviously we cannot consider co= nnecting to the "wrong" host to be some kind of security issue (a= nd it is not).=C2=A0

Like I said, this is mostly a= digression, since we've already adopted the SAN-validation approach in= the Github (and it should be in the next draft, unless I hear major object= ions, per the seeming consensus at the UTA meeting). But I believe this pro= /con is largely a red herring.=C2=A0
=
On Mon, Apr 3, 2017 at 11:05 PM, Viktor Dukh= ovni <ietf-dane@dukhovni.org> wrote:

> On Apr 3, 2017, at 4:53 PM, Daniel Margolis <dmargolis@google.com> wrote:
>
> In hypothetical pseudocode, your MX is going to be doing something lik= e this:
>
> for candidate in mx_list:
>=C2=A0 =C2=A0if try_to_send(candidate):
>=C2=A0 =C2=A0 =C2=A0success =3D True
>=C2=A0 =C2=A0 =C2=A0break

Yes, but with an initial step to prune the MX list when the sending = host
is a member of that list...=C2=A0 And of course dealing with multi-recipien= t
messages, ...

> And in the cert validation (or DANE validation or anything else) step,=
> we modify "try_to_send()" to close the connection and return= False if
> the cert validation fails, no?

When authentication is required and fails, all recipients tempfail, = and
the next candidate MX is tried (ignoring details of what "next host&qu= ot; means
when MX hosts have multiple IP addresses).

> So your point seems to be that the MX selection logic must be modified=
> to support the MX matching approach:

The draft suggests filtering the MX host list first, and then loopin= g
over the remaining hosts.

> for candidate in filter_mx_list(mx_list):
>=C2=A0 =C2=A0 # etc

As above.

> Right? But why would you not simply modify "try_to_send()" > to check the hostname against the policy (same as it would
> check the cert SANs or CN against the policy)?

One could defer the hostname validation, but if it is really
just an MX hostname filter, and not a certificate filter,
then there would be a futile connection to the host, and
a TLS handshake, before the TLS layer discovers that the
MX hostname is a priori forbidden by the STS policy.

> I'm afraid I don't understand the distinction you are drawing<= br> > between modifying candidate selection and modifying cert
> validation. Can you explain a little more?

If the policy restricts the acceptable content of the MX RRset
in DNS, then one ought to avoid connections to "forged" MX hosts,=
which requires changes to the MX selection loop.

If the policy restricts the acceptable names in the MX host
certificate, then MX selection remains unaffected, and one
tempfails connections where the peer certificate fails to
validate (for any of a set of reasons, including name check
failure).

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

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

--001a113fb930406d2f054c5229f9-- --001a113fb930491d92054c522988 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBC3kV1MIfYRz0Y 2yUbnG+XcO7fI19Rv4Cm1zwveMo9UTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA0MDQwNzI0MDdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEANZfB2dmaOihreeAkwM3n6qSgxV+jW+Rj e98NZ7R86mkeluHoXdBNqpbwcsmjR0ei05xA2E9CnBvqipMnyU83VgtkK1l01s0S1wI0Xvr/DApq xLK19LL9vmJi3FLOA+pVl5udUEQRHJALH4l6TcW4Id5ItEpzKTFvIH2ov28YcUIkZaafjdzI/2xO 1QNvEmt3OOAz7fR732WaDLOfWfFHXrsSKo00E1DvpTt1p9Ddlr1b5WrzJMspIdC2ajj7UbswVfFC 6Zun/36vBz2V8zV/FTSm6R4kr4Y9PYLniu5uE1wlkYZA6V0HelINzu9gN6Ji50/EpHjrSCansOC9 oEo0qw== --001a113fb930491d92054c522988-- From nobody Tue Apr 4 05:13: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 AB1E3129556 for ; Tue, 4 Apr 2017 05:13:02 -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, FREEMAIL_FROM=0.001, 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=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 TwgrApxkaJ6n for ; Tue, 4 Apr 2017 05:13:01 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 12E5B12871F for ; Tue, 4 Apr 2017 05:13:01 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id d2so27002404oig.1 for ; Tue, 04 Apr 2017 05:13:01 -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=0+VmB982cKF+Yg4IztQUGSSyWwS1vQJ+ehhBw3pC5gU=; b=mUlN5rn5a19zhI7jfBSCa0olGfODruI0X/xUblx1q0uvAxXh+648+zdyVyPKv192I6 uq8XJA3NEwMA3DquZYi5m/1k8Ki9gXXBSGJYT+HZNo4pD21WNVrzpU3kxCZcOC5sB1ou niOkEKMsa3XSsbKIj5BfiaZ2+Nj4Hq0OCBS20MWassmtvCMk/f6iJvQHQu/D7LCj/p1J j5wwzJUkrI+GXqBuSH+HCbbUyk3enZbvZILP7NFGQT5ILy97YJzQx8sFfGc9C7eAbTTh /mDK2mdXYVBUn8s0M7h9G9Du9zZbQBuL8A8kxYgz+pp0Yrr8YnF566l5ot2Aox0nds5Z xubA== 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=0+VmB982cKF+Yg4IztQUGSSyWwS1vQJ+ehhBw3pC5gU=; b=fsC1Q/qBMbPOdtnmZ66qqKdz3R065Rg0QM6kZVrXx1D7oB6v6t8FKWcWz4rpWOGQqW BDqe8vpcsrCOjlmV5PZo0kSx+mWT7GUNAa4XrGxYf2B0Kg7ShNfttSK02FShWtdyzixp YND6tn9sfIVaDvRhIvzzwLJVUre+N7VNoLmBDyc1b2Pq2jMjTCWRPpWWgES4L1IunXZj qDT4CZARTBbjPZoCn++kQjEv3WJCEziX/1v6zMW+h9B2W8QSX59aMUI828Je0dD9hGdc zcwIIXNanTqHRftr92gnlskY0uSRlxLyVOj2Id18M4GCjTSPY1PCLJ36h1OcbvWwTUfa Ea9w== X-Gm-Message-State: AFeK/H0NMy2ec4IbUwYE4LRs9nWhIFihVbliNT1uXaqxpcSiOpEGPah/b3ylPMWvMTYvxVpnSmtRSNdKEkhHuQ== X-Received: by 10.157.21.86 with SMTP id z22mr245982otz.36.1491307980227; Tue, 04 Apr 2017 05:13:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.101.11 with HTTP; Tue, 4 Apr 2017 05:12:59 -0700 (PDT) From: ranjana mukhia Date: Tue, 4 Apr 2017 17:42:59 +0530 Message-ID: To: uta@ietf.org Content-Type: multipart/alternative; boundary=94eb2c191e04698acf054c5632f9 Archived-At: Subject: [Uta] MTA-STS-03 review 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, 04 Apr 2017 12:13:03 -0000 --94eb2c191e04698acf054c5632f9 Content-Type: text/plain; charset=UTF-8 Hi All, I have a basic question to ask related to the below-mentioned lines of the draft. >We additionally consider the Denial of Service risk posed by an > attacker who can modify the DNS records for a victim domain. Absent > SMTP STS, such an attacker can cause a sending MTA to cache invalid > MX records for a long TTL. With SMTP STS, the attacker can > additionally advertise a new, long-"max_age" SMTP STS policy with > "mx" constraints that validate the malicious MX record, causing > senders to cache the policy and refuse to deliver messages once the > victim has resecured the MX records. > This attack is mitigated in part by the ability of a victim domain to > (at any time) publish a new policy updating the cached, malicious > policy, though this does require the victim domain to both obtain a > valid CA-signed certificate and to understand and properly configure > SMTP STS. *can the above mentioned solution, provide the preemptive measure for avoiding the DOS attack?* Regards Ranjana Centre for Development of Advanced Computing(CDAC),Bangalore(India) --94eb2c191e04698acf054c5632f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

I have a basic question to ask = related to the below-mentioned lines of the draft.

>We additionally consider the Denial =
of Service risk posed by an
>  at=
tacker who can modify the DNS records for a victim domain.  Absent
>   SMTP STS, such an attacker can cause a sending MTA to cache invalid
>   MX records for a long TTL.  With SMTP STS, the attacker can

>   additionally advertise a new=
, long-"max_age" SMTP STS policy with
>  "mx" constraints that validate the malicious MX record, cau=
sing
>   senders to cache the policy and refuse to deliver messages once the
>   victim has resecured the MX records.

>   This attack is mitigated in part by the ability of a victim domain t=
o
>   (at any time) publish a new policy updating the cached, malicious
>   policy, though this does require the victim domain to both obtain a
>   valid CA-signed certificate and to understand and properly configure
>   SMTP STS.


can=
 the above mentioned solution, provide the preemptive measure for avoiding =
the DOS attack?


Regards
Ranjana
Centre for Development  of Advanced Computing(CDAC)=
,Bangalore(India)


--94eb2c191e04698acf054c5632f9-- From nobody Tue Apr 4 07:21:06 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 397E5128B4E for ; Tue, 4 Apr 2017 07:21:05 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 sg5Fl9oHSf1r for ; Tue, 4 Apr 2017 07:21:01 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 C15AE1288B8 for ; Tue, 4 Apr 2017 07:21:01 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id a140so29268992ita.0 for ; Tue, 04 Apr 2017 07:21:01 -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=XPAPb/SZylBwcNGDmEGxVidy3r4H8jBY2P9msjUp/rE=; b=nHpeZG1ev+g1n8HFKZB6wIOQjsAOl9musK2IWqM6z74v5/VSeSNonboiQUMF+36fUW AKDj0dgrlOo0gJFsljhSb0hubduGyVPc4+//f3MfNGBcGNr/G6CgiS73C82ixE4XfOwZ EDUiJRAPieZLgeOGQ8PBYsphIe8dkuG0Sw0ahI+PAovz850gKR9it8+/87IoIj6zQtLE hlOxiB39eahdow9snUKsYolyfLunnA68IuY/ZpGT7taiIYaJl56AnURxse/okH3mazZa WftSdfvJKdLcM8Ul7AKYQkfMZ9JESt9ieLeEkDcD+zZiTMJDuSuFjdspA5EyVx15IX8I BXqA== 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=XPAPb/SZylBwcNGDmEGxVidy3r4H8jBY2P9msjUp/rE=; b=O0uCBMzw44w5ne0r8O8gmeZeEzur9Fh4Ll5qbKSnpUKnzj14PYdvcO2YLhaaoVZ7cA bbbU1lqYY8Vw5Xbeca6GG44G5YSF1QQbtqxKBmP1WmJUWAzss9pLZoMQQ50X9RbCsGlO CBY1/9twLjjJx5BeIDkt+fmuYxEFhNdJGUv7vcszJXz6VueNodsHvgbVQOb9vLcWxmvB 56J4e0u/nwtJlOHAhEekdyDGXbhllk5q9F1br6ZvRbj5/93VR9tb5nMBnaweQLIR7ak8 cui12buZJ0Zz+5xAWQ8bQxeCqCFD3tP7mcnKGZw1RTjy0vdwrVDRqtyY4+FZVFOS/BnY Flig== X-Gm-Message-State: AFeK/H1ZTU6WvpOetXrblNYBL6CVtm3BoGVWfN7ntCLJnSVjYWC6m8Uqy43a/3YQ/XREb/39v0xDYzUvLU3++NSQ X-Received: by 10.36.13.149 with SMTP id 143mr15314102itx.21.1491315660631; Tue, 04 Apr 2017 07:21:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.39.215 with HTTP; Tue, 4 Apr 2017 07:20:59 -0700 (PDT) In-Reply-To: References: From: Daniel Margolis Date: Tue, 4 Apr 2017 16:20:59 +0200 Message-ID: To: ranjana mukhia Cc: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1144d5ec3d0b70054c57fc8f" Archived-At: Subject: Re: [Uta] MTA-STS-03 review 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, 04 Apr 2017 14:21:05 -0000 --001a1144d5ec3d0b70054c57fc8f Content-Type: multipart/alternative; boundary=001a1144d5ec33c12f054c57fcc9 --001a1144d5ec33c12f054c57fcc9 Content-Type: text/plain; charset=UTF-8 Hi, Can you explain a little more what you mean? The mitigation is to publish a new policy with the correct values, so certainly anyone who does so pre-emptively is not likely to fall victim to a DoS attack. More specifically, anyone who is _aware_ of this risk should simply ensure untrusted individuals cannot publish content with a certificate for *. example.com on "mta-sts.example.com"; the risk is for domains like (say) tumblr.com who may inadvertently allow that. On Tue, Apr 4, 2017 at 2:12 PM, ranjana mukhia wrote: > Hi All, > > I have a basic question to ask related to the below-mentioned lines of the > draft. > > >We additionally consider the Denial of Service risk posed by an > > > attacker who can modify the DNS records for a victim domain. Absent > > SMTP STS, such an attacker can cause a sending MTA to cache invalid > > MX records for a long TTL. With SMTP STS, the attacker can > > > additionally advertise a new, long-"max_age" SMTP STS policy with > > "mx" constraints that validate the malicious MX record, causing > > senders to cache the policy and refuse to deliver messages once the > > victim has resecured the MX records. > > > This attack is mitigated in part by the ability of a victim domain to > > (at any time) publish a new policy updating the cached, malicious > > policy, though this does require the victim domain to both obtain a > > valid CA-signed certificate and to understand and properly configure > > SMTP STS. > > > > *can the above mentioned solution, provide the preemptive measure for avoiding the DOS attack?* > > > > Regards > > Ranjana > > Centre for Development of Advanced Computing(CDAC),Bangalore(India) > > > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > > --001a1144d5ec33c12f054c57fcc9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Can you explain a little more= what you mean? The mitigation is to publish a new policy with the correct = values, so certainly anyone who does so pre-emptively is not likely to fall= victim to a DoS attack. More specifically, anyone who is _aware_ of this r= isk should simply ensure untrusted individuals cannot publish content with = a certificate for *.example.com on "= ;mta-sts.example.com"; the = risk is for domains like (say) tumblr.com= who may inadvertently allow that.=C2=A0

On Tue, Apr 4, 2017 at 2:12 PM, ranjana = mukhia <fbmails2me@gmail.com> wrote:
Hi All,

I have a basic qu= estion to ask related to the below-mentioned lines of the draft.
= 
>W=
e additionally consider the Denial of Service risk posed by an
>  attacker who can modi=
fy the DNS records for a victim domain.  Absent
>   SMTP STS, such an attacker can cause a sending MTA to cache invalid
>   MX records for a long TTL.  With SMTP STS, the attacker can

>   additio=
nally advertise a new, long-"max_age" SMTP STS policy with
>  "mx" constraints that validate the malicious MX record, cau=
sing
>   senders to cache the policy and refuse to deliver messages once the
>   victim has resecured the MX records.

>   This attack is mitigated in part by the ability of a victim domain t=
o
>   (at any time) publish a new policy updating the cached, malicious
>   policy, though this does require the victim domain to both obtain a
>   valid CA-signed certificate and to understand and properly configure
>   SMTP STS.


can the above m=
entioned solution, provide the preemptive measure for avoiding the DOS atta=
ck?


=

Regards
Ranjana
Centre for Development  of Advance=
d Computing(CDAC),Bangalore(India)



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


--001a1144d5ec33c12f054c57fcc9-- --001a1144d5ec3d0b70054c57fc8f 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAoP2wu5Iovoe3r l4ANbdjUBTug219aXMKC7gazOrl7cDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA0MDQxNDIxMDFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAWBmAwfcbs5N8d6vKjTgL8Bp9wxVMB3VY D51Qzpk0S21ELw/e2/qAO6AdgHoeuQqsoqOFDUKWzh7xGHcjEQz75JSpuu90XZ8IsStCtSyWwNTf kegpBASKAYSuw1XEH97ND4FmlZO5TlmqE7teRpvVV1zjRrvVMPOdDP7xJGBGtBgsXO2XKd38QVoy q6oahel+XGEJYJ9+liZ3F75xRpLkYu27bti5EfP5zTdghn7L1Xtt+o8AI+zQyXMTQdgvPIIZBDs9 YKPaQTzxEIz+c80zJAz8bbekkC6I7VqUCKQwrT/lbBb/yFU032Ko6f8BlaJV9QULfpiaSvPUNdjz wgJv7w== --001a1144d5ec3d0b70054c57fc8f-- From nobody Tue Apr 4 11:21: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 C816D129490 for ; Tue, 4 Apr 2017 11:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMn1XU-wOj6R for ; Tue, 4 Apr 2017 11:21:24 -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 B064B128E19 for ; Tue, 4 Apr 2017 11:21:24 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 03BEF7A330D; Tue, 4 Apr 2017 18:21:23 +0000 (UTC) Date: Tue, 4 Apr 2017 18:21:23 +0000 From: Viktor Dukhovni To: uta@ietf.org Message-ID: <20170404182123.GR25754@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] MTA-STS-03 review 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, 04 Apr 2017 18:21:27 -0000 On Tue, Apr 04, 2017 at 04:20:59PM +0200, Daniel Margolis wrote: > Can you explain a little more what you mean? The mitigation is to publish a > new policy with the correct values, so certainly anyone who does so > pre-emptively is not likely to fall victim to a DoS attack. More > specifically, anyone who is _aware_ of this risk should simply ensure > untrusted individuals cannot publish content with a certificate for *. > example.com on "mta-sts.example.com"; the risk is for domains like (say) > tumblr.com who may inadvertently allow that. I too found the text in question confusing. It makes no mention the attacker is presumed able to obtain certificates for "mta-sts.example.com", but otherwise the description does not make much sense. The DNS TXT record does indeed facilitate recovery after the fact by signalling the availability of an updated policy. I would also like to encourage the authors to post revised drafts more frequently. Please see: https://www.ietf.org/mail-archive/web/ietf/current/threads.html#101804 -- Viktor. From nobody Tue Apr 4 12:38: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 6F1AC1205D3 for ; Tue, 4 Apr 2017 12:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGnOaNtMvGpq for ; Tue, 4 Apr 2017 12:38:22 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 EB646127275 for ; Tue, 4 Apr 2017 12:38:21 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QCS20V02M8010997@mauve.mrochek.com> for uta@ietf.org; Tue, 4 Apr 2017 12:33:17 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QCQVHRJDXS00ZAK8@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for uta@ietf.org; Tue, 04 Apr 2017 12:33:11 -0700 (PDT) From: ned+uta@mrochek.com Cc: uta@ietf.org Message-id: <01QCS20RB8W400ZAK8@mauve.mrochek.com> Date: Tue, 04 Apr 2017 12:32:58 -0700 (PDT) In-reply-to: "Your message dated Tue, 04 Apr 2017 18:21:23 +0000" <20170404182123.GR25754@mournblade.imrryr.org> References: <20170404182123.GR25754@mournblade.imrryr.org> To: Viktor Dukhovni Archived-At: Subject: Re: [Uta] MTA-STS-03 review 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, 04 Apr 2017 19:38:24 -0000 > On Tue, Apr 04, 2017 at 04:20:59PM +0200, Daniel Margolis wrote: > > Can you explain a little more what you mean? The mitigation is to publish a > > new policy with the correct values, so certainly anyone who does so > > pre-emptively is not likely to fall victim to a DoS attack. More > > specifically, anyone who is _aware_ of this risk should simply ensure > > untrusted individuals cannot publish content with a certificate for *. > > example.com on "mta-sts.example.com"; the risk is for domains like (say) > > tumblr.com who may inadvertently allow that. > I too found the text in question confusing. It makes no mention > the attacker is presumed able to obtain certificates for > "mta-sts.example.com", but otherwise the description does not make > much sense. The DNS TXT record does indeed facilitate recovery > after the fact by signalling the availability of an updated policy. > I would also like to encourage the authors to post revised drafts > more frequently. Please see: > https://www.ietf.org/mail-archive/web/ietf/current/threads.html#101804 +1000. Ned From nobody Wed Apr 5 07:18:09 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 3958D124282; Wed, 5 Apr 2017 07:18:01 -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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149140188117.1128.17402693168758910093@ietfa.amsl.com> Date: Wed, 05 Apr 2017 07:18:01 -0700 Archived-At: Subject: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-04.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: Wed, 05 Apr 2017 14:18:01 -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 of the IETF. Title : SMTP TLS Reporting Authors : Daniel Margolis Alexander Brotman Binu Ramakrishnan Janet Jones Mark Risher Filename : draft-ietf-uta-smtp-tlsrpt-04.txt Pages : 17 Date : 2017-04-05 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-uta-smtp-tlsrpt-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-tlsrpt-04 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 Wed Apr 5 07:18:42 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 8C2DA1294B8; Wed, 5 Apr 2017 07:18:36 -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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149140191653.1191.3095654268022218269@ietfa.amsl.com> Date: Wed, 05 Apr 2017 07:18:36 -0700 Archived-At: Subject: [Uta] I-D Action: draft-ietf-uta-mta-sts-04.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: Wed, 05 Apr 2017 14:18:37 -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 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-04.txt Pages : 17 Date : 2017-04-05 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-uta-mta-sts-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-mta-sts-04 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 Wed Apr 5 07:33:44 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 37F7C129489 for ; Wed, 5 Apr 2017 07:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 uhRPS6hrfg7z for ; Wed, 5 Apr 2017 07:33:40 -0700 (PDT) Received: from copdcmhout01.cable.comcast.com (copdcmhout01.cable.comcast.com [162.150.44.71]) (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 070D712944A for ; Wed, 5 Apr 2017 07:33:32 -0700 (PDT) X-AuditID: a2962c47-c7ff89a00000ad42-5b-58e5003cf23d Received: from COPDCEX18.cable.comcast.com (Unknown_Domain [96.114.156.147]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by copdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 4F.AD.44354.C3005E85; Wed, 5 Apr 2017 08:33:32 -0600 (MDT) Received: from COPDCEX19.cable.comcast.com (147.191.124.150) by COPDCEX18.cable.comcast.com (147.191.124.149) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 5 Apr 2017 08:33:30 -0600 Received: from COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380]) by COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380%19]) with mapi id 15.00.1263.000; Wed, 5 Apr 2017 08:33:30 -0600 From: "Brotman, Alexander" To: "uta@ietf.org" Thread-Topic: Updated MTA-STS & TLSRPT Drafts Thread-Index: AdKuF4vPvUyjSd6oRqayf+4pnIFdDw== Date: Wed, 5 Apr 2017 14:33:29 +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: [68.87.29.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsWSUDRnsq4Nw9MIg8adyhanjjYzOjB6LFny kymAMYrLJiU1J7MstUjfLoEro3lNK2PBDfaKLzv3Mzcw9rN1MXJySAiYSKw/Nx/I5uIQEljB JPFr7WQo5yCjxN51jYwQzglGiRUP3zGBtLAJWEm8/d/ODGKLCChKvPjznh3EFhbQkPj++xY7 RFxX4uuvv1C2nsTUnidg9SwCKhIrDx9mAbF5Bbwk5qztYgWxGQXEJL6fWgM2n1lAXOLWk/lM EOcJSCzZc54ZwhaVePn4HyuEbSCxdek+FghbTmLu63ssEL06Egt2f2KDsLUlli18zQyxS1Di 5MwnUPXiEoeP7GCdwCg6C8m6WUjaZyFpn4WkfQEjyypGueT8gpTk3Iz80hIDQ73kxKScVL3k /NzkxOISEL2JERgpi6bpuO9gvNDrfIhRgINRiYfX/8+TCCHWxLLiytxDjBIczEoivOrvgUK8 KYmVValF+fFFpTmpxYcYpTlYlMR5vW/eihASSE8sSc1OTS1ILYLJMnFwSjUwBv4/0nqrwPZ+ 67sXMRY2fsHsn+KeJbaIzC5YIvxevJo3Rfml7MEIhas89/uNnVfmPXQ8KW6QPMVb9HjzwZ3/ p8coTtNU+84+WWXa7ON/rqldW770q+H6uQe/Le2R2WTy+abdPzurnowty9cxVYspKvbLf59l XGz8bV74qQ1v0ra/WqBh3/BLWYmlOCPRUIu5qDgRADMtREmQAgAA Archived-At: Subject: [Uta] Updated MTA-STS & TLSRPT Drafts 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, 05 Apr 2017 14:33:43 -0000 Hello, I meant to send these yesterday, but got sidetracked with some things at th= e office, as well as a rather long meeting. Probably the biggest alteration is that we altered both to utilize the SAN = instead of the CN for hostname/policy validation. We made several clarific= ations, and updated pseudocode as well. Ultimately, it was decided to keep= the JSON for the policy as it should be easily parsed either with the appr= opriate JSON libraries or using standard string manipulation functions avai= lable in most languages. I believe these updates address the issues that have been discussed, and we= 'd like to work toward a last call (with approval from the chairs). If the= re are further issues, or believe we have not appropriately addressed an is= sue, please let us know. We'll attempt to quickly update the drafts and ge= t them back to the group. Thank you for your time. -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast x5364 From nobody Wed Apr 5 08:00:22 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 4214B129498 for ; Wed, 5 Apr 2017 08:00:21 -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, RP_MATCHES_RCVD=-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 xaXxEx2Uw0hQ for ; Wed, 5 Apr 2017 08:00:19 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 4E14C129488 for ; Wed, 5 Apr 2017 08:00:18 -0700 (PDT) Received: from [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_RC100) id 1cvmPu-0004gW-Hw for uta@ietf.org (return-path ); Wed, 05 Apr 2017 15:00:14 +0000 To: uta@ietf.org From: Jeremy Harris Message-ID: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> Date: Wed, 5 Apr 2017 16:00:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: [Uta] mtp-tlsrpt-04 review 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, 05 Apr 2017 15:00:21 -0000 The example in Appendix 9 implies that the Policy Domain should correspond to the domain part of email addresses attempted. I think this should be made explicit in an earlier section, eg. Section 3 ("A domain should") - otherwise it could confused with the A-record domain of an MX. CNAME indirections should be explicitly discussed (I'd like them permitted). -- Cheers, Jeremy From nobody Wed Apr 5 08:46: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 C5AFB1273E2 for ; Wed, 5 Apr 2017 08:46:36 -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 fV8jmLOtceKd for ; Wed, 5 Apr 2017 08:46: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 6E4C4129477 for ; Wed, 5 Apr 2017 08:46:30 -0700 (PDT) Received: from [172.31.30.48] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id B8C917A330A for ; Wed, 5 Apr 2017 15:46:29 +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: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> Date: Wed, 5 Apr 2017 11:46:28 -0400 Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Message-Id: <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] mtp-tlsrpt-04 review 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, 05 Apr 2017 15:46:37 -0000 > On Apr 5, 2017, at 11:00 AM, Jeremy Harris wrote: > > The example in Appendix 9 All I see is "Section 10, Appendix 1" and "Section 11, Appendix 2". What is "Appendix 9"? > CNAME indirections should be explicitly discussed > (I'd like them permitted). Where would you like to see CNAMEs permitted? [ Oh, and by the way, it seems the authors have concluded that JSON policy has rough consensus. I am not sure that's accurate, or at least don't think that accurately represents MTA implementors. Where do you stand on the JSON issue? I am not looking forward to adding a JSON parser to Postfix, or requiring all the O/S platforms to provide a common C JSON API (is there one that is widely available) as a pre-requisite for installing Postfix. ] -- Viktor. From nobody Wed Apr 5 09:02: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 5CE8E129447 for ; Wed, 5 Apr 2017 09:02:41 -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, RP_MATCHES_RCVD=-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 VlKARr6UEB3J for ; Wed, 5 Apr 2017 09:02:38 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 98B97126C89 for ; Wed, 5 Apr 2017 09:02:37 -0700 (PDT) Received: from [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_RC100) id 1cvnOD-00004y-PX for uta@ietf.org (return-path ); Wed, 05 Apr 2017 16:02:33 +0000 To: uta@ietf.org References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> From: Jeremy Harris Message-ID: Date: Wed, 5 Apr 2017 17:02:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Uta] mtp-tlsrpt-04 review 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, 05 Apr 2017 16:02:41 -0000 On 05/04/17 16:46, Viktor Dukhovni wrote: > >> On Apr 5, 2017, at 11:00 AM, Jeremy Harris wrote: >> >> The example in Appendix 9 > > All I see is "Section 10, Appendix 1" and "Section 11, Appendix 2". > What is "Appendix 9"? Apologies. Section 9, being Appendix 2. >> CNAME indirections should be explicitly discussed >> (I'd like them permitted). > > Where would you like to see CNAMEs permitted? Perhaps Section 3, initial paragraph. > [ Oh, and by the way, it seems the authors have concluded that > JSON policy has rough consensus. I am not sure that's accurate, > or at least don't think that accurately represents MTA implementors. > > Where do you stand on the JSON issue? I am not looking forward to > adding a JSON parser to Postfix, or requiring all the O/S platforms > to provide a common C JSON API (is there one that is widely available) > as a pre-requisite for installing Postfix. ] I do not intend to add a JSON parser to Exim, and would make my anti-bloat views known to any of the other Exim developers. [I have the same views on any need for https, cf. MTA-STS] However, I don't think using JSON for the reports defined by this draft would require an MTA-based parser. -- Cheers, Jeremy From nobody Wed Apr 5 10:15: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 AE24912949B for ; Wed, 5 Apr 2017 10:15:07 -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 G9oshA_2KY61 for ; Wed, 5 Apr 2017 10:14:55 -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 2ACC5127775 for ; Wed, 5 Apr 2017 10:14:55 -0700 (PDT) Received: from [172.31.30.48] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 752BF7A330A for ; Wed, 5 Apr 2017 17:14:54 +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, 5 Apr 2017 13:14:53 -0400 Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Message-Id: <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] mtp-tlsrpt-04 review 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, 05 Apr 2017 17:15:08 -0000 > On Apr 5, 2017, at 12:02 PM, Jeremy Harris wrote: > > On 05/04/17 16:46, Viktor Dukhovni wrote: >> >>> On Apr 5, 2017, at 11:00 AM, Jeremy Harris wrote: >>> >>> The example in Appendix 9 >> >> All I see is "Section 10, Appendix 1" and "Section 11, Appendix 2". >> What is "Appendix 9"? > > Apologies. Section 9, being Appendix 2. Oops, sorry, I though you were commenting on the STS draft, not the report draft. >> [ Oh, and by the way, it seems the authors have concluded that >> JSON policy has rough consensus. I am not sure that's accurate, >> or at least don't think that accurately represents MTA implementors. >> >> Where do you stand on the JSON issue? I am not looking forward to >> adding a JSON parser to Postfix, or requiring all the O/S platforms >> to provide a common C JSON API (is there one that is widely available) >> as a pre-requisite for installing Postfix. ] > > I do not intend to add a JSON parser to Exim, and would make my > anti-bloat views known to any of the other Exim developers. > > [I have the same views on any need for https, cf. MTA-STS] Sorry that question was about STS... -- Viktor. From nobody Thu Apr 6 02:08: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 5A2A31243F6 for ; Thu, 6 Apr 2017 02:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.998 X-Spam-Level: X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 wgO23Lih2jvE for ; Thu, 6 Apr 2017 02:08:54 -0700 (PDT) Received: from out.mail.ec.europa.eu (out.mail.ec.europa.eu [147.67.249.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840361200FC for ; Thu, 6 Apr 2017 02:08:53 -0700 (PDT) Received: from S-DC-EMP019-I.net1.cec.eu.int (158.166.6.137) by S-DC-EDG009-Q.rcnet.cec.eu.int (147.67.249.5) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 6 Apr 2017 11:08:42 +0200 Received: from S-DC-EMP009-B.net1.cec.eu.int (158.167.2.19) by S-DC-EMP019-I.net1.cec.eu.int (158.166.6.137) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 6 Apr 2017 11:08:49 +0200 Received: from S-DC-ESTE03-B.net1.cec.eu.int ([169.254.2.152]) by S-DC-EMP009-B.net1.cec.eu.int ([158.167.2.19]) with mapi id 14.03.0301.000; Thu, 6 Apr 2017 11:08:50 +0200 From: To: Thread-Topic: draft-ietf-uta-mta-sts-04 Review Thread-Index: AdKutGbXiPZGQt7NR9iZoIOalBzYkA== Date: Thu, 6 Apr 2017 09:08:49 +0000 Message-ID: <2DB01F3A9898AE41BB3266315D9FDA2704903D88@S-DC-ESTE03-B.net1.cec.eu.int> Accept-Language: en-GB, fr-LU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.167.189.38] Content-Type: multipart/alternative; boundary="_000_2DB01F3A9898AE41BB3266315D9FDA2704903D88SDCESTE03Bnet1c_" MIME-Version: 1.0 Archived-At: Subject: [Uta] draft-ietf-uta-mta-sts-04 Review 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, 06 Apr 2017 09:08:57 -0000 --_000_2DB01F3A9898AE41BB3266315D9FDA2704903D88SDCESTE03Bnet1c_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29tZSBtaW5vciBjb21tZW50cyBhbmQgYSBxdWVzdGlvbiBvbiBwb2xpY3kgdXBkYXRlcy4NCg0K XyBTZWN0aW9uIDMuMiBNVEEtU1RTIFBvbGljaWVzLCB3aGVuIGRlc2NyaWJpbmcgdGhlICJteCIg cGFyYW1ldGVyLCBpdCBzYXlzOg0KDQoiRm9yIGV4YW1wbGUsICJbIm1haWwuZXhhbXBsZS5jb20i LCAiLmV4YW1wbGUubmV0Il0iIGluZGljYXRlcyB0aGF0DQptYWlsIGZvciB0aGlzIGRvbWFpbiBt aWdodCBiZSBoYW5kbGVkIGJ5IGFueSBNWCB3aXRoIGEgY2VydGlmaWNhdGUNCnZhbGlkIGZvciBh IGhvc3QgYXQgImV4YW1wbGUuY29tIiBvciAiZXhhbXBsZS5uZXQiLi4uIg0KU2hvdWxkJ3QgaXQg c2F5OiAiIHZhbGlkIGZvciBhIGhvc3QgYXQgJ21haWwuZXhhbXBsZS5jb20nIj8NCg0KXyBTZWN0 aW9uIDMuMyBIVFRQUyBQb2xpY3kgRmV0Y2hpbmcNCg0KIldoZW4gZmV0Y2hpbmcgYSBuZXcgcG9s aWN5IG9yIHVwZGF0aW5nIGEgcG9saWN5LCB0aGUgSFRUUFMgZW5kcG9pbnQNCk1VU1QgcHJlc2Vu dCBhIFguNTA5IGNlcnRpZmljYXRlIHdoaWNoIGlzIHZhbGlkIGZvciB0aGUgIm10YS1zdHMiDQpo b3N0IChhcyBkZXNjcmliZWQgaW4gW1JGQzYxMjVdKSwgY2hhaW4gdG8gYSByb290IENBIHRoYXQg aXMgdHJ1c3RlZA0KYnkgdGhlIHNlbmRpbmcgTVRBLCBhbmQgYmUgbm9uLWV4cGlyZWQuIg0KIE1h eWJlIGl0J3MgcmVkdW5kYW50LCBidXQgc2luY2UgaXQgZXhwbGljaXRseSBtZW50aW9uIG5vbi1l eHBpcmVkLA0Kc2hvdWxkIGl0IGFsc28gbWVudGlvbiBub3QgcmV2b2NhdGVkPw0KDQoiSWYgYSB2 YWxpZCBUWFQgcmVjb3JkIGlzIGZvdW5kIGJ1dCBubyBwb2xpY3kgY2FuIGJlIGZldGNoZWQgdmlh DQpIVFRQUywgYW5kIHRoZXJlIGlzIG5vIHZhbGlkIChub24tZXhwaXJlZCkgcHJldmlvdXNseS1j YWNoZWQgcG9saWN5LA0Kc2VuZGVycyBNVVNUIHRyZWF0IHRoZSByZWNpcGllbnQgZG9tYWluIGFz IG9uZSB0aGF0IGhhcyBub3QNCmltcGxlbWVudGVkIE1UQS1TVFMuIg0KIEkgdGhpbmsgdGhhdCBh IGJldHRlciBvcHRpb24gd291bGQgYmUgdG8gcmVwb3J0IHRoZSByZWNpcGllbnQgYW5kDQpjb250 aW51ZSB3aXRoIG9wcG9ydHVuaXN0aWMgVExTLg0KDQpfIFNlY3Rpb24gNCBQb2xpY3kgVmFsaWRh dGlvbjoNCg0KIjIuICBUaGF0IGF0IGxlYXN0IG9uZSBvZiB0aGUgcG9saWN5J3MgIm14IiBwYXR0 ZXJucyBtYXRjaGVzIGF0IGxlYXN0DQogICAgIG9uZSBvZiB0aGUgaWRlbnRpdGllcyBwcmVzZW50 ZWQgaW4gdGhlIE1YJ3MgWC41MDkgY2VydGlmaWNhdGUsIGFzDQogICAgIGRlc2NyaXBlZCBpbiAi TVggQ2VydGlmaWNhdGUgVmFsaWRhdGlvbiIuIg0KDQpUaGUgbGFzdCBsaW5lIHNob3VsZCBzYXkg ImRlc2NyaWJlZCBpbiAuLi4iDQoNCg0KXyBTZWN0aW9uIDQuMSBNWCBDZXJ0aWZpY2F0ZSBWYWxp ZGF0aW9uOiAoU2FtZSB0aGFuIGluIHNlY3Rpb24gMy4zIGFib3V0IGNlcnRpZmljYXRlcykNCg0K IlRoZSBjZXJ0aWZpY2F0ZSBwcmVzZW50ZWQgYnkgdGhlIHJlY2VpdmluZyBNWCBNVVNUIGNoYWlu IHRvIGEgcm9vdCBDQQ0KdGhhdCBpcyB0cnVzdGVkIGJ5IHRoZSBzZW5kaW5nIE1UQSBhbmQgYmUg bm9uLWV4cGlyZWQuICINCiBNYXliZSBpdCdzIHJlZHVuZGFudCwgYnV0IHNpbmNlIGl0IGV4cGxp Y2l0bHkgbWVudGlvbiBub24tZXhwaXJlZCwNCnNob3VsZCBpdCBhbHNvIG1lbnRpb24gbm90IHJl dm9jYXRlZD8NCg0KXyBTZWN0aW9uIDUuMSBQb2xpY3kgQXBwbGljYXRpb24gQ29udHJvbCBGbG93 DQoNCiIzLiBVcG9uIG1lc3NhZ2UgcmV0cmllcywgYSBtZXNzYWdlIE1BWSBiZSBwZXJtYW5lbnRs eSBmYWlsZWQNCiAgICBmb2xsb3dpbmcgZmlyc3QgY2hlY2tpbmcgZm9yIHRoZSBwcmVzZW5jZSBv ZiBhIG5ldyBwb2xpY3kgKGFzDQogICAgaW5kaWNhdGVkIGJ5IHRoZSAiaWQiIGZpZWxkIGluIHRo ZSAiX210YS1zdHMiIFRYVCByZWNvcmQpLiINCg0KSXQgZG9lcyBub3Qgc3BlY2lmeSB0aGUgbnVt YmVyIG9mIHJldHJpZXMuIEEgcGFyYW1ldGVyIGNvdWxkIGJlIGFkZGVkIHRvDQp0aGUgcG9saWN5 IHRvIGluZGljYXRlIHRoZSBudW1iZXIgb2YgcmV0cmllcyBiZWZvcmUgcGVybWFuZW50IGZhaWx1 cmUsDQp3aXRoIGEgZGVmYXVsdCB2YWx1ZSBvZiBYLg0KDQpNYXliZSBJIG1pc3NlZCBpdCwgYnV0 IEkgZGlkbid0IHNlZSBhbnkgbWVudGlvbiB0byB3aGF0IHRvIGRvIGlmDQp0aGUgaWQgZnJvbSB0 aGUgVFhUIHJlY29yZCBkb2VzIG5vdCBtYXRjaCB0aGUgaWQgZnJvbSB0aGUgSFRUUFMgcG9saWN5 Lg0KDQpfIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zOg0KDQpUaGUgZmlyc3QgcGFyYWdyYXBoIG9m IFNlY3Rpb24gNi4xIGNvbnRyYWRpY3RzIHRoZSBzZWNvbmQgcGFyYWdyYXBoIG9uIFNlY3Rpb24g OC4zDQoNCiAgIlVwZGF0aW5nIHRoZSBwb2xpY3kgcmVxdWlyZXMgdGhhdCB0aGUgb3duZXIgbWFr ZSBjaGFuZ2VzIGluIHR3bw0KICAgcGxhY2VzOiB0aGUgIl9tdGEtc3RzIiBUWFQgcmVjb3JkIGlu IHRoZSBQb2xpY3kgRG9tYWluJ3MgRE5TIHpvbmUgYW5kDQogICBhdCB0aGUgY29ycmVzcG9uZGlu ZyBIVFRQUyBlbmRwb2ludC4gIEFzIGEgcmVzdWx0LCByZWNpcGllbnRzIHNob3VsZA0KICAgdGh1 cyBleHBlY3QgYSBwb2xpY3kgd2lsbCBjb250aW51ZSB0byBiZSB1c2VkIGJ5IHNlbmRlcnMgdW50 aWwgYm90aA0KICAgdGhlIEhUVFBTIGFuZCBUWFQgZW5kcG9pbnRzIGFyZSB1cGRhdGVkIGFuZCB0 aGUgVFhUIHJlY29yZCdzIFRUTCBoYXMNCiAgIHBhc3NlZC4iICgxc3QgcGFyYWdyYXBoIFNlY3Rp b24gNi4xKQ0KDQogICJUaGlzIGF0dGFjayBpcyBtaXRpZ2F0ZWQgaW4gcGFydCBieSB0aGUgYWJp bGl0eSBvZiBhIHZpY3RpbSBkb21haW4gdG8NCiAgIChhdCBhbnkgdGltZSkgcHVibGlzaCBhIG5l dyBwb2xpY3kgdXBkYXRpbmcgdGhlIGNhY2hlZCwgbWFsaWNpb3VzDQogICBwb2xpY3ksIHRob3Vn aCB0aGlzIGRvZXMgcmVxdWlyZSB0aGUgdmljdGltIGRvbWFpbiB0byBib3RoIG9idGFpbiBhDQog ICB2YWxpZCBDQS1zaWduZWQgY2VydGlmaWNhdGUgYW5kIHRvIHVuZGVyc3RhbmQgYW5kIHByb3Bl cmx5IGNvbmZpZ3VyZQ0KICAgTVRBLVNUUy4iICgybmQgcGFyYWdyYXBoIFNlY3Rpb24gOC4zKQ0K DQogICBJZiBJIGFtIGFibGUgdG8gcHVibGlzaCBhIG5ldyBwb2xpY3ksIGJ1dCB0aGlzIHBvbGlj eSBkb2VzIG5vdCByZWFjaA0KICAgdGhlIHNlbmRlcnMsIHRoZW4gSSBhbSBub3Qgc29sdmluZyB0 aGUgcHJvYmxlbS4NCg0KVGhlIHdob2xlIHBvbGljeSBhcHBsaWNhdGlvbiwgdXBkYXRlIGlzIG5v dCBjbGVhciB0byBtZSwgaXQgc2VlbXMgdGhlcmUgaXMNCmEgY29udHJhZGljdGlvbiBiZXR3ZWVu IHRoZSBmYWN0LCBtZW50aW9uZWQgYSBjb3VwbGUgb2YgdGltZXMsIHRoYXQgYSBwb2xpY3kNCmNh biBiZSB1cGRhdGVkIGFueSB0aW1lLCBhbmQgdGhlIHJlc2lzdGFuY2UgdG8gIlRMUyBkb3duZ3Jh ZGUiIGF0dGFja3MuIFBsZWFzZQ0KY29ycmVjdCBtZSBpZiBJJ20gd3JvbmcuDQoNCkluIHRoZSBw b2xpY3kgdXBkYXRlcywgaXQgY2xlYXJseSBzdGF0ZXMgdGhhdCB1cGRhdGluZyBhIHBvbGljeSBy ZXF1aXJlcw0KdXBkYXRpbmcgYm90aCB0aGUgVFhUIHJlY29yZCBhbmQgdGhlIEhUVFBTIHBvbGlj eS4NCg0KRE5TIHJlcXVlc3QgYXJlIHVzdWFsbHkgc2VydmVkIGJ5IGludGVybWVkaWFyeSBETlMg c2VydmVycywgdGhhdCB3aWxsIHVwZGF0ZQ0KdGhlIGNhY2hlIGJhc2VkIG9uIHRoZSBUVEwgb2Yg cmVjb3Jkcywgd2hlcmVhcyBIVFRQUyByZXF1ZXN0cyB3aWxsIGJlIHVzdWFsbHkNCnNlcnZlZCBi eSB0aGUgImZpbmFsIiBzZXJ2ZXIgaXRzZWxmLCB0aGVyZWZvcmUgcG9saWN5IHVwZGF0ZXMgd2ls bCBpbW1lZGlhdGVseQ0KKGFsbW9zdCkgYmUgZGVwbG95ZWQuDQoNClRoaXMgY3JlYXRlcyBhIGRp bGVtbWEuIFVzaW5nIHNob3J0IFRUTHMgdG8gYWxsb3cgZnJlcXVlbnQgcG9saWN5IHVwZGF0ZXMg aW5jcmVhc2VzDQp0aGUgd2luZG93IG9mIHZ1bG5lcmFiaWxpdHkgKHBvbGljeSB1cGRhdGUgcmVx dWlyZXMgZmV0Y2hpbmcgdGhlIFRYVCByZWNvcmQpLA0KYnV0IHVzaW5nIGxvbmcgVFRMcyByZWR1 Y2VzIHRoZSBhYmlsaXR5IHRvIHVwZGF0ZSB0aGUgcG9saWN5IG9uLWRlbWFuZC4NCg0KQSBwb3Nz aWJsZSBzb2x1dGlvbiBjb3VsZCBiZSB0byB1bmxpbmsgdGhlIGlkIGZyb20gdGhlIFRYVCByZWNv cmQgZnJvbSB0aGUgaWQgb2YgdGhlIHBvbGljeS4NCkEgbG9uZyBUVEwgKDEgbW9udGg/KSBjYW4g YmUgdXNlZCB0byAiYnJvYWRjYXN0IiB0aGF0IGEgZG9tYWluIGFwcGxpZXMgTVRBLVNUUywgYW5k IGEgc2hvcnQNCm1heC1hZ2UgKGhvdXJzLCBtaW51dGVzPykgY2FuIGJlIHVzZWQgdG8gZmFjaWxp dGF0ZSBmcmVxdWVudCBwb2xpY3kgdXBkYXRlcy4NCg0KRmluYWxseSwgcmVnYXJkaW5nIHRoZSBK U09OIHZzIHBhaXItb2YtdmFsdWVzLCAgSSB0aGluayB0aGF0IGF0IHRoaXMgc3RhZ2UgdGhlIG9w aW5pb24gb2YgdGhlDQpJbXBsZW1lbnRvcnMgKHRob3NlIHdobyB3aWxsIGltcGxlbWVudCBpdCkg c2hvdWxkIHByZXZhaWwsIHRvIGZhY2lsaXRhdGUgaXRzIGZ1dHVyZSBhY2NlcHRhbmNlLg0KSSBk b24ndCB0aGluayBpdCBtYWtlcyBtdWNoIGRpZmZlcmVuY2UgZm9yIGRvbWFpbiBjb250cm9sbGVy cywgd2hvIG1heSBkZXBsb3kgaXQuDQoNCkdlcmFyZCBEcmFwZXIgR2lsDQoNCg== --_000_2DB01F3A9898AE41BB3266315D9FDA2704903D88SDCESTE03Bnet1c_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1HQjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNvbWUgbWlub3IgY29tbWVudHMgYW5kIGEgcXVlc3Rpb24gb24g cG9saWN5IHVwZGF0ZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl8gU2VjdGlvbiAzLjIgTVRB LVNUUyBQb2xpY2llcywgd2hlbiBkZXNjcmliaW5nIHRoZSAmcXVvdDtteCZxdW90OyBwYXJhbWV0 ZXIsIGl0IHNheXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O0ZvciBleGFtcGxlLCAm cXVvdDtbJnF1b3Q7bWFpbC5leGFtcGxlLmNvbSZxdW90OywgJnF1b3Q7LmV4YW1wbGUubmV0JnF1 b3Q7XSZxdW90OyBpbmRpY2F0ZXMgdGhhdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+bWFpbCBmb3IgdGhpcyBkb21haW4gbWlnaHQgYmUgaGFuZGxlZCBieSBhbnkgTVggd2l0 aCBhIGNlcnRpZmljYXRlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj52YWxp ZCBmb3IgYSBob3N0IGF0ICZxdW90O2V4YW1wbGUuY29tJnF1b3Q7IG9yICZxdW90O2V4YW1wbGUu bmV0JnF1b3Q7Li4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNob3VsZCd0IGl0IHNheTogJnF1 b3Q7IHZhbGlkIGZvciBhIGhvc3QgYXQgJ21haWwuZXhhbXBsZS5jb20nJnF1b3Q7PzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5fIFNlY3Rpb24gMy4zIEhUVFBTIFBvbGljeSBGZXRjaGluZzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDtXaGVuIGZldGNoaW5nIGEgbmV3IHBvbGljeSBvciB1 cGRhdGluZyBhIHBvbGljeSwgdGhlIEhUVFBTIGVuZHBvaW50PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5NVVNUIHByZXNlbnQgYSBYLjUwOSBjZXJ0aWZpY2F0ZSB3aGljaCBp cyB2YWxpZCBmb3IgdGhlICZxdW90O210YS1zdHMmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmhvc3QgKGFzIGRlc2NyaWJlZCBpbiBbUkZDNjEyNV0pLCBjaGFpbiB0 byBhIHJvb3QgQ0EgdGhhdCBpcyB0cnVzdGVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5ieSB0aGUgc2VuZGluZyBNVEEsIGFuZCBiZSBub24tZXhwaXJlZC4mcXVvdDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7TWF5YmUgaXQncyByZWR1bmRhbnQsIGJ1dCBzaW5jZSBpdCBl eHBsaWNpdGx5IG1lbnRpb24gbm9uLWV4cGlyZWQsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5zaG91bGQgaXQgYWxzbyBtZW50aW9uIG5vdCByZXZvY2F0ZWQ/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZxdW90O0lmIGEgdmFsaWQgVFhUIHJlY29yZCBpcyBmb3VuZCBidXQg bm8gcG9saWN5IGNhbiBiZSBmZXRjaGVkIHZpYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SFRUUFMsIGFuZCB0aGVyZSBpcyBubyB2YWxpZCAobm9uLWV4cGlyZWQpIHByZXZp b3VzbHktY2FjaGVkIHBvbGljeSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnNlbmRlcnMgTVVTVCB0cmVhdCB0aGUgcmVjaXBpZW50IGRvbWFpbiBhcyBvbmUgdGhhdCBoYXMg bm90PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pbXBsZW1lbnRlZCBNVEEt U1RTLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtJIHRoaW5rIHRoYXQgYSBiZXR0ZXIg b3B0aW9uIHdvdWxkIGJlIHRvIHJlcG9ydCB0aGUgcmVjaXBpZW50IGFuZDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29udGludWUgd2l0aCBvcHBvcnR1bmlzdGljIFRMUy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+XyBTZWN0aW9uIDQgUG9saWN5IFZhbGlkYXRpb246PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90OzIuJm5ic3A7IFRoYXQgYXQgbGVhc3Qgb25lIG9m IHRoZSBwb2xpY3kncyAmcXVvdDtteCZxdW90OyBwYXR0ZXJucyBtYXRjaGVzIGF0IGxlYXN0PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgb25lIG9mIHRoZSBpZGVudGl0aWVzIHByZXNlbnRlZCBpbiB0aGUgTVgncyBYLjUwOSBjZXJ0 aWZpY2F0ZSwgYXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwZWQgaW4gJnF1b3Q7TVggQ2VydGlmaWNhdGUgVmFsaWRh dGlvbiZxdW90Oy4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZSBsYXN0IGxpbmUgc2hvdWxkIHNheSAmcXVvdDtkZXNjcmliZWQgaW4g Li4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+XyBTZWN0aW9uIDQuMSBNWCBDZXJ0aWZpY2F0ZSBWYWxpZGF0 aW9uOiAoU2FtZSB0aGFuIGluIHNlY3Rpb24gMy4zIGFib3V0IGNlcnRpZmljYXRlcyk8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7VGhlIGNlcnRpZmljYXRlIHByZXNlbnRlZCBieSB0aGUg cmVjZWl2aW5nIE1YIE1VU1QgY2hhaW4gdG8gYSByb290IENBPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj50aGF0IGlzIHRydXN0ZWQgYnkgdGhlIHNlbmRpbmcgTVRBIGFuZCBi ZSBub24tZXhwaXJlZC4gJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO01heWJlIGl0J3Mg cmVkdW5kYW50LCBidXQgc2luY2UgaXQgZXhwbGljaXRseSBtZW50aW9uIG5vbi1leHBpcmVkLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2hvdWxkIGl0IGFsc28gbWVudGlv biBub3QgcmV2b2NhdGVkPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fIFNlY3Rpb24gNS4xIFBv bGljeSBBcHBsaWNhdGlvbiBDb250cm9sIEZsb3c8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1 b3Q7My4gVXBvbiBtZXNzYWdlIHJldHJpZXMsIGEgbWVzc2FnZSBNQVkgYmUgcGVybWFuZW50bHkg ZmFpbGVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsm bmJzcDsgZm9sbG93aW5nIGZpcnN0IGNoZWNraW5nIGZvciB0aGUgcHJlc2VuY2Ugb2YgYSBuZXcg cG9saWN5IChhczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IGluZGljYXRlZCBieSB0aGUgJnF1b3Q7aWQmcXVvdDsgZmllbGQgaW4gdGhlICZx dW90O19tdGEtc3RzJnF1b3Q7IFRYVCByZWNvcmQpLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JdCBkb2VzIG5vdCBzcGVjaWZ5IHRoZSBudW1iZXIgb2YgcmV0cmllcy4gQSBwYXJhbWV0 ZXIgY291bGQgYmUgYWRkZWQgdG8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+dGhlIHBvbGljeSB0byBpbmRpY2F0ZSB0aGUgbnVtYmVyIG9mIHJldHJpZXMgYmVmb3JlIHBl cm1hbmVudCBmYWlsdXJlLA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53 aXRoIGEgZGVmYXVsdCB2YWx1ZSBvZiBYLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWF5YmUg SSBtaXNzZWQgaXQsIGJ1dCBJIGRpZG4ndCBzZWUgYW55IG1lbnRpb24gdG8gd2hhdCB0byBkbyBp Zg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgaWQgZnJvbSB0aGUg VFhUIHJlY29yZCBkb2VzIG5vdCBtYXRjaCB0aGUgaWQgZnJvbSB0aGUgSFRUUFMgcG9saWN5Ljxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGUgZmlyc3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNi4xIGNvbnRy YWRpY3RzIHRoZSBzZWNvbmQgcGFyYWdyYXBoIG9uIFNlY3Rpb24gOC4zPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmcXVvdDtVcGRhdGluZyB0aGUgcG9saWN5IHJlcXVpcmVzIHRoYXQg dGhlIG93bmVyIG1ha2UgY2hhbmdlcyBpbiB0d288bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBwbGFjZXM6IHRoZSAmcXVvdDtfbXRhLXN0cyZxdW90OyBU WFQgcmVjb3JkIGluIHRoZSBQb2xpY3kgRG9tYWluJ3MgRE5TIHpvbmUgYW5kPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgYXQgdGhlIGNvcnJlc3BvbmRp bmcgSFRUUFMgZW5kcG9pbnQuJm5ic3A7IEFzIGEgcmVzdWx0LCByZWNpcGllbnRzIHNob3VsZDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IHRodXMgZXhw ZWN0IGEgcG9saWN5IHdpbGwgY29udGludWUgdG8gYmUgdXNlZCBieSBzZW5kZXJzIHVudGlsIGJv dGg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyB0aGUg SFRUUFMgYW5kIFRYVCBlbmRwb2ludHMgYXJlIHVwZGF0ZWQgYW5kIHRoZSBUWFQgcmVjb3JkJ3Mg VFRMIGhhczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7 IHBhc3NlZC4mcXVvdDsgKDFzdCBwYXJhZ3JhcGggU2VjdGlvbiA2LjEpPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmcXVvdDtUaGlzIGF0dGFjayBpcyBtaXRpZ2F0 ZWQgaW4gcGFydCBieSB0aGUgYWJpbGl0eSBvZiBhIHZpY3RpbSBkb21haW4gdG88bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAoYXQgYW55IHRpbWUpIHB1 Ymxpc2ggYSBuZXcgcG9saWN5IHVwZGF0aW5nIHRoZSBjYWNoZWQsIG1hbGljaW91czxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IHBvbGljeSwgdGhvdWdo IHRoaXMgZG9lcyByZXF1aXJlIHRoZSB2aWN0aW0gZG9tYWluIHRvIGJvdGggb2J0YWluIGE8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyB2YWxpZCBDQS1z aWduZWQgY2VydGlmaWNhdGUgYW5kIHRvIHVuZGVyc3RhbmQgYW5kIHByb3Blcmx5IGNvbmZpZ3Vy ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IE1UQS1T VFMuJnF1b3Q7ICgybmQgcGFyYWdyYXBoIFNlY3Rpb24gOC4zKTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsgSWYgSSBhbSBhYmxlIHRvIHB1Ymxpc2ggYSBuZXcgcG9saWN5LCBi dXQgdGhpcyBwb2xpY3kgZG9lcyBub3QgcmVhY2g8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyB0aGUgc2VuZGVycywgdGhlbiBJIGFtIG5vdCBzb2x2aW5n IHRoZSBwcm9ibGVtLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHdob2xlIHBvbGljeSBh cHBsaWNhdGlvbiwgdXBkYXRlIGlzIG5vdCBjbGVhciB0byBtZSwgaXQgc2VlbXMgdGhlcmUgaXMN CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YSBjb250cmFkaWN0aW9uIGJl dHdlZW4gdGhlIGZhY3QsIG1lbnRpb25lZCBhIGNvdXBsZSBvZiB0aW1lcywgdGhhdCBhIHBvbGlj eTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y2FuIGJlIHVwZGF0ZWQgYW55 IHRpbWUsIGFuZCB0aGUgcmVzaXN0YW5jZSB0byAmcXVvdDtUTFMgZG93bmdyYWRlJnF1b3Q7IGF0 dGFja3MuIFBsZWFzZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29ycmVj dCBtZSBpZiBJJ20gd3JvbmcuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgcG9saWN5 IHVwZGF0ZXMsIGl0IGNsZWFybHkgc3RhdGVzIHRoYXQgdXBkYXRpbmcgYSBwb2xpY3kgcmVxdWly ZXMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dXBkYXRpbmcgYm90aCB0 aGUgVFhUIHJlY29yZCBhbmQgdGhlIEhUVFBTIHBvbGljeS4gPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkROUyByZXF1ZXN0IGFyZSB1c3VhbGx5IHNlcnZlZCBieSBpbnRlcm1lZGlhcnkgRE5TIHNl cnZlcnMsIHRoYXQgd2lsbCB1cGRhdGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+dGhlIGNhY2hlIGJhc2VkIG9uIHRoZSBUVEwgb2YgcmVjb3Jkcywgd2hlcmVhcyBIVFRQ UyByZXF1ZXN0cyB3aWxsIGJlIHVzdWFsbHkNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+c2VydmVkIGJ5IHRoZSAmcXVvdDtmaW5hbCZxdW90OyBzZXJ2ZXIgaXRzZWxmLCB0 aGVyZWZvcmUgcG9saWN5IHVwZGF0ZXMgd2lsbCBpbW1lZGlhdGVseQ0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oYWxtb3N0KSBiZSBkZXBsb3llZC4gPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoaXMgY3JlYXRlcyBhIGRpbGVtbWEuIFVzaW5nIHNob3J0IFRUTHMgdG8g YWxsb3cgZnJlcXVlbnQgcG9saWN5IHVwZGF0ZXMgaW5jcmVhc2VzDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSB3aW5kb3cgb2YgdnVsbmVyYWJpbGl0eSAocG9saWN5 IHVwZGF0ZSByZXF1aXJlcyBmZXRjaGluZyB0aGUgVFhUIHJlY29yZCksDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1dCB1c2luZyBsb25nIFRUTHMgcmVkdWNlcyB0aGUg YWJpbGl0eSB0byB1cGRhdGUgdGhlIHBvbGljeSBvbi1kZW1hbmQuDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QSBwb3NzaWJsZSBzb2x1dGlvbiBjb3VsZCBiZSB0byB1bmxpbmsgdGhlIGlkIGZy b20gdGhlIFRYVCByZWNvcmQgZnJvbSB0aGUgaWQgb2YgdGhlIHBvbGljeS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgbG9uZyBUVEwgKDEgbW9udGg/KSBjYW4gYmUgdXNl ZCB0byAmcXVvdDticm9hZGNhc3QmcXVvdDsgdGhhdCBhIGRvbWFpbiBhcHBsaWVzIE1UQS1TVFMs IGFuZCBhIHNob3J0DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm1heC1h Z2UgKGhvdXJzLCBtaW51dGVzPykgY2FuIGJlIHVzZWQgdG8gZmFjaWxpdGF0ZSBmcmVxdWVudCBw b2xpY3kgdXBkYXRlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RmluYWxseSwgcmVnYXJkaW5n IHRoZSBKU09OIHZzIHBhaXItb2YtdmFsdWVzLCZuYnNwOyBJIHRoaW5rIHRoYXQgYXQgdGhpcyBz dGFnZSB0aGUgb3BpbmlvbiBvZiB0aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SW1wbGVtZW50b3JzICh0aG9zZSB3aG8gd2lsbCBpbXBsZW1lbnQgaXQpIHNob3VsZCBw cmV2YWlsLCB0byBmYWNpbGl0YXRlIGl0cyBmdXR1cmUgYWNjZXB0YW5jZS4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCB0aGluayBpdCBtYWtlcyBtdWNoIGRp ZmZlcmVuY2UgZm9yIGRvbWFpbiBjb250cm9sbGVycywgd2hvIG1heSBkZXBsb3kgaXQuDQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPkdlcmFyZCBEcmFwZXIgR2lsPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJJVCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_2DB01F3A9898AE41BB3266315D9FDA2704903D88SDCESTE03Bnet1c_-- From nobody Thu Apr 6 06:17: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 E0803127F0E for ; Thu, 6 Apr 2017 06:17:13 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaDGyKEhqcBP for ; Thu, 6 Apr 2017 06:17:11 -0700 (PDT) Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) (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 3AADE120227 for ; Thu, 6 Apr 2017 06:17:03 -0700 (PDT) X-AuditID: 60729ed4-c7bff70000004a04-88-58e63fcd21cb Received: from COPDCEX17.cable.comcast.com (Unknown_Domain [96.114.156.147]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id E6.CE.18948.DCF36E85; Thu, 6 Apr 2017 07:17:02 -0600 (MDT) Received: from COPDCEX19.cable.comcast.com (147.191.124.150) by COPDCEX17.cable.comcast.com (147.191.124.148) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 6 Apr 2017 07:17:00 -0600 Received: from COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380]) by COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380%19]) with mapi id 15.00.1263.000; Thu, 6 Apr 2017 07:17:01 -0600 From: "Brotman, Alexander" To: "uta@ietf.org" Thread-Topic: [Uta] mtp-tlsrpt-04 review Thread-Index: AQHSrh1c+DSkrZDt10Cb3xx0Sxc636G3T+4AgAAEfQCAABQ3gIAA5MhQ Date: Thu, 6 Apr 2017 13:17:00 +0000 Message-ID: <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> In-Reply-To: <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> 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.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsWSUDRnsu45+2cRBoce61ucOtrM6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLYOjoJjAhWbjr9jbWCcwdvFyMkhIWAicfLBbJYuRi4OIYEV TBK/HvcwQTgHGSVuLLvJClIlJHCCUeJWoyyIzSZgJfH2fzsziC0ioCjx4s97dhBbWEBd4taC PhaIuIbElRU/oWw3iX8H/jOC2CwCKhI/b+0Cq+cV8JLYdOIyM8Sy+4wSb2dtByviFHCQ6F+3 GcxmFBCT+H5qDROIzSwgLnHryXwmiLMFJJbsOc8MYYtKvHz8jxXCNpDYunQfC4QtJ7Hs5x1m iF4diQW7P7FB2NoSyxa+ZoY4QlDi5MwnUPXiEoeP7GCdwCg+C8m6WUjaZyFpn4WkfQEjyypG ueT8gpTk3Iz80hIDI73kxKScVL3k/NzkxOISEL2JERxX867sYLw83eMQowAHoxIPr4n8swgh 1sSy4srcQ4wSHMxKIrx+1kAh3pTEyqrUovz4otKc1OJDjNIcLErivN43b0UICaQnlqRmp6YW pBbBZJk4OKUaGJ3CTju5pn/awdzQZFW9s6Btkvvs18f3L47esYkl4ZdBqu1Dix4Jh111lv85 jrxe3fKEy9FQNkLpSszajfPu83/f0Lzt5sdFW9eseJWwIVKv48rst398Yi8dvrT06vM/Qf8f 7X2be/Smyc/i/t2bvJxNg2YmHuF5P+9zeui11inR9XsPVjyZe4ZTiaU4I9FQi7moOBEAEmEj CacCAAA= Archived-At: Subject: Re: [Uta] mtp-tlsrpt-04 review 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, 06 Apr 2017 13:17:14 -0000 In section 4, it mentions the Policy section should include the domain for = which the policy was applied. I can add another reference in Section 3 if = that's preferred. We can add an explicit CNAME mention.=20 With regard to the JSON policy (though that's STS, not TLSRPT). It's a sma= ll file, which given the JSON requirement, should be properly formatted. I= would think this should be relatively easy to parse with standard C string= functions. -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast x5364 -----Original Message----- From: Uta [mailto:uta-bounces@ietf.org] On Behalf Of Viktor Dukhovni Sent: Wednesday, April 05, 2017 1:15 PM To: uta@ietf.org Subject: Re: [Uta] mtp-tlsrpt-04 review > On Apr 5, 2017, at 12:02 PM, Jeremy Harris wrote: >=20 > On 05/04/17 16:46, Viktor Dukhovni wrote: >>=20 >>> On Apr 5, 2017, at 11:00 AM, Jeremy Harris wrote: >>>=20 >>> The example in Appendix 9 >>=20 >> All I see is "Section 10, Appendix 1" and "Section 11, Appendix 2". >> What is "Appendix 9"? >=20 > Apologies. Section 9, being Appendix 2. Oops, sorry, I though you were commenting on the STS draft, not the report = draft. >> [ Oh, and by the way, it seems the authors have concluded that JSON=20 >> policy has rough consensus. I am not sure that's accurate, or at=20 >> least don't think that accurately represents MTA implementors. >>=20 >> Where do you stand on the JSON issue? I am not looking forward to =20 >> adding a JSON parser to Postfix, or requiring all the O/S platforms =20 >> to provide a common C JSON API (is there one that is widely=20 >> available) as a pre-requisite for installing Postfix. ] >=20 > I do not intend to add a JSON parser to Exim, and would make my=20 > anti-bloat views known to any of the other Exim developers. >=20 > [I have the same views on any need for https, cf. MTA-STS] Sorry that question was about STS... --=20 Viktor. _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta From nobody Thu Apr 6 06:35:30 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 6FAE9128656 for ; Thu, 6 Apr 2017 06:35:29 -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, RP_MATCHES_RCVD=-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 sqxjXNgobnAC for ; Thu, 6 Apr 2017 06:35:27 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 CC6F51294F0 for ; Thu, 6 Apr 2017 06:35:18 -0700 (PDT) Received: from [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_RC100) id 1cw7ZC-0001i8-Fk for uta@ietf.org (return-path ); Thu, 06 Apr 2017 13:35:14 +0000 To: uta@ietf.org References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> From: Jeremy Harris Message-ID: <18337bbe-36d8-a60c-41fa-29d8f8a56b91@wizmail.org> Date: Thu, 6 Apr 2017 14:35:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Uta] mtp-tlsrpt-04 review 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, 06 Apr 2017 13:35:29 -0000 On 06/04/17 14:17, Brotman, Alexander wrote: > In section 4, it mentions the Policy section should include the domain for which the policy was applied. I can add another reference in Section 3 if that's preferred. The point I'm trying to make is that the generator of reports needs to know how to select a domain for which a particular message transmission attempt should be reported against. This needs to be specified. Please give the semantics of this "domain" mentioned in both sections 3 and 4 (separately if they differ, else it needs to be clear that they are the same; perhaps by using the term "Policy Domain" mentioned in section 1). -- Cheers, Jeremy From nobody Thu Apr 6 07:12:03 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 C449B128CDB for ; Thu, 6 Apr 2017 07:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3SmfQtbz5ll for ; Thu, 6 Apr 2017 07:11:59 -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 8A77E1275AB for ; Thu, 6 Apr 2017 07:11:53 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (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 CFA2A7A330A for ; Thu, 6 Apr 2017 14:11:52 +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: <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> Date: Thu, 6 Apr 2017 10:11:51 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] back to smtp-sts-04 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, 06 Apr 2017 14:12:02 -0000 > On Apr 6, 2017, at 9:17 AM, Brotman, Alexander = wrote: >=20 > With regard to the JSON policy (though that's STS, not TLSRPT). > It's a small file, which given the JSON requirement, should > be properly formatted. I would think this should be relatively > easy to parse with standard C string functions. Here are the line counts for the "*.[ch]" files from what appears to be a popular JSON parsing API for C: $ git clone https://github.com/json-c/json-c.git $ cd json-c $ wc -l *.[ch] | sort -n 11 strdup_compat.h 19 json_inttypes.h 20 json_c_version.c 22 json_c_version.h 25 random_seed.h 26 libjson.c 31 math_compat.h 34 json.h 35 bits.h 45 vasprintf_compat.h 55 json_object_private.h 63 arraylist.h 71 debug.h 83 debug.c 89 json_util.h 91 json_visit.h 114 printbuf.h 115 json_pointer.h 133 json_visit.c 143 arraylist.c 154 printbuf.c 168 json_object_iterator.c 208 json_tokener.h 238 random_seed.c 239 json_object_iterator.h 326 json_pointer.c 326 json_util.c 366 linkhash.h 690 linkhash.c 901 json_object.h 978 json_tokener.c 1195 json_object.c 7014 total That does not jive with relatively easy to parse... JSON supports comments, elements that are integers, strings, arrays or associative arrays (nested JSON objects). JSON strings are UTF-8 and allow embedded NUL octets. Your JSON reference is to the obsolete RFC4627, the non-obsolete reference is RFC7159. Speaking of the policy, what should be done if the HTTPS policy contains multiple JSON objects, no JSON objects, or broken JSON? Is there a size limit a parser can reasonably impose on the policy data to avoid resource exhaustion parsing absurdly large JSON input? Could we say for example that a valid STSv1 JSON object must fit in 16K bytes or 64K bytes? How does a domain get rid of its STS policy? I thought we had discussed using "max_age =3D 0" for this, which after being in place long enough = to assure that all previously cached policies have expired can be removed. Or might just "404" suffice? --=20 Viktor. From nobody Fri Apr 7 06:20:55 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 37F55129461 for ; Fri, 7 Apr 2017 06:20:54 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVWFOfsjDel2 for ; Fri, 7 Apr 2017 06:20:52 -0700 (PDT) Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) (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 8707A1242EA for ; Fri, 7 Apr 2017 06:20:52 -0700 (PDT) X-AuditID: 60729ed4-c7bff70000004a04-97-58e79233e747 Received: from COPDCEX18.cable.comcast.com (Unknown_Domain [96.114.156.147]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id D0.D0.18948.33297E85; Fri, 7 Apr 2017 07:20:52 -0600 (MDT) Received: from COPDCEX19.cable.comcast.com (147.191.124.150) by COPDCEX18.cable.comcast.com (147.191.124.149) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 7 Apr 2017 07:20:50 -0600 Received: from COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380]) by COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380%19]) with mapi id 15.00.1263.000; Fri, 7 Apr 2017 07:20:50 -0600 From: "Brotman, Alexander" To: Jeremy Harris , "uta@ietf.org" Thread-Topic: [Uta] mtp-tlsrpt-04 review Thread-Index: AQHSrh1c+DSkrZDt10Cb3xx0Sxc636G3T+4AgAAEfQCAABQ3gIAA5MhQgABwJoCAASmoIA== Date: Fri, 7 Apr 2017 13:20:50 +0000 Message-ID: References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> <18337bbe-36d8-a60c-41fa-29d8f8a56b91@wizmail.org> In-Reply-To: <18337bbe-36d8-a60c-41fa-29d8f8a56b91@wizmail.org> 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.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsWSUDRnsq7JpOcRBl9uM1kcvLeLzeLU0WZG ByaPJUt+MnmsOLuJLYApissmJTUnsyy1SN8ugStjU/Nn1oLvHBUvdq1ma2BcyN7FyMkhIWAi sWPvLCCbi0NIYAWTxJRl+9kgnIOMEq83fGeEcE4wSize3wzWwiZgJfH2fzsziC0i4CTx/8pD VhBbWEBd4taCPhaIuIbElRU/oewwiTcPv4PVswioSLzqWgU2h1fAS2L19nVQ264ySRy4dYsR JMEpYC9x7FsvWAOjgJjE91NrmEBsZgFxiVtP5jNB3C0gsWTPeWYIW1Ti5eN/rBC2gcTWpftY IGw5iZ4drYwQvToSC3Z/YoOwtSWWLXzNDHGEoMTJmU+g6sUlDh/ZwTqBUXwWknWzkLTPQtI+ C0n7AkaWVYxyyfkFKcm5GfmlJQZGesmJSTmpesn5ucmJxSUgehMjON7mXdnBeHm6xyFGAQ5G JR7e5x3PI4RYE8uKK3MPMUpwMCuJ8Kb1A4V4UxIrq1KL8uOLSnNSiw8xSnOwKInzet+8FSEk kJ5YkpqdmlqQWgSTZeLglGpgtIyR+Jd38nf/GsvW1MA5u+4dk/027eecSU+VQhaztAqfLUz5 brD88YlPstfffLDbWHlM4qziC80tK7g/3Drrs3OSuD2r+bv4T45vHl3K3mbheGz/e46p3v3H atRffFmQFs157aTkbdX4HfdVG7fVHvzH7xRgwS19dMk59q8r8xZ0vHt45u/srBdKLMUZiYZa zEXFiQCMjdnSswIAAA== Archived-At: Subject: Re: [Uta] mtp-tlsrpt-04 review 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, 07 Apr 2017 13:20:54 -0000 Ah, we'll make that more clear. Thank you for the feedback. -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast x5364 -----Original Message----- From: Uta [mailto:uta-bounces@ietf.org] On Behalf Of Jeremy Harris Sent: Thursday, April 06, 2017 9:35 AM To: uta@ietf.org Subject: Re: [Uta] mtp-tlsrpt-04 review On 06/04/17 14:17, Brotman, Alexander wrote: > In section 4, it mentions the Policy section should include the domain fo= r which the policy was applied. I can add another reference in Section 3 i= f that's preferred. The point I'm trying to make is that the generator of reports needs to know= how to select a domain for which a particular message transmission attempt= should be reported against. This needs to be specified. Please give the semantics of this "domain" mentioned in both sections 3 and= 4 (separately if they differ, else it needs to be clear that they are the = same; perhaps by using the term "Policy Domain" mentioned in section 1). -- Cheers, Jeremy _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta From nobody Fri Apr 7 09:41:50 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 465FC12951E for ; Fri, 7 Apr 2017 09:41:49 -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 rwMsiNaxQjLw for ; Fri, 7 Apr 2017 09:41:45 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A19651294E0 for ; Fri, 7 Apr 2017 09:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1491583304; d=isode.com; s=june2016; i=@isode.com; bh=uIA813lvHyIegSBp8HEahNokGQzsph/FOD7HTHCr5rY=; 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=Jzz3AeoCTfJgWImem5OdYL/MB8pnwMq8lg0dLa2CtG68KCCXb73oyWdGkWUg/GTMQDoOzS 5XJfPblDGInAkJxzBYXCuDSS7MPlRLLCho2h5bElbkhwxTFxnW7h9LCy+yvGDbTinBwJeK Izcoag04Zsr2vM/cOrtqkPvindY2Lrk=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 7 Apr 2017 17:41:44 +0100 To: "uta@ietf.org" From: Alexey Melnikov Message-ID: Date: Fri, 7 Apr 2017 17:41:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-04.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: Fri, 07 Apr 2017 16:41:49 -0000 Hi, I've done an early Area Director-style review of the document. Some of the issues I found in -03 were already fixed in -04. In Section 1: Specifically, this document defines a reporting schema that covers failures in routing, STARTTLS negotiation, and both DANE [RFC6698] and MTA-STS (TODO: Add ref) policy validation errors, and a standard Such references should be fixed. Which format are you using for editing the document? TXT record that recipient domains can use to indicate where reports in this format should be sent. <> This document is intended as a companion to the specification for SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref). In 1.1: TLS needs a reference. In Section 2: You list related technologies, but don't mention how they relate to this document or why you need a new format. Can you add a sentence or two on this? After reading this section my initial reaction is "why on Earth you are not using/extending one of existing mechanisms?". In Section 3: HTTPS needs to be updated to point to [one of] the latest HTTP/1.1 RFC. mailto: URI needs a Normative Reference to RFC 6068. Do you want to mention something in this section about extensibility (e.g. in anticipation of addition of "ruf")? Unless "ruf" is gone for good, adding new values might be difficult otherwise. (And ideally this should also be reflected in the ABNF.) In Section 4.3 Is the list of result types extensible? If yes, you should create a new IANA registry, so that people can add new values, without the need to update this document. 4.3.3. General Failures When a negotiation failure can not be categorized into one of the "Negotiation Failures" stated above, the reporter SHOULD use the "validation-failure" category. As TLS grows and becomes more complex, new mechanisms may not be easily categorized. This allows for a generic feedback category. When this category is used, the reporter SHOULD also use the "failure-reason-code" to give some feedback to the receiving entity. This is intended to be a short text field, and the contents of the field should be an error code or error text, such as "X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION". Is this field human readable? In Section 5.3: "text/json" is not a registered MIME type. I think you meant "application/json". Why not define new email header fields? Encoding everything in Subject looks rather hackish. Also, why not define new JSON-based MIME type for reports? This will make it easier to process reports of different type addressed to the same email recipient. Section 7: o Flooding of the Aggregate report URI (rua) endpoint: An attacker could flood the endpoint and prevent the receiving domain from accepting additional reports. This type of Denial-of-Service attack would limit visibility into STARTTLS failures, leaving the receiving domain blind to an ongoing attack. [...] o Reports as DDoS: TLSRPT allows specifying destinations for the 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 the Policy Domain DNS could also use this mechanism to direct the reports to an unwitting victim, flooding that victim with excessive reports. DMARC [RFC7489] defines an elegant solution for verifying delegation; however, since the attacker had less ability to generate large reports than with DMARC failures, and since the Are these talking about the same issue? If yes, they should be merged or one of them should be deleted. Section 9: As this section is pretty much the most important section in the document, I am surprised that it is marked as Appendix. As a general comment, I think this section would benefit from more clarity about various syntaxes used. Some specific comments: o "policy-type": The type of policy that was applied by the sending domain. Presently, the only three valid choices are "tlsa", "sts", and the literal string "no-policy-found". It is provided as a string. Is this field case sensitive? If yes, it would be good to say so. o "policy-string": The string serialization of the policy, whether TLSA record or STS policy. Any linefeeds from the original policy MUST be replaced with [SP]. TODO: Help with specifics. The definition is clearly unfinished. o "domain": The Policy Domain upon which the policy was applied. For messages sent to "user@example.com" this field would contain "example.com". It is provided as a string. Again, need references here. Are IDN domains (in UTF-8) allowed here? o "ip-address": The IP address of the sending MTA that attempted the STARTTLS connection. It is provided as a string representation of an IPv4 or IPv6 address in dot-decimal or colon-hexadecimal notation. Need references for string representations of both types of IP addresses. o "success-aggregate": The aggregate number (integer) of successfully negotiated SSL-enabled connections to the receiving site. o "failure-aggregate": The aggregate number (integer) of failures to negotiate an SSL-enabled connection to the receiving site. Please let's use "TLS" everywhere instead of "SSL". I found at least 3 places. Best Regards, Alexey From nobody Tue Apr 18 08:05:45 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 BD40612EC9E for ; Tue, 18 Apr 2017 08:05:42 -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 io0MEEy79iVu for ; Tue, 18 Apr 2017 08:05:36 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 13C7B12EC0C for ; Tue, 18 Apr 2017 08:05:36 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id k87so169692566ioi.0 for ; Tue, 18 Apr 2017 08:05:36 -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=J0fHW2SWWqjLQ1Shm12CF3LOQ3uz31ek0kMIweSAO/k=; b=l48424BWfoHChCJRiAIC14p0fxcoOn+WdxHtzQ7ihMkZAwLmYfbUKNIM2nig2Su8Zb oIf/UunoFDUZbUQ+J64m/6lAvb9PG2lVhXcqY3ibABBayzsOrsQZ+dgJ6t5dJDhcUMEJ S/jbQyZAV37r1DOTQZD7DQQ0RuSa6hmMKR0zVJC2xC4CwkUhoMElcBcc4JhvbAd//XTS gEuxbdClIzbn4a3Bpv4Y8w0Y3JvdvYxsA6T/65UQ9F6Wb/lfl0CxjloG0Rv4tgd/kE4c rpAbLxfiNhkYHJ6hIo+yVflnSOish5Y8pejBZ7a9IKCFxe3KYuvyrdHKs8Km9uv1KOcz xhTQ== 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=J0fHW2SWWqjLQ1Shm12CF3LOQ3uz31ek0kMIweSAO/k=; b=Q/fJVuUNMuluznkIM0FRsWP0h9X6d0VzYNiyFaJKY5jartoIRemhqC2COGPyBuyBKB PzYD9jTWWUQzFyG/DoF5zCXzTa/Gusvx242jb98VAn9wvAKQaBCx1Q4Gxa8qrcPMI8QM 7ThtdekjCWogJkWlbW2p3Bu5cRdnksijjBwxZGEdQOU8DB6a/ZEFqGOczSclIHLMrOLf 2sGPM+hrKrYMSw8x8pe7ee7IlrP1LiO+IxU/ZX1xS/hIybUL09BGelYBD+SFhPKysKMA rS1D8wU0pG4QMEBJvVnlXrAaut0DX1KL0cbrrSPeGWNlqB7npg8tucOSGYvDxDnnx0Ox mcaw== X-Gm-Message-State: AN3rC/6n2/+uyeX3i86NSE4rC+5xw/jeLpb3a1HsMvd8vVcwkXVJjMnZ vaRTvmNJDwX70TS742ncb4jfqMFyMpa+ X-Received: by 10.107.172.134 with SMTP id v128mr15738689ioe.49.1492527921289; Tue, 18 Apr 2017 08:05:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.39.215 with HTTP; Tue, 18 Apr 2017 08:05:20 -0700 (PDT) In-Reply-To: <01QCS20RB8W400ZAK8@mauve.mrochek.com> References: <20170404182123.GR25754@mournblade.imrryr.org> <01QCS20RB8W400ZAK8@mauve.mrochek.com> From: Daniel Margolis Date: Tue, 18 Apr 2017 17:05:20 +0200 Message-ID: To: ned+uta@mrochek.com Cc: Viktor Dukhovni , uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1148d5d49c58b1054d723ce1" Archived-At: Subject: Re: [Uta] MTA-STS-03 review 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, 18 Apr 2017 15:05:43 -0000 --001a1148d5d49c58b1054d723ce1 Content-Type: multipart/alternative; boundary=001a1148d5d4914bbc054d723c40 --001a1148d5d4914bbc054d723c40 Content-Type: text/plain; charset=UTF-8 Thanks for the feedback. I think we were not sure how careful we should be about posting frequently vs spamming people with intermediate drafts. ;) What text do you find confusing? You mean this? Similarly, we consider the possibility of domains that deliberately > allow untrusted users to serve untrusted content on user-specified > subdomains. In some cases (e.g. the service Tumblr.com) this takes > the form of providing HTTPS hosting of user-registered subdomains; in > other cases (e.g. dynamic DNS providers) this takes the form of > allowing untrusted users to register custom DNS records at the > provider's domain. > > In these cases, there is a risk that untrusted users would be able to > serve custom content at the "mta-sts" host, including serving an > illegitimate MTA-STS policy. On Tue, Apr 4, 2017 at 9:32 PM, wrote: > > On Tue, Apr 04, 2017 at 04:20:59PM +0200, Daniel Margolis wrote: > > > > Can you explain a little more what you mean? The mitigation is to > publish a > > > new policy with the correct values, so certainly anyone who does so > > > pre-emptively is not likely to fall victim to a DoS attack. More > > > specifically, anyone who is _aware_ of this risk should simply ensure > > > untrusted individuals cannot publish content with a certificate for *. > > > example.com on "mta-sts.example.com"; the risk is for domains like > (say) > > > tumblr.com who may inadvertently allow that. > > > I too found the text in question confusing. It makes no mention > > the attacker is presumed able to obtain certificates for > > "mta-sts.example.com", but otherwise the description does not make > > much sense. The DNS TXT record does indeed facilitate recovery > > after the fact by signalling the availability of an updated policy. > > > I would also like to encourage the authors to post revised drafts > > more frequently. Please see: > > > https://www.ietf.org/mail-archive/web/ietf/current/ > threads.html#101804 > > +1000. > > Ned > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a1148d5d4914bbc054d723c40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the feedback. I think we were not sure how care= ful we should be about posting frequently vs spamming people with intermedi= ate drafts. ;)=C2=A0

What text do you find confusing? Yo= u mean this?

Similarly, we consider the possibility of domains that deliber= ately
=C2=A0 =C2=A0allow untrusted users to serve untrusted content on u= ser-specified
=C2=A0 =C2=A0subdomains.=C2=A0 In some cases (e.g. the ser= vice Tumblr.com) this takes
=C2=A0 =C2=A0the form of providing HTTPS hos= ting of user-registered subdomains; in
=C2=A0 =C2=A0other cases (e.g. dy= namic DNS providers) this takes the form of
=C2=A0 =C2=A0allowing untrus= ted users to register custom DNS records at the
=C2=A0 =C2=A0provider= 9;s domain.
=C2=A0
=C2=A0 =C2=A0In these cases, there is a risk that untru= sted users would be able to
=C2=A0 =C2=A0serve custom content at the &qu= ot;mta-sts" host, including serving an
=C2=A0 =C2=A0illegitimate MT= A-STS policy. =C2=A0

=C2=A0

On Tue, Apr 4, = 2017 at 9:32 PM, <ned+uta@mrochek.com> wrote:
> On Tue, Apr 04, 2017 at 04:20:= 59PM +0200, Daniel Margolis wrote:

> > Can you explain a little more what you mean? The mitigation is to= publish a
> > new policy with the correct values, so certainly anyone who does = so
> > pre-emptively is not likely to fall victim to a DoS attack.=C2=A0= More
> > specifically, anyone who is _aware_ of this risk should simply en= sure
> > untrusted individuals cannot publish content with a certificate f= or *.
> > example.com on "mta-sts.example.com"; the risk is for= domains like (say)
> > tumblr.com who may inadvertently allow that.

> I too found the text in question confusing.=C2=A0 It makes no mention<= br> > the attacker is presumed able to obtain certificates for
> "mta-sts.example.com", but otherwise the description do= es not make
> much sense.=C2=A0 The DNS TXT record does indeed facilitate recovery > after the fact by signalling the availability of an updated policy.
> I would also like to encourage the authors to post revised drafts
> more frequently.=C2=A0 Please see:

>=C2=A0 =C2=A0 =C2=A0https:= //www.ietf.org/mail-archive/web/ietf/current/threads.html#101804<= /a>

+1000.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ned

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

--001a1148d5d4914bbc054d723c40-- --001a1148d5d49c58b1054d723ce1 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCB38Otyjt3fkUEs 5CULmMAvqv6jbZMDzbvme6cUJ0s97jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA0MTgxNTA1MjJaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAkyYkzhjv9GVPQ2u0aioe80Qcvka2uNoH s5in8OFrKjJkJZw+5GyZYLMqzqyPi7C1pBsUN8UIknlCdeUcWot1uu00jLyTYF/5Xt//ozU3uRip yQnCpjLvcbnc3gtqLMW6/ko/7C1bhcWvEmR2RflWAAuC87iIwZD84xqnrhoc1viAptMawJlTTXp4 nmM1/EAmWdnLBqzLbEFowGJgNG0AKHaXUAM0ze0L1JSPt49wWy0yyAN7vZXKol3eeUEi33sXWfTb OKqp0+0+xF5cWuZjTjvV9ifj3SLdR6ylWS/m9gagrwQeplDPYFTBGnyw2nOivmGxO9p4fVi1eDyD +MWeNA== --001a1148d5d49c58b1054d723ce1-- From nobody Tue Apr 18 09:15: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 EBD5612EBFA for ; Tue, 18 Apr 2017 09:15:13 -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 xW7nGgXH4sNm for ; Tue, 18 Apr 2017 09:15:12 -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 CC792128ACA for ; Tue, 18 Apr 2017 09:15:11 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id o22so2282720iod.3 for ; Tue, 18 Apr 2017 09:15: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=Jlz72dmGc+7hsfLvSkcEM4grLlJA08eboW8+YdSusuo=; b=XoX9TGekr5QNLLsb5AtSzFG3srv15G+UgZ8BmwWv/YANrvuIMw/JOqvdw6PqvRljSr o5nNatZxvT3V8jLg1kGYVY5aWyR8TDzyB92c+TwhoFRtCpANkE7J/rrC9w8r9/4TtfMX eKxx4HV7hIy9nstLHuDy8dUDNjG83nlT8V2hgSvu7NSd0DibcuWYcqRaYCuTr/Nue3+J LRPOj+OCzPYptjdtU3PLhWs9YEZa9U6tQZsJxxFt5N38ow7M+OlEGjy/buycvp/BF1WZ trFMs1JKDowZOynrI3JfAiXQRZDMofo2V/3nkGoviGSg6f4szzhOHA/lqSB+K4fWlcSy XTog== 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=Jlz72dmGc+7hsfLvSkcEM4grLlJA08eboW8+YdSusuo=; b=PeMNdSySN9tTW2NTL/1tE9YU29ytuNnW/+xyD9BhPR+ozw3hLrrPh3U+36iAghg5gc c1fh8JRelh0a9xCG/lXAJCk4MPWOW4Xd/suLCVn4nNdD2OpZB6BLcvPHA0YArMCSJj+F au8pxKwoMZE3sPVe96qNz5KGOhsaIMprTy/7Ytv0pQCdCmEQ9+0DW/DvNmlbKVeSdcOe fyuelVRH+sNWper7kBG/eqTZj8A7pMCMH3P0nq7/iqmEVNIoKqrIU5ts7n9qw63qBj7o a3BOSLybAaey0BBAExiKQcj2Ui0GxwNHfLxoorffScF0VEuRswjPcoJZJWqC6mBqUDm7 aM7A== X-Gm-Message-State: AN3rC/6cOuPfrewbJx1ZvaQxY8RrpRbMTGbpr/K4fPrsINJazp7uuOkp xhqXaz+UpZcoIppb9Br9IwOuQWnPrFFH X-Received: by 10.36.80.213 with SMTP id m204mr15388332itb.105.1492532110568; Tue, 18 Apr 2017 09:15:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.39.215 with HTTP; Tue, 18 Apr 2017 09:15:09 -0700 (PDT) In-Reply-To: <2DB01F3A9898AE41BB3266315D9FDA2704903D88@S-DC-ESTE03-B.net1.cec.eu.int> References: <2DB01F3A9898AE41BB3266315D9FDA2704903D88@S-DC-ESTE03-B.net1.cec.eu.int> From: Daniel Margolis Date: Tue, 18 Apr 2017 18:15:09 +0200 Message-ID: To: Gerard.DRAPER-GIL@ec.europa.eu Cc: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1145f2fa50671c054d73361f" Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-04 Review 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, 18 Apr 2017 16:15:14 -0000 --001a1145f2fa50671c054d73361f Content-Type: multipart/alternative; boundary=001a1145f2fa44bab5054d7336d0 --001a1145f2fa44bab5054d7336d0 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 6, 2017 at 11:08 AM, wrote: > Some minor comments and a question on policy updates. > > > > _ Section 3.2 MTA-STS Policies, when describing the "mx" parameter, it > says: > > > > "For example, "["mail.example.com", ".example.net"]" indicates that > > mail for this domain might be handled by any MX with a certificate > > valid for a host at "example.com" or "example.net"..." > > Should't it say: " valid for a host at 'mail.example.com'"? > > Yes! Thanks. Fixed in Github and the next draft. > _ Section 3.3 HTTPS Policy Fetching > > > > "When fetching a new policy or updating a policy, the HTTPS endpoint > > MUST present a X.509 certificate which is valid for the "mta-sts" > > host (as described in [RFC6125]), chain to a root CA that is trusted > > by the sending MTA, and be non-expired." > > Maybe it's redundant, but since it explicitly mention non-expired, > > should it also mention not revocated? > Do relevant RFCs for HTTPS specify CRL/OCSP checking? If not--and in practice it varies by implementation, such that some major browsers do not implement one or the other--I would not want to mandate it here, even if it's a good idea. (And I agree it's a good idea in the abstract, but to my very limited knowledge, the state of deployment is haphazard, so it seems a bit risky to require it.) > "If a valid TXT record is found but no policy can be fetched via > > HTTPS, and there is no valid (non-expired) previously-cached policy, > > senders MUST treat the recipient domain as one that has not > > implemented MTA-STS." > > I think that a better option would be to report the recipient and > > continue with opportunistic TLS. > Agreed. Added. > > > _ Section 4 Policy Validation: > > > > "2. That at least one of the policy's "mx" patterns matches at least > > one of the identities presented in the MX's X.509 certificate, as > > descriped in "MX Certificate Validation"." > > > > The last line should say "described in ..." > Fixed. > > > > > _ Section 4.1 MX Certificate Validation: (Same than in section 3.3 about > certificates) > > > > "The certificate presented by the receiving MX MUST chain to a root CA > > that is trusted by the sending MTA and be non-expired. " > > Maybe it's redundant, but since it explicitly mention non-expired, > > should it also mention not revocated? > See above. > > > _ Section 5.1 Policy Application Control Flow > > > > "3. Upon message retries, a message MAY be permanently failed > > following first checking for the presence of a new policy (as > > indicated by the "id" field in the "_mta-sts" TXT record)." > > > > It does not specify the number of retries. A parameter could be added to > > the policy to indicate the number of retries before permanent failure, > > with a default value of X. > This is up to the sending MTA. We mandate a minimum retry count only in order to ensure that cached policies are refreshed before any message is perm-failed. In any reasonable implementation, you probably have some high number of retries with backoff, but I think it's appropriate to leave it to MTA implementors (who already have similar configurations for things like MX lookup failures or server temp-failures. > > > Maybe I missed it, but I didn't see any mention to what to do if > > the id from the TXT record does not match the id from the HTTPS policy. > We have removed the ID from the HTTPS policy, so this cannot happen. :) > > > _ Security considerations: > > > > The first paragraph of Section 6.1 contradicts the second paragraph on > Section 8.3 > > > > "Updating the policy requires that the owner make changes in two > > places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and > > at the corresponding HTTPS endpoint. As a result, recipients should > > thus expect a policy will continue to be used by senders until both > > the HTTPS and TXT endpoints are updated and the TXT record's TTL has > > passed." (1st paragraph Section 6.1) > > > > "This attack is mitigated in part by the ability of a victim domain to > > (at any time) publish a new policy updating the cached, malicious > > policy, though this does require the victim domain to both obtain a > > valid CA-signed certificate and to understand and properly configure > > MTA-STS." (2nd paragraph Section 8.3) > > > > If I am able to publish a new policy, but this policy does not reach > > the senders, then I am not solving the problem. > > > > The whole policy application, update is not clear to me, it seems there is > > a contradiction between the fact, mentioned a couple of times, that a > policy > > can be updated any time, and the resistance to "TLS downgrade" attacks. > Please > > correct me if I'm wrong. > I am not sure I understand you. If you can publish a new policy _and_ it is reachable, you can update any maliciously-published policy. If you cannot publish a new policy and have senders fetch it because the MITM is ongoing, a DoS is possible in any event (someone who can DoS HTTPS fetches can, *at the time*, also DoS SMTP directly). So the only concern here is that a temporary MITM against DNS/HTTPS can become a long-term MITM against SMTP (due to policy caching), which is mitigated by the ability to publish a new policy *once the MITM is over*. Does that address your question? > In the policy updates, it clearly states that updating a policy requires > > updating both the TXT record and the HTTPS policy. > > > > DNS request are usually served by intermediary DNS servers, that will > update > > the cache based on the TTL of records, whereas HTTPS requests will be > usually > > served by the "final" server itself, therefore policy updates will > immediately > > (almost) be deployed. > > > > This creates a dilemma. Using short TTLs to allow frequent policy updates > increases > > the window of vulnerability (policy update requires fetching the TXT > record), > > but using long TTLs reduces the ability to update the policy on-demand. > The DNS TTL is independent of the max_age. Using a reasonably short DNS TTL is probably a good idea--say, something similar to the TTL on the MX records. Using a long policy max_age is also a good idea, for the reason you suggest. So using a short DNS TTL does not introduce any real vulnerability that I can see, does it? > A possible solution could be to unlink the id from the TXT record from the > id of the policy. > > A long TTL (1 month?) can be used to "broadcast" that a domain applies > MTA-STS, and a short > > max-age (hours, minutes?) can be used to facilitate frequent policy > updates. > > > > Finally, regarding the JSON vs pair-of-values, I think that at this stage > the opinion of the > > Implementors (those who will implement it) should prevail, to facilitate > its future acceptance. > > I don't think it makes much difference for domain controllers, who may > deploy it. > I unfortunately don't know everyone's names, so I don't know who is an implementor and who is not. :) I've hopefully made clear that I don't personally have a strong opinion about this, but I hope we can reach a consensus that most people are reasonably comfortable with. > > > > Gerard Draper Gil > > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > > --001a1145f2fa44bab5054d7336d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 6, 2017 at 11:08 AM, <Gerard.DRAPER-GIL@ec.e= uropa.eu> wrote:

Some minor comments and a question on policy updates= .

=C2=A0

_ Section 3.2 MTA-STS Policies, when describing the = "mx" parameter, it says:

=C2=A0

"For example, "["mail.example.com", ".example.net"]" ind= icates that

mail for this domain might be handled by any MX with= a certificate

valid for a host at "example.com" or "example.net"..."

Should't it say: " valid for a host at '= ;mail.example.com= '"?


<= div>Yes! Thanks. Fixed in Github and the next draft.=C2=A0
=C2=A0=

_ Section 3.3 HTTPS Policy Fetching

=C2=A0

"When fetching a new policy or updating a polic= y, the HTTPS endpoint

MUST present a X.509 certificate which is valid for = the "mta-sts"

host (as described in [RFC6125]), chain to a root CA= that is trusted

by the sending MTA, and be non-expired."=

=C2=A0Maybe it's redundant, but since it explici= tly mention non-expired,

should it also mention not revocated?


Do relevant RFCs for HTTPS specify CRL/OC= SP checking? If not--and in practice it varies by implementation, such that= some major browsers do not implement one or the other--I would not want to= mandate it here, even if it's a good idea. =C2=A0

(And I agree it's a good idea in the abstract, but to my very = limited knowledge, the state of deployment is haphazard, so it seems a bit = risky to require it.)
=C2=A0
=

"If a valid TXT record is found but no policy c= an be fetched via

HTTPS, and there is no valid (non-expired) previousl= y-cached policy,

senders MUST treat the recipient domain as one that = has not

implemented MTA-STS."

=C2=A0I think that a better option would be to repor= t the recipient and

continue with opportunistic TLS.


Agreed. Added.
=C2=A0

=C2=A0

_ Section 4 Policy Validation:

=C2=A0

"2.=C2=A0 That at least one of the policy's= "mx" patterns matches at least

=C2=A0=C2=A0=C2=A0=C2=A0 one of the identities prese= nted in the MX's X.509 certificate, as

=C2=A0=C2=A0=C2=A0=C2=A0 descriped in "MX Certi= ficate Validation"."

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

The last line should say "described in ..."= ;


Fixed.=C2=A0
= =C2=A0

=C2=A0

=C2=A0

_ Section 4.1 MX Certificate Validation: (Same than = in section 3.3 about certificates)

=C2=A0

"The certificate presented by the receiving MX = MUST chain to a root CA

that is trusted by the sending MTA and be non-expire= d. "

=C2=A0Maybe it's redundant, but since it explici= tly mention non-expired,

should it also mention not revocated?


See above.=C2=A0
=C2=A0

=C2=A0

_ Section 5.1 Policy Application Control Flow=

=C2=A0

"3. Upon message retries, a message MAY be perm= anently failed

=C2=A0=C2=A0=C2=A0 following first checking for the = presence of a new policy (as

=C2=A0=C2=A0=C2=A0 indicated by the "id" f= ield in the "_mta-sts" TXT record)."

=C2=A0

It does not specify the number of retries. A paramet= er could be added to

the policy to indicate the number of retries before = permanent failure,

with a default value of X.


This is up to the sending MTA. We mandate a minimum = retry count only in order to ensure that cached policies are refreshed befo= re any message is perm-failed. In any reasonable implementation, you probab= ly have some high number of retries with backoff, but I think it's appr= opriate to leave it to MTA implementors (who already have similar configura= tions for things like MX lookup failures or server temp-failures.=C2=A0
=C2=A0

<= u>

=C2=A0

Maybe I missed it, but I didn't see any mention = to what to do if

the id from the TXT record does not match the id fro= m the HTTPS policy.


We have= removed the ID from the HTTPS policy, so this cannot happen. :)=C2=A0
=C2=A0

=C2=A0

_ Security considerations:

=C2=A0

The first paragraph of Section 6.1 contradicts the s= econd paragraph on Section 8.3

=C2=A0

=C2=A0 "Updating the policy requires that the o= wner make changes in two

=C2=A0=C2=A0 places: the "_mta-sts" TXT re= cord in the Policy Domain's DNS zone and

=C2=A0=C2=A0 at the corresponding HTTPS endpoint.=C2= =A0 As a result, recipients should

=C2=A0=C2=A0 thus expect a policy will continue to b= e used by senders until both

=C2=A0=C2=A0 the HTTPS and TXT endpoints are updated= and the TXT record's TTL has

=C2=A0=C2=A0 passed." (1st paragraph Section 6.= 1)

=C2=A0=C2=A0

=C2=A0=C2=A0"This attack is mitigated in part b= y the ability of a victim domain to

=C2=A0=C2=A0 (at any time) publish a new policy upda= ting the cached, malicious

=C2=A0=C2=A0 policy, though this does require the vi= ctim domain to both obtain a

=C2=A0=C2=A0 valid CA-signed certificate and to unde= rstand and properly configure

=C2=A0=C2=A0 MTA-STS." (2nd paragraph Section 8= .3)

=C2=A0

=C2=A0=C2=A0 If I am able to publish a new policy, b= ut this policy does not reach

=C2=A0=C2=A0 the senders, then I am not solving the = problem.

=C2=A0

The whole policy application, update is not clear to= me, it seems there is

a contradiction between the fact, mentioned a couple= of times, that a policy

can be updated any time, and the resistance to "= ;TLS downgrade" attacks. Please

correct me if I'm wrong.


I am not sure I understand you. If you can publish= a new policy _and_ it is reachable, you can update any maliciously-publish= ed policy. If you cannot publish a new policy and have senders fetch it bec= ause the MITM is ongoing, a DoS is possible in any event (someone who can D= oS HTTPS fetches can, at the time, also DoS SMTP directly). So the o= nly concern here is that a temporary MITM against DNS/HTTPS can become a lo= ng-term MITM against SMTP (due to policy caching), which is mitigated by th= e ability to publish a new policy once the MITM is over. Does that a= ddress your question?

=C2=A0

In the policy updates, it clearly states that updati= ng a policy requires

updating both the TXT record and the HTTPS policy. <= u>

=C2=A0

DNS request are usually served by intermediary DNS s= ervers, that will update

the cache based on the TTL of records, whereas HTTPS= requests will be usually

served by the "final" server itself, there= fore policy updates will immediately

(almost) be deployed.

=C2=A0

This creates a dilemma. Using short TTLs to allow fr= equent policy updates increases

the window of vulnerability (policy update requires = fetching the TXT record),

but using long TTLs reduces the ability to update th= e policy on-demand.


The DNS= TTL is independent of the max_age. Using a reasonably short DNS TTL is pro= bably a good idea--say, something similar to the TTL on the MX records. Usi= ng a long policy max_age is also a good idea, for the reason you suggest.= =C2=A0

So using a short DNS TTL does not introduce= any real vulnerability that I can see, does it?
=C2=A0

A possible solution could be to unlink the id from t= he TXT record from the id of the policy.

A long TTL (1 month?) can be used to "broadcast= " that a domain applies MTA-STS, and a short

max-age (hours, minutes?) can be used to facilitate = frequent policy updates.

=C2=A0

Finally, regarding the JSON vs pair-of-values,=C2=A0= I think that at this stage the opinion of the

Implementors (those who will implement it) should pr= evail, to facilitate its future acceptance.

I don't think it makes much difference for domai= n controllers, who may deploy it.


I unfortunately don't know everyone's names, so I don't = know who is an implementor and who is not. :)=C2=A0

I've hopefully made clear that I don't personally have a strong o= pinion about this, but I hope we can reach a consensus that most people are= reasonably comfortable with.=C2=A0
=C2=A0

=C2=A0

=C2=A0

Gerard Draper Gil

=C2=A0


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


--001a1145f2fa44bab5054d7336d0-- --001a1145f2fa50671c054d73361f 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDqXioOuuyoH/zr B8ccksNpZ6boIdi6oeA3TjrnFsoGNTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA0MTgxNjE1MTFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAQ95nDALL12vU2yIIlyyQruNS71hNSyaC qfqfjFIvoM0KBU4rtyrx0SyLtoQIPeCsUFD0oKbrByhNcxyQrZnJkR/pX8FbgWw6kpIUJzGDsNrn LRJvXoY7gcisqSnFnw/dUbpfFNjhwObhvJTASDZISr5eLjg/dho30EreHRwN8AGULsjyaDwWX+4L ipYbHKRUVHl7/BVRDF5wgxssw6rDQgrRBwxTQnDG/+IyX5IMiQd2Wl0GamEWYoPD+aqpQvlWsQdR jUsa+JMM0l2qLe2/vAAmJrCcAdKsqNn2C2QS7BgMD1reZvQOrTNX5zuPvc9Uq/iFu+boUMIpTmZe LIV/Jw== --001a1145f2fa50671c054d73361f-- From nobody Tue Apr 18 09:23: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 B8E19128ACA for ; Tue, 18 Apr 2017 09:23:05 -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, HTML_MESSAGE=0.001, 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 DWythtEcmhxR for ; Tue, 18 Apr 2017 09:23:04 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 56FDE126B6E for ; Tue, 18 Apr 2017 09:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1492532583; d=isode.com; s=june2016; i=@isode.com; bh=akPsf/CIaKAjZID8fAq8KWF/4ndjMQTQ78VajTCo+2s=; 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=qGBkwuoznfGcjs13sXggvxQR4NiTJWTvI0hFIZZ5r1Pr4/dCal7GEc8DYqhMV/cjCXs2T+ /iTry7JEROtOqknsiIXRUjZVEA1I6MI1rG8jUxQKcW6qEVjH+o0BDL2Z0dvd5wVsR7yqLQ iXPVEm3r6mRY3tFlUU9jmDjFidTd6Ms=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 18 Apr 2017 17:23:03 +0100 To: Daniel Margolis , Gerard.DRAPER-GIL@ec.europa.eu References: <2DB01F3A9898AE41BB3266315D9FDA2704903D88@S-DC-ESTE03-B.net1.cec.eu.int> Cc: uta@ietf.org From: Alexey Melnikov Message-ID: <5c361c89-907b-ff65-8a11-8df08e0e46af@isode.com> Date: Tue, 18 Apr 2017 17:23:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------0F0677EDD6498EC0D0B2E658" Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-04 Review 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, 18 Apr 2017 16:23:05 -0000 --------------0F0677EDD6498EC0D0B2E658 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Daniel, On 18/04/2017 17:15, Daniel Margolis wrote: > On Thu, Apr 6, 2017 at 11:08 AM, > wrote: > _ Section 3.3 HTTPS Policy Fetching > > "When fetching a new policy or updating a policy, the HTTPS endpoint > > MUST present a X.509 certificate which is valid for the "mta-sts" > > host (as described in [RFC6125]), chain to a root CA that is trusted > > by the sending MTA, and be non-expired." > > Maybe it's redundant, but since it explicitly mention non-expired, > > should it also mention not revocated? > > > Do relevant RFCs for HTTPS specify CRL/OCSP checking? If not--and in > practice it varies by implementation, such that some major browsers do > not implement one or the other--I would not want to mandate it here, > even if it's a good idea. > > (And I agree it's a good idea in the abstract, but to my very limited > knowledge, the state of deployment is haphazard, so it seems a bit > risky to require it.) RFC 5280 mention it. I think you need to make it clear that checking OCSP is not prohibited here. (Maybe say "MAY use OCSP to check for revocation" or similar.) Best Regards, Alexey --------------0F0677EDD6498EC0D0B2E658 Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable

Hi Daniel,


On 18/04/2017 17:15, Daniel Margolis wrote:
On Thu, Apr 6, 2017 at 11:08 AM, &l= t;Gerard.DRAPER-GIL@ec.europa.eu> wrote:

_ Section 3.3 HTTPS Policy Fetching

=A0

"When fetching a new policy or updating a policy, the HTTPS endpoint

MUST present a X.509 certificate which is valid for the "mta-sts"

host (as described in [RFC6125]), chain to a root CA that is trusted

by the sending MTA, and be non-expired."

=A0Maybe it's redundant, but since it explicitly mention non-expired,

should it also mention not revocated?


Do relevant RFCs for HTTPS specify CRL/OCSP checking? If not--and in practice it varies by implementation, such that some major browsers do not implement one or the other--I would not want to mandate it here, even if it's a good idea. =A0

(And I agree it's a good idea in the abstract, but to my very limited knowledge, the state of deployment is haphazard, so it seems a bit risky to require it.)

RFC 5280 mention it. I think you need to make it clear that checking OCSP is not prohibited here. (Maybe say "MAY use OCSP to check for revocation" or similar.)

Best Regards,
Alexey


--------------0F0677EDD6498EC0D0B2E658-- From nobody Wed Apr 19 04:06: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 014D21294A5 for ; Wed, 19 Apr 2017 04:06: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 syvtWs9ncnfy for ; Wed, 19 Apr 2017 04:06:04 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5F76E129489 for ; Wed, 19 Apr 2017 04:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1492599963; d=isode.com; s=june2016; i=@isode.com; bh=4Dr288JgOSePKV5HzK+CmGcfNHJ0bdnTHytGyVA1B+c=; 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=eOzl2v8mHcw1Ai066Ok1C3gpGab6MqwGRVsTXa4KkIWOZq5WQYeuqhsRZTJiYDhFk+wZql LPqKxqz8KOPf7iXQkR2lzSuKhyBq27YAzj/G96larCMTjMtBGNiXLC3FM3WBRM9YKQSmOq 1wxTKWLEuZVlR4Q2K8JDMzHFNTdtKHs=; 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, 19 Apr 2017 12:06:03 +0100 From: Alexey Melnikov To: "uta@ietf.org" Message-ID: Date: Wed, 19 Apr 2017 12:05:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Uta] Review of draft-ietf-uta-mta-sts-04 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, 19 Apr 2017 11:06:06 -0000 Hi, Below is my early "AD review" of the document. I think it is in pretty good shape and is ready for WG Last Call (I am Ok with the question of JSON versa something else be settled during or after WGLC.) 1) In 1.1: o Policy Domain: The domain for which an MTA-STS Policy is defined. This is the next-hop domain; when sending mail to "alice@example.com" this would ordinarly be "example.com", but this may be overriden by explicit routing rules (as described in "Policy Selection for Smart Hosts"). Nit: This needs an internal section reference. I think there was another place in the document when an internal section number is not mentioned. 2) In 3.1: sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1" %x53 %x76 %x31 Do you intend for this to be matched case-sensitively? What you wrote above is that "v" is case-insensitive, but "STSv1" is. 3) Section 3.2 says that unrecognized fields are to be ignored, so you need to update ABNF in 3.1 to make it clear. Current ABNF: sts-text-record = sts-version *WSP %x3B *WSP sts-id [%x3B] sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1" %x53 %x76 %x31 sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT) I suggest something like the following (this implies that position of the first 2 fields is fixed, extensions at the end. If you prefer that any fields are in any order (other than the version), I can update the ABNF): sts-text-record = sts-version *WSP field-delim *WSP sts-id [field-delim [sts-extensions]] field-delim = %x3B sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1" %x53 %x76 %x31 sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT) sts-extensions = sts-extension *(field-delim sts-extension) [field-delim] ; Extension fields at the end in any order sts-extension = sts-ext-name *WSP "=" *WSP sts-ext-value sts-ext-name = (ALPHA / DIGIT) *31(ALPHA / DIGIT / "_" / "-" / ".") sts-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) ; like esmtp-value from RFC 5321, but doesn't allow ";". ; So basically any CHAR excluding "=", ";", SP, and control ; characters. 4) In 3.2: Should "SHOULD ignore unrecognized fields" be a MUST? I.e., why would it not be Ok to ignore unrecognized fields? 5) In 3.3: RFC 6125 use needs more details, because you need to specify answers to every question in section 3 of RFC 6125. In particular you should say that when checking certificates, you only use DNS-ID and CN-ID (SRV-ID and URI-ID are not used) and that you allow wildcards in them. 6) Last para on page 7: this is also true in RFC 6125. 7) In 5.1, last para: I think you mean that if there are too many failures to deliver when using MTA-STS, regular SMTP rules for generating a bounce apply? I think this needs rewording to say that. 8) If you want to allow for extensibility, you probably need an IANA registry of fields allowed, so that developers can find them easily. I can help with some text. 9) On page 13: I think pseudocode should make it clear that you retrieve DNS-ID SAN. Best Regards, Alexey P.S. I might have a couple of extra items, but I need to double check a few things first. From nobody Sat Apr 22 06:12: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 5B0C81294BE for ; Sat, 22 Apr 2017 06:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] 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 pQHqBAAfcwsb for ; Sat, 22 Apr 2017 06:12:27 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9890D1294AF for ; Sat, 22 Apr 2017 06:12:25 -0700 (PDT) Received: from mbpdejulienelie.home ([92.170.5.52]) by mwinf5d03 with ME id BRCN1v00q17Lgi403RCPAW; Sat, 22 Apr 2017 15:12:24 +0200 X-ME-Helo: mbpdejulienelie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Sat, 22 Apr 2017 15:12:24 +0200 X-ME-IP: 92.170.5.52 References: <20170422043754.97B4CB80E5A__43187.9896474586$1492835902$gmane$org@rfc-editor.org> To: ietf-nntp@lists.eyrie.org, uta@ietf.org From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ X-Forwarded-Message-Id: <20170422043754.97B4CB80E5A__43187.9896474586$1492835902$gmane$org@rfc-editor.org> Message-ID: <1813db57-0fe3-ace7-2610-44b173e2630d@trigofacile.com> Date: Sat, 22 Apr 2017 15:12:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170422043754.97B4CB80E5A__43187.9896474586$1492835902$gmane$org@rfc-editor.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Uta] New RFC 8143 on Using TLS with NNTP 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: Sat, 22 Apr 2017 13:12:29 -0000 Hi all, RFC 8143 has just been published. It updates RFC 4642 notably by modernizing the NNTP usage of TLS to be consistent with TLS best current practices described in BCP 195 (RFC 7525). https://tools.ietf.org/html/rfc8143 Thanks to all involved, especially folks in UTA and (concluded) NNTP working groups. -- Julien ÉLIE -------- Message transféré -------- Date : Fri, 21 Apr 2017 21:37:54 -0700 (PDT) A new Request for Comments is now available in online RFC libraries. RFC 8143 Title: Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) Author: J. Elie Status: Standards Track Stream: IETF Date: April 2017 Pages: 13 Characters: 28484 Updates: RFC 4642 I-D Tag: draft-elie-nntp-tls-recommendations-05.txt URL: https://www.rfc-editor.org/info/rfc8143 DOI: 10.17487/RFC8143 This document provides recommendations for improving the security of the Network News Transfer Protocol (NNTP) when using Transport Layer Security (TLS). It modernizes the NNTP usage of TLS to be consistent with TLS best current practices. This document updates RFC 4642. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. From nobody Sat Apr 22 10:11:21 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 43A271294E2 for ; Sat, 22 Apr 2017 10:11:16 -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 rb3lW_lx6CPO for ; Sat, 22 Apr 2017 10:11:14 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 3D2911294E1 for ; Sat, 22 Apr 2017 10:11:14 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id 70so4310121ita.0 for ; Sat, 22 Apr 2017 10:11:14 -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=bI6IswmyLUGdXzvqExrlcn2aiO2imTbdM93aw/0yTmY=; b=AtG+JcOYfjZoHg+wbSrxF+MpdQAT7cENTpUi6soiBTDwxF8D1hAcxBPs+0hteg3Udk VFOhXQ4JDvcG2kdPGTpveS4PqDAecFO8gF7T7MoLQMjCvBS1gROVFBxXSAfHcuclrhU3 BVPOoGa+1gLJyZFU6CC+1+Mlyl3c+GZr1Nc2T4Q0ehBvInOyS/BNnTizMtLfMqag1v65 3RvYNFmoIus300Gd7UaEl9H9cp7tMseVj9q1ZNRClCja3EqgN6D/n4/J7XK1lCGlBLzP 9283JXtyEFphx7KEZTm85cKszUJCM1W2A22FvpUma/RqDpUySCBVerkTP6AJEESEf8jk 3kqg== 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=bI6IswmyLUGdXzvqExrlcn2aiO2imTbdM93aw/0yTmY=; b=TFdr6TcZHOddk5YKYcpP6frFgALSAR0mklKEwBl56GOqEujdNnIDJBlcF+GPP7E2ZZ iTjxQBedp7GYh/P7czsdM0jrbqr4ZWHht/8COrUO0mlWkHsbY3se7ohFRqukJgQ286LV rKU7eQLPOV9wLGAORNKCMcapax4MGGFDlgFC1K/iLKWZXgH/x8Q69JlK8msMTFPpye6G jSGknCemyaXRMxFjI6oTWHnvuoh5NO1X9zJ41NfummB/4tb0cidCLSXbwt7hmPehfhHa lkE1ua3ciehGI9fE0w1+1W3ng5Kr9k3o4FB6kwpJuxaD7+Qj02IZUbVIBJqAQrxYOQuQ Fzuw== X-Gm-Message-State: AN3rC/4JOyUwPMCahD96T6J2q5faoeLHcRSYxOyrPk3QgUQGCex0ix+U +hQ2pDVeseaHsFFjijj/5bZb6mk1ewcM X-Received: by 10.36.152.196 with SMTP id n187mr4943716itd.28.1492881073063; Sat, 22 Apr 2017 10:11:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.111.11 with HTTP; Sat, 22 Apr 2017 10:11:11 -0700 (PDT) In-Reply-To: <5c361c89-907b-ff65-8a11-8df08e0e46af@isode.com> References: <2DB01F3A9898AE41BB3266315D9FDA2704903D88@S-DC-ESTE03-B.net1.cec.eu.int> <5c361c89-907b-ff65-8a11-8df08e0e46af@isode.com> From: Daniel Margolis Date: Sat, 22 Apr 2017 19:11:11 +0200 Message-ID: To: Alexey Melnikov Cc: Gerard.DRAPER-GIL@ec.europa.eu, uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c05e9a21827f4054dc4761f" Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-04 Review 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: Sat, 22 Apr 2017 17:11:16 -0000 --94eb2c05e9a21827f4054dc4761f Content-Type: multipart/alternative; boundary=94eb2c05e9a20dd2b5054dc47666 --94eb2c05e9a20dd2b5054dc47666 Content-Type: text/plain; charset=UTF-8 Thanks for the pointer. Yes, I of course have no objections to checking CRL or OCSP. Given the mixed state of deployments among browsers, it merely seems worrisome to me to *require* that. MAY seems like a good clarification to have here. On Tue, Apr 18, 2017 at 6:23 PM, Alexey Melnikov wrote: > Hi Daniel, > > On 18/04/2017 17:15, Daniel Margolis wrote: > > On Thu, Apr 6, 2017 at 11:08 AM, wrote: > > > _ Section 3.3 HTTPS Policy Fetching >> >> >> >> "When fetching a new policy or updating a policy, the HTTPS endpoint >> >> MUST present a X.509 certificate which is valid for the "mta-sts" >> >> host (as described in [RFC6125]), chain to a root CA that is trusted >> >> by the sending MTA, and be non-expired." >> >> Maybe it's redundant, but since it explicitly mention non-expired, >> >> should it also mention not revocated? >> > > Do relevant RFCs for HTTPS specify CRL/OCSP checking? If not--and in > practice it varies by implementation, such that some major browsers do not > implement one or the other--I would not want to mandate it here, even if > it's a good idea. > > (And I agree it's a good idea in the abstract, but to my very limited > knowledge, the state of deployment is haphazard, so it seems a bit risky to > require it.) > > > RFC 5280 mention it. I think you need to make it clear that checking OCSP > is not prohibited here. (Maybe say "MAY use OCSP to check for revocation" > or similar.) > > Best Regards, > Alexey > > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > > --94eb2c05e9a20dd2b5054dc47666 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the pointer.=C2=A0

Yes, I of= course have no objections to checking CRL or OCSP. Given the mixed state o= f deployments among browsers, it merely seems worrisome to me to require= =C2=A0that. MAY seems like a good clarification to have here.

On Tue, Apr 18,= 2017 at 6:23 PM, Alexey Melnikov <alexey.melnikov@isode.com&g= t; wrote:
=20 =20 =20

Hi Daniel,


On 18/04/2017 17:1= 5, Daniel Margolis wrote:
On Thu, Apr 6, 2017 at 11:08 AM, &= lt;Gera= rd.DRAPER-GIL@ec.europa.eu> wrote:

_ Section 3.3 HTTPS Policy Fetching

=C2=A0

"When fetching a new policy o= r updating a policy, the HTTPS endpoint

MUST present a X.509 certificate which is valid for the "mta-sts"

host (as described in [RFC6125]), chain to a root CA that is trusted

by the sending MTA, and be non-expired."

=C2=A0Maybe it's redundant, bu= t since it explicitly mention non-expired,

should it also mention not revocated?


Do relevant RFCs for HTTPS specify CRL/OCSP checking? If not--and in practice it varies by implementation, such that some major browsers do not implement one or the other--I would not want to mandate it here, even if it's = a good idea. =C2=A0

(And I agree it's a good idea in the abstract, but to my very limited knowledge, the state of deployment is haphazard, so it seems a bit risky to require it.)

 RFC 5280 mention it. I think you need to make it clear that checking OCSP is not prohibited here. (Maybe say "MAY use OCSP to check for revocation" or similar.)

Best Regards,
Alexey



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


--94eb2c05e9a20dd2b5054dc47666-- --94eb2c05e9a21827f4054dc4761f 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 K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCGBSXooxsJnbGD nNXwPuyxkgNJoA+RTvGaGabP5EyFMjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA0MjIxNzExMTNaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAFKIxWg8LRE1bacHIbibhWKKLAkoekcCJ FAajpcHbGfNz92l3E3dYUehhRm7pDF7h8K/KfL1v8/g/v6mI4uagvzDmHBrCHjNfiieVlivHba1v EiAnT/9Mz+zKxArSkeHkJMj5OEEtiSCLAiBXKxP3wWrGE/iJmgrUTMO3aeEcgneq/qYLwcp8bagj eOjOVTYEv7eSwx0kXrXQS+XkBzHbimqbj5Xd6S4emRMIkAtS9Xztj/9z/iQ8XwfKJhkED1GM4nIF mWLbxxFGlUfZpiL9PeWFOcNajMXX1KX83uRScDla3DWSWpKHlOP9hNmjxr6SWYldGbRwXyU9YeOL Tn0E2Q== --94eb2c05e9a21827f4054dc4761f-- From nobody Sat Apr 22 10:35: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 C793A1294FE for ; Sat, 22 Apr 2017 10:35:31 -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 rildOGFsKsFe for ; Sat, 22 Apr 2017 10:35:29 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 0AE5F1294F7 for ; Sat, 22 Apr 2017 10:35:28 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id k87so149398685ioi.0 for ; Sat, 22 Apr 2017 10:35:28 -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=8eo+1GbALeLis8+GNJ5viXKmiz34i6BeQrdfoU2rico=; b=Jsvswyf5UKrWTRMXaOSaryOJlhnDwKJhO4M2yL2q9pPePDh9nPr5tSEWctxI2gwAkW fpWySpezjThxkvRO+Y6x5JMxApCd+9PwyBrfIuvDVYfcxp679PTKQSNA2SwmAhZ3Us3X MiVE/M6EDFW+GTjGd2RNlT2nUNfJb8fl2yZguBP6km9UGbF25bLr4r4f6DpdU7BeO5sP 1yhvfRg5BouD5fSl2O0Erq+05n/qWduLDLTyqx00v/SfPlFyrBhmzUZpgMVKYO8IG/2e JZvMoUn2k9xGd8n4XBoiiBOCCUlyW5Ymovn7fQS4PjwkMnKNHNdUyCQR1mmprlXxNl/B VIeQ== 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=8eo+1GbALeLis8+GNJ5viXKmiz34i6BeQrdfoU2rico=; b=XWmLvEw77LWgpecLlkZ5DDIK4GdxrviSiRRmwACKqfLlhziK7g1Ped2w01P/yw6ctu WPJlaKQNNPazHJp1N3vcpxi3uStLDcISrv+GDDClJqMHylHpIiZSREUoGK7y9bO4wlYM DoWof/ex/DKlogv9bEsdghb13lfTkqe9UdrG2MBumD3FDS3QhadqOpVLTmrw1icOs+sI 2T2BxyjK1/dAfCIl0V4DCJfiYtTJjsg/bUk4wOpK71LvjgMUlPZ+hh/CtV6V70/bwsiy tRcM1rmfJ9Pp3362Df+PWBG22dlNPsrKtbTTpb9JdsTZ3LXopQWpyJyCVPiddTpTA5Ew jWwQ== X-Gm-Message-State: AN3rC/6CIdQ1hh7K/Roga1NJJok2aD/6bPDS+X5r9fIFV5y+diXKNafS 0ZZUWtvPiHHRGIfJy3hcNFjJGzAQMiMq8swVGg== X-Received: by 10.107.170.163 with SMTP id g35mr2583049ioj.101.1492882527619; Sat, 22 Apr 2017 10:35:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.111.11 with HTTP; Sat, 22 Apr 2017 10:35:26 -0700 (PDT) In-Reply-To: References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> From: Daniel Margolis Date: Sat, 22 Apr 2017 19:35:26 +0200 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11426222cace0b054dc4ccc4" Archived-At: Subject: Re: [Uta] back to smtp-sts-04 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: Sat, 22 Apr 2017 17:35:32 -0000 --001a11426222cace0b054dc4ccc4 Content-Type: multipart/alternative; boundary=001a11426222c073bc054dc4cc49 --001a11426222c073bc054dc4cc49 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 6, 2017 at 4:11 PM, Viktor Dukhovni wrote: > > > On Apr 6, 2017, at 9:17 AM, Brotman, Alexander < > Alexander_Brotman@comcast.com> wrote: > > > > With regard to the JSON policy (though that's STS, not TLSRPT). > > It's a small file, which given the JSON requirement, should > > be properly formatted. I would think this should be relatively > > easy to parse with standard C string functions. > > Here are the line counts for the "*.[ch]" files from what appears > to be a popular JSON parsing API for C: > > $ git clone https://github.com/json-c/json-c.git > $ cd json-c > $ wc -l *.[ch] | sort -n > 11 strdup_compat.h > 19 json_inttypes.h > 20 json_c_version.c > 22 json_c_version.h > 25 random_seed.h > 26 libjson.c > 31 math_compat.h > 34 json.h > 35 bits.h > 45 vasprintf_compat.h > 55 json_object_private.h > 63 arraylist.h > 71 debug.h > 83 debug.c > 89 json_util.h > 91 json_visit.h > 114 printbuf.h > 115 json_pointer.h > 133 json_visit.c > 143 arraylist.c > 154 printbuf.c > 168 json_object_iterator.c > 208 json_tokener.h > 238 random_seed.c > 239 json_object_iterator.h > 326 json_pointer.c > 326 json_util.c > 366 linkhash.h > 690 linkhash.c > 901 json_object.h > 978 json_tokener.c > 1195 json_object.c > 7014 total > > That does not jive with relatively easy to parse... > > JSON supports comments, elements that are integers, strings, > arrays or associative arrays (nested JSON objects). JSON > strings are UTF-8 and allow embedded NUL octets. > > Your JSON reference is to the obsolete RFC4627, the non-obsolete > reference is RFC7159. > Thanks. Fixed. > Speaking of the policy, what should be done if the HTTPS policy > contains multiple JSON objects, no JSON objects, or broken JSON? > "If a valid TXT record is found but no policy can be fetched via HTTPS, and there is no valid (non-expired) previously-cached policy, senders MUST treat the recipient domain as one that has not implemented MTA-STS." If you can't parse it, it's not a valid policy, so you fall back to cached-non-expired or none. Same as if there's an HTTP timeout, an HTTPS cert validation error, etc. > Is there a size limit a parser can reasonably impose on the policy > data to avoid resource exhaustion parsing absurdly large JSON input? > Could we say for example that a valid STSv1 JSON object must fit in > 16K bytes or 64K bytes? > It's certainly very reasonable to do so in an implementation, to be sure. Since we already have this text on timeouts: "Senders MAY impose a timeout on the HTTPS GET to avoid long delays imposed by attempted policy updates. A suggested timeout is one minute; policy hosts SHOULD respond to requests with a complete policy body within that timeout" we could also say the same for a maximum size on the response. As you say, even a very small limit like 64Kb is "absurdly large", so I am not convinced we need to specify a hard limit (in the sense that a very conservative--from the perspective of RAM usage--limit still provides a huge buffer for valid policies!). I have added some text to the above paragraph. > How does a domain get rid of its STS policy? I thought we had discussed > using "max_age = 0" for this, which after being in place long enough to > assure that all previously cached policies have expired can be removed. > Or might just "404" suffice? > Yes, I remember discussing this. But I am not sure such a mechanism is needed. 1. Domains can publish a "report" policy (with or without a TLSRPT record!) with a low expiration 2. They have to keep this policy published until "last time the old policy was published" + "old policy's max_age" The knock-on effects of this are fairly limited: a) extra record in the sender's policy cache, and b) maybe some extra CPU cycles spent on starting any reporting path before discovering there's no TLSRPT record to report to. Let's consider in comparison an implementation with a special "opt out" mechanism (however it works). Would it avoid the above two knock-on effects, or be easier to publish? I think for publishing (i.e. the duration required in #2 above) the answer is "no"; obviously the "opt out" must be published in the same way (i.e. for the same duration) as any new policy. Similarly, because it must be published as (effectively) a new policy, senders must still cache it (or else hit the endpoint every time), so we're still talking about knock-on effect (a).* So I think the only argument for adding an explicit opt-out--which I think is otherwise extra complexity to be avoided--is to avoid (b), i.e., to avoid any cost of a "report-only" policy which has no reporting endpoint defined. And I suspect that cost is low, and does not justify even the minimal additional complexity of an "opt out". But I may be missing something here, as usual. ;) * In fact, you could design a behavior where the TXT record indicates if the new policy is an "opt out" one or not, such that senders who do not have a cached policy for the domain can be told via DNS-only not to lookup the new policy, but senders who do have a policy MUST look it up to determine if it is an authenticated "opt out." But the extra complexity here is high--making the system quite hard to reason about by introducing a new variant of the lookup flow--with limited real value. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a11426222c073bc054dc4cc49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 6, 2017 at 4:11 PM, Viktor Dukhovni <<= a href=3D"mailto:ietf-dane@dukhovni.org" target=3D"_blank">ietf-dane@dukhov= ni.org> wrote:

> On Apr 6, 2017, at 9:17 AM, Brotman, Alexander <Alexander_Brotman@comcast.com> wr= ote:
>
> With regard to the JSON policy (though that's STS, not TLSRPT). > It's a small file, which given the JSON requirement, should
> be properly formatted.=C2=A0 I would think this should be relatively > easy to parse with standard C string functions.

Here are the line counts for the "*.[ch]" files from what appears=
to be a popular JSON parsing API for C:

$ git clone https://github.com/json-c/json-c.git
$ cd json-c
$ wc -l *.[ch] | sort -n
=C2=A0 =C2=A0 =C2=A0 11 strdup_compat.h
=C2=A0 =C2=A0 =C2=A0 19 json_inttypes.h
=C2=A0 =C2=A0 =C2=A0 20 json_c_version.c
=C2=A0 =C2=A0 =C2=A0 22 json_c_version.h
=C2=A0 =C2=A0 =C2=A0 25 random_seed.h
=C2=A0 =C2=A0 =C2=A0 26 libjson.c
=C2=A0 =C2=A0 =C2=A0 31 math_compat.h
=C2=A0 =C2=A0 =C2=A0 34 json.h
=C2=A0 =C2=A0 =C2=A0 35 bits.h
=C2=A0 =C2=A0 =C2=A0 45 vasprintf_compat.h
=C2=A0 =C2=A0 =C2=A0 55 json_object_private.h
=C2=A0 =C2=A0 =C2=A0 63 arraylist.h
=C2=A0 =C2=A0 =C2=A0 71 debug.h
=C2=A0 =C2=A0 =C2=A0 83 debug.c
=C2=A0 =C2=A0 =C2=A0 89 json_util.h
=C2=A0 =C2=A0 =C2=A0 91 json_visit.h
=C2=A0 =C2=A0 =C2=A0114 printbuf.h
=C2=A0 =C2=A0 =C2=A0115 json_pointer.h
=C2=A0 =C2=A0 =C2=A0133 json_visit.c
=C2=A0 =C2=A0 =C2=A0143 arraylist.c
=C2=A0 =C2=A0 =C2=A0154 printbuf.c
=C2=A0 =C2=A0 =C2=A0168 json_object_iterator.c
=C2=A0 =C2=A0 =C2=A0208 json_tokener.h
=C2=A0 =C2=A0 =C2=A0238 random_seed.c
=C2=A0 =C2=A0 =C2=A0239 json_object_iterator.h
=C2=A0 =C2=A0 =C2=A0326 json_pointer.c
=C2=A0 =C2=A0 =C2=A0326 json_util.c
=C2=A0 =C2=A0 =C2=A0366 linkhash.h
=C2=A0 =C2=A0 =C2=A0690 linkhash.c
=C2=A0 =C2=A0 =C2=A0901 json_object.h
=C2=A0 =C2=A0 =C2=A0978 json_tokener.c
=C2=A0 =C2=A0 1195 json_object.c
=C2=A0 =C2=A0 7014 total

That does not jive with relatively easy to parse...

JSON supports comments, elements that are integers, strings,
arrays or associative arrays (nested JSON objects).=C2=A0 JSON
strings are UTF-8 and allow embedded NUL octets.

Your JSON reference is to the obsolete RFC4627, the non-obsolete
reference is RFC7159.

Thanks. Fixed.
=C2=A0
Speaking of the policy, what should be done if the HTTPS policy
contains multiple JSON objects, no JSON objects, or broken JSON?

=C2=A0 =C2=A0"If a valid TXT record is = found but no policy can be fetched via
=C2=A0 =C2=A0HTTPS, and th= ere is no valid (non-expired) previously-cached policy,
=C2=A0 = =C2=A0senders MUST treat the recipient domain as one that has not
=C2=A0 =C2=A0implemented MTA-STS."

If = you can't parse it, it's not a valid policy, so you fall back to ca= ched-non-expired or none.

Same as if there's a= n HTTP timeout, an HTTPS cert validation error, etc.=C2=A0
=C2=A0=
Is there a size limit a parser can reasonably impose on the policy
data to avoid resource exhaustion parsing absurdly large JSON input?
Could we say for example that a valid STSv1 JSON object must fit in
16K bytes or 64K bytes?

It's certai= nly very reasonable to do so in an implementation, to be sure. Since we alr= eady have this text on timeouts:

=C2=A0 "Send= ers MAY impose a timeout on the HTTPS GET to avoid long delays
= =C2=A0 =C2=A0imposed by attempted policy updates.=C2=A0 A suggested timeout= is one
=C2=A0 =C2=A0minute; policy hosts SHOULD respond to reque= sts with a complete
=C2=A0 =C2=A0policy body within that timeout&= quot;

we could also say the same for a maximum siz= e on the response. As you say, even a very small limit like 64Kb is "a= bsurdly large", so I am not convinced we need to specify a hard limit = (in the sense that a very conservative--from the perspective of RAM usage--= limit still provides a huge buffer for valid policies!).=C2=A0
I have added some text to the above paragraph.
=C2= =A0
How does a domain get rid of its STS policy?=C2=A0 I thought we had discuss= ed
using "max_age =3D 0" for this, which after being in place long e= nough to
assure that all previously cached policies have expired can be removed.
Or might just "404" suffice?

= Yes, I remember discussing this. But I am not sure such a mechanism is need= ed.=C2=A0

1. Domains can publish a "report&qu= ot; policy (with or without a TLSRPT record!) with a low expiration
2. They have to keep this policy published until "last time the old= policy was published" + "old policy's max_age"

The knock-on effects of this are fairly limited: a) extra = record in the sender's policy cache, and b) maybe some extra CPU cycles= spent on starting any reporting path before discovering there's no TLS= RPT record to report to.=C2=A0

Let's consider = in comparison an implementation with a special "opt out" mechanis= m (however it works). Would it avoid the above two knock-on effects, or be = easier to publish?

I think for publishing (i.e. th= e duration required in #2 above) the answer is "no"; obviously th= e "opt out" must be published in the same way (i.e. for the same = duration) as any new policy. Similarly, because it must be published as (ef= fectively) a new policy, senders must still cache it (or else hit the endpo= int every time), so we're still talking about knock-on effect (a).*=C2= =A0

So I think the only argument for adding an exp= licit opt-out--which I think is otherwise extra complexity to be avoided--i= s to avoid (b), i.e., to avoid any cost of a "report-only" policy= which has no reporting endpoint defined. And I suspect that cost is low, a= nd does not justify even the minimal additional complexity of an "opt = out".=C2=A0

But I may be missing something he= re, as usual. ;)=C2=A0


* In fact, y= ou could design a behavior where the TXT record indicates if the new policy= is an "opt out" one or not, such that senders who do not have a = cached policy for the domain can be told via DNS-only not to lookup the new= policy, but senders who do have a policy MUST look it up to determine if i= t is an authenticated "opt out." But the extra complexity here is= high--making the system quite hard to reason about by introducing a new va= riant of the lookup flow--with limited real value.=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

--001a11426222c073bc054dc4cc49-- --001a11426222cace0b054dc4ccc4 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 K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCD0JeBfG9bp3rD6 MbA4kls/PGlEvrQ7G8D7CDJXt1JDNTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA0MjIxNzM1MjhaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAnqEjXEwhqZ8IIMsJhmn1TYKqGL1GslD1 ycS4wdCJNTYDWizrOYD5dIrMJ3vrS8ImXyipWkGOOTvqCNGM+1ZXHe4wLaFbRMGbYRW55C6WxfqO CzPbYoHMELHqbfJyucAzLapawUpK1qAvRZjrK0lHmFStWz46Dd7ydmzbYac3FxlztmfkmTWEMdyx xtEaCKpl6NpK5I2JNj5IxlRNakklPHvfU6NFJj0sB+TdeLsZcyC3+TMmcWsD9t4L0aNiWtv+AKsa jb3LizgQ498whxtX/wWwcYyd5qPNVbW7AUmUmv/TJn7KwPaa2RwDcSdspu1GycCUuVdhpVqQkeie 48yQvQ== --001a11426222cace0b054dc4ccc4-- From nobody Sat Apr 22 12:23: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 D9D6E129444 for ; Sat, 22 Apr 2017 12:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 lQqUnh3uduTe for ; Sat, 22 Apr 2017 12:23:05 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 984921205F0 for ; Sat, 22 Apr 2017 12:23:05 -0700 (PDT) X-AuditID: 12074423-4dbff7000000349d-80-58fbad9851d5 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 37.86.13469.89DABF85; Sat, 22 Apr 2017 15:23:04 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v3MJN3pI014927 for ; Sat, 22 Apr 2017 15:23:03 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v3MJMx4f010831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 22 Apr 2017 15:23:02 -0400 Date: Sat, 22 Apr 2017 14:23:00 -0500 From: Benjamin Kaduk To: uta@ietf.org Message-ID: <20170422192211.GH30306@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixCmqrTtj7e8Ig44vUhanjjYzOjB6LFny kymAMYrLJiU1J7MstUjfLoEro3ftcvaC2ywVUxo/sjQw3mXuYuTgkBAwkbh0OaiLkYtDSKCN SWJ/+09GCOcIo8SitjlsEM4LJolPr6azdDFycrAIqEpMWL6XCcRmE1CRaOi+zAxiiwgISPz+ +ZgVZKqwgJrEpNOlIGFeoAXnLzYzgthCAuYSd888ZoKIC0qcnPkEbCSzgJbEjX8vmUBamQWk JZb/4wAJcwpYSLx/3A/WKiqgLNEw4wHzBEb+WUi6ZyHpnoXQvYCReRWjbEpulW5uYmZOcWqy bnFyYl5eapGumV5uZoleakrpJkZQ2LG7KO9gfNnnfYhRgINRiYc3of13hBBrYllxZe4hRkkO JiVR3pDfPyOE+JLyUyozEosz4otKc1KLDzFKcDArifC6TwAq501JrKxKLcqHSUlzsCiJ84pr NEYICaQnlqRmp6YWpBbBZGU4OJQkeLXXADUKFqWmp1akZeaUIKSZODhBhvMADfcFqeEtLkjM Lc5Mh8ifYtTlmHPv63smIZa8/LxUKXHe3auBigRAijJK8+DmgNKFRPb+mleM4kBvCfPmgozi AaYauEmvgJYwAS056/cDZElJIkJKqoHRa8eSPIZFCy55Noo/+pLfVHo84YEw798PrxiFj2js /3D30N879y8KBjjlXzU7r/053CU17brPnoajnMs6Gd3ENTJX39Z7sFt+icHbDUKln7NqTy1a ob7Q97/lac8H3WVbcrM35uTwaTqvrYgXfr35t97Kr/+m+p1I4Fz3y9ry2ryqZQ+PmO19osRS nJFoqMVcVJwIAOpprVPyAgAA Archived-At: Subject: Re: [Uta] back to smtp-sts-04 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: Sat, 22 Apr 2017 19:23:07 -0000 > Date: Sat, 22 Apr 2017 19:35:26 +0200 > From: Daniel Margolis > To: uta@ietf.org > Subject: Re: [Uta] back to smtp-sts-04 > > On Thu, Apr 6, 2017 at 4:11 PM, Viktor Dukhovni > wrote: > > > > > Your JSON reference is to the obsolete RFC4627, the non-obsolete > > reference is RFC7159. > > > > Thanks. Fixed. And of course draft-ietf-jsonbis-rfc7159bis has made it through IETF last call, and currently has enough IESG ballot positions to pass (but no telechat date). So RFC 7159 may itself be the obsolet reference, soon. -Ben From nobody Sat Apr 22 18:32: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 AF9C21293EB for ; Sat, 22 Apr 2017 18:32: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 50hAOrEKYXhD for ; Sat, 22 Apr 2017 18:32:03 -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 64AD9126DFB for ; Sat, 22 Apr 2017 18:32:03 -0700 (PDT) Received: from [172.31.98.10] (rrcs-24-30-253-116.nys.biz.rr.com [24.30.253.116]) (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 CF6AE7A32F1 for ; Sun, 23 Apr 2017 01:32: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: Sat, 22 Apr 2017 21:31:58 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: <5C69D23D-9C3E-45EA-98C7-862C3916F5B2@dukhovni.org> References: <2DB01F3A9898AE41BB3266315D9FDA2704903D88@S-DC-ESTE03-B.net1.cec.eu.int> <5c361c89-907b-ff65-8a11-8df08e0e46af@isode.com> To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-04 Review 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, 23 Apr 2017 01:32:05 -0000 > On Apr 22, 2017, at 1:11 PM, Daniel Margolis = wrote: >=20 > Thanks for the pointer.=20 >=20 > Yes, I of course have no objections to checking CRL or OCSP. Given the = mixed > state of deployments among browsers, it merely seems worrisome to me = to require > that. MAY seems like a good clarification to have here. MAY is fine. Postfix has no support for CRLs or OCSP. CRLs will never = be supported, I might support OCSP stapling some day, but not very soon. Exim appears to have OCSP support, but last time I looked at the code, = it seemed to be going through the motions, but not actually validating the OCSP = response correctly. So indeed MUST is rather far from current or likely near-term practice. --=20 Viktor. From nobody Sat Apr 22 19:50: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 4C214126DD9 for ; Sat, 22 Apr 2017 19:50: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 4Z7NGAAd40bO for ; Sat, 22 Apr 2017 19:50: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 B2946126B6D for ; Sat, 22 Apr 2017 19:50:04 -0700 (PDT) Received: from [192.168.0.2] (cpe-67-241-70-168.twcny.res.rr.com [67.241.70.168]) (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 16D097A32F1 for ; Sun, 23 Apr 2017 02:50:02 +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: Sat, 22 Apr 2017 22:50:01 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] back to smtp-sts-04 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, 23 Apr 2017 02:50:06 -0000 > On Apr 22, 2017, at 1:35 PM, Daniel Margolis = wrote: >=20 >> Speaking of the policy, what should be done if the HTTPS policy >> contains multiple JSON objects, no JSON objects, or broken JSON? >=20 > "If a valid TXT record is found but no policy can be fetched via > HTTPS, and there is no valid (non-expired) previously-cached = policy, > senders MUST treat the recipient domain as one that has not > implemented MTA-STS." >=20 > If you can't parse it, it's not a valid policy, so you fall back to = cached-non-expired or none. > Same as if there's an HTTP timeout, an HTTPS cert validation error, = etc.=20 Getting an authenticated invalid policy seems rather different from = failure to retrieve the policy. The latter is obviously a temporary condition = and one can stick with what's cached. On the other hand when an authentic = policy fails to parse, it seems clear whatever we had in the cache is no longer = the current policy. So what is the right course of action is not so clear. =20 >> How does a domain get rid of its STS policy? I thought we had = discussed >> using "max_age =3D 0" for this, which after being in place long = enough to >> assure that all previously cached policies have expired can be = removed. >> Or might just "404" suffice >=20 > Yes, I remember discussing this. But I am not sure such a mechanism is = needed. I rather think it is needed. When a domain changes hands, or no longer = wishes to deal with the hassles of certificate expiration, it must be possible = to revoke the policy. > 1. Domains can publish a "report" policy (with or without a TLSRPT = record!) > with a low expiration What happens when that expires? It is again found and refreshed unless = there's a way to ultimate say "no policy". > 2. They have to keep this policy published until "last time the old = policy was > published" + "old policy's max_age" Yes, but that's not actually policy removal. Clients will likely still = end up collecting stats for reports, even if they later prove undeliverable or = there's no address to send them to. > Let's consider in comparison an implementation with a special "opt = out" mechanism > (however it works). Would it avoid the above two knock-on effects, or = be easier > to publish? It seems to me that "age=3D0" is simpler and more clear than "report". = Combined with ultimate removal of the DNS TXT record the policy is eventually flushed = from caches. > I think for publishing (i.e. the duration required in #2 above) the = answer is "no"; obviously the "opt out" must be published in the same = way (i.e. for the same duration) as any new policy. Similarly, because = it must be published as (effectively) a new policy, senders must still = cache it (or else hit the endpoint every time), so we're still talking = about knock-on effect (a).*=20 >=20 > So I think the only argument for adding an explicit opt-out--which I = think is otherwise extra complexity to be avoided--is to avoid (b), = i.e., to avoid any cost of a "report-only" policy which has no reporting = endpoint defined. And I suspect that cost is low, and does not justify = even the minimal additional complexity of an "opt out".=20 How does the "report" policy ultimately go away? When can clients stop = doing policy lookups and the HTTPS service be decommissioned? > But I may be missing something here, as usual. ;)=20 Yes, how does the refresh cycle stop... --=20 Viktor. From nobody Sat Apr 22 19:58: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 C24C2126B6D for ; Sat, 22 Apr 2017 19:58:28 -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 RNoDcBO8IFlT for ; Sat, 22 Apr 2017 19:58:27 -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 5B75A1294D4 for ; Sat, 22 Apr 2017 19:58:27 -0700 (PDT) Received: from [192.168.0.2] (cpe-67-241-70-168.twcny.res.rr.com [67.241.70.168]) (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 94AB27A32F1 for ; Sun, 23 Apr 2017 02:58:26 +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: Sat, 22 Apr 2017 22:58:25 -0400 Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Message-Id: References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] smtp-sts-04 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: Sun, 23 Apr 2017 02:58:29 -0000 > On Apr 22, 2017, at 1:35 PM, Daniel Margolis wrote: > > That does not jive with relatively easy to parse... > > JSON supports comments, elements that are integers, strings, > arrays or associative arrays (nested JSON objects). JSON > strings are UTF-8 and allow embedded NUL octets. > > Your JSON reference is to the obsolete RFC4627, the non-obsolete > reference is RFC7159. So any compelling arguments for JSON from MTA implementors? A much simpler format would be a block of lines (CRLF terminated), with each line either a boolean propery name, or a name value pair. version STSv1 mode report max_age 8640000 mx mx1.example.com mx mx2.example.com ... Line length is limited to the usual 1000 bytes including the terminating CRLF. This simplifies parsing, because a simple line-orienter parser can now process the entire policy. It is no longer possible to have multiple policies, as with JSON, because there is no way to express multiple objects. The JSON format is much too general for the needs at hand. -- Viktor. From nobody Sun Apr 23 04:10: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 59B72126CC7 for ; Sun, 23 Apr 2017 04:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-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 auIOEND0wiBa for ; Sun, 23 Apr 2017 04:10:08 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 D7C961200FC for ; Sun, 23 Apr 2017 04:10:07 -0700 (PDT) Received: from [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_RC100) id 1d2FP1-0002mb-CZ (return-path ); Sun, 23 Apr 2017 11:10:03 +0000 To: uta@ietf.org, "exim-dev@exim.org" References: <2DB01F3A9898AE41BB3266315D9FDA2704903D88@S-DC-ESTE03-B.net1.cec.eu.int> <5c361c89-907b-ff65-8a11-8df08e0e46af@isode.com> <5C69D23D-9C3E-45EA-98C7-862C3916F5B2@dukhovni.org> From: Jeremy Harris Message-ID: <1dff6643-83dd-ae6f-e513-b6e25c0dfd2b@wizmail.org> Date: Sun, 23 Apr 2017 12:10:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <5C69D23D-9C3E-45EA-98C7-862C3916F5B2@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Uta] draft-ietf-uta-mta-sts-04 Review 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, 23 Apr 2017 11:10:09 -0000 On 23/04/17 02:31, Viktor Dukhovni wrote: > Exim appears to have OCSP support, but last time I looked at the code, it seemed to > be going through the motions, but not actually validating the OCSP response correctly. Perhaps you could raise specific bugs? -- Cheers, Jeremy From nobody Sun Apr 23 04:58:34 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 04AC7129438 for ; Sun, 23 Apr 2017 04:58:32 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Ope7u25Z0FiY for ; Sun, 23 Apr 2017 04:58:29 -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 9353A1292F5 for ; Sun, 23 Apr 2017 04:58:29 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id k87so158060172ioi.0 for ; Sun, 23 Apr 2017 04:58:29 -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=Sk5h7ORfwJNyTnKh7fFs5pbv67x797K70auZXH45Nhw=; b=mVZul7/84JCiOIPNzX6zGUjMHPpo6bDkjCqJC8D7kB8ejS/4oBumhDlXe8rGdebQsi /ZLcqjT2F7YZDyfYXfmRpjP5N5uvG8RF94TD3TS4fb1duGrqZXDpCanZ7jfdoUfJtT2y LuLEcUq4bsn5Z26f3hJJ/hFMAE7pP18tr4AYziTRveqQKH95C0jvLpdfdHqCckqOD3WF KUHiFADVrxYkTYlAd1jFLdKpdURjwgz/KfneFMT4I0d4PjDAD/rWzzbMXKGClydbOFT4 3hMv6zxrzopZNpV6LFaXWA2IiIUkNmRDoR0Pl2+WA5OvePVUg6Hv9hXKaEwICINOF0Q3 kj3A== 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=Sk5h7ORfwJNyTnKh7fFs5pbv67x797K70auZXH45Nhw=; b=Q93E/h1+rLTjdZq+gcv4HK3t9yUMDJUXglwTxmtGHK8QsKbQk0zA7/mBiYjrdVj8Dr MnfbZZZLKVX/WeHzayBoGj3OJhDXukrkWBtlb9ZKUFg41eKn0kRs2d+gKro3yONDiXDO 7umTZGDFfcBEawmlRhwBGaVn5nzU1oi8wceHDPMdK4HW9HOjt1fIv7PvIl/I7d4Nrq78 okCGAAigC1xAtQ+OZ4E1NvcO7YZ4RGfpIktp5Ew1yvY+IAbUSLRX8BkDOh7QsZQguZOH qENtgo3k6RUYAlBlDhQmOWFDe37OV+gan6x/0HjLMuI6P+JWKEk+3Od5cYCrGtuVC7Nl /zQw== X-Gm-Message-State: AN3rC/7Ay8k90i5Wuj97rYa+5TFjuKSq7uXxBetCcCP+hD2YD28+FxhT HxtpGcKFj+/x0ig/JX8GHUTtCFJuDWe6xjk= X-Received: by 10.107.142.198 with SMTP id q189mr1619048iod.49.1492948708485; Sun, 23 Apr 2017 04:58:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.111.11 with HTTP; Sun, 23 Apr 2017 04:58:27 -0700 (PDT) In-Reply-To: References: From: Daniel Margolis Date: Sun, 23 Apr 2017 13:58:27 +0200 Message-ID: To: Alexey Melnikov Cc: "uta@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c05a35079bcdd054dd43597" Archived-At: Subject: Re: [Uta] Review of draft-ietf-uta-mta-sts-04 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, 23 Apr 2017 11:58:32 -0000 --94eb2c05a35079bcdd054dd43597 Content-Type: multipart/alternative; boundary=94eb2c05a3507062ff054dd4351b --94eb2c05a3507062ff054dd4351b Content-Type: text/plain; charset=UTF-8 Thanks. Comments inline, mostly ticking off changes. :) I have pushed all my changes in response to this to the git repo and they should appear in our next draft. On Wed, Apr 19, 2017 at 1:05 PM, Alexey Melnikov wrote: > Hi, > Below is my early "AD review" of the document. I think it is in pretty > good shape and is ready for WG Last Call (I am Ok with the question of JSON > versa something else be settled during or after WGLC.) > > 1) In 1.1: > > o Policy Domain: The domain for which an MTA-STS Policy is defined. > This is the next-hop domain; when sending mail to > "alice@example.com" this would ordinarly be "example.com", but > this may be overriden by explicit routing rules (as described in > "Policy Selection for Smart Hosts"). > > Nit: This needs an internal section reference. > I think there was another place in the document when an internal section > number is not mentioned. > Done. Thanks. > > 2) In 3.1: > > sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1" > %x53 %x76 %x31 > > Do you intend for this to be matched case-sensitively? > What you wrote above is that "v" is case-insensitive, but "STSv1" is. > Good point. I actually would have intended the field names to also be case-sensitive. (At any rate, the code I have is case sensitive.) I see no reason to tolerate mixed case here given we're requiring specific strings anyway. > > 3) Section 3.2 says that unrecognized fields are to be ignored, so you > need to update ABNF in 3.1 to make it clear. > > Current ABNF: > > sts-text-record = sts-version *WSP %x3B *WSP sts-id [%x3B] > > sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1" > %x53 %x76 %x31 > > sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT) > > I suggest something like the following (this implies that position of the > first 2 fields is fixed, extensions at the end. If you prefer that any > fields are in any order (other than the version), I can update the ABNF): > Good point. Looking at SPF, DMARC, and DKIM, all three require the v= to be first in the record (which makes some sense, I suppose, to allow future versions to have different parsing syntaxes), so I suppose we can just keep it as you have it here. Thanks for that! > > sts-text-record = sts-version *WSP field-delim *WSP sts-id > [field-delim [sts-extensions]] > > field-delim = %x3B > > sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1" > %x53 %x76 %x31 > > sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT) > > sts-extensions = sts-extension *(field-delim sts-extension) > [field-delim] > ; Extension fields at the end in any order > > sts-extension = sts-ext-name *WSP "=" *WSP sts-ext-value > > sts-ext-name = (ALPHA / DIGIT) *31(ALPHA / DIGIT / "_" / "-" / > ".") > > sts-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) > ; like esmtp-value from RFC 5321, but doesn't > allow ";". > ; So basically any CHAR excluding "=", ";", SP, > and control > ; characters. > > 4) In 3.2: Should "SHOULD ignore unrecognized fields" be a MUST? I.e., why > would it not be Ok to ignore unrecognized fields? > It's a bug. Thanks. :) > > 5) In 3.3: RFC 6125 use needs more details, because you need to specify > answers to every question in section 3 of RFC 6125. > In particular you should say that when checking certificates, you only use > DNS-ID and CN-ID (SRV-ID and URI-ID are not used) and that you allow > wildcards in them. > Thanks, I've clarified this. > 6) Last para on page 7: this is also true in RFC 6125. > Correct. 7) In 5.1, last para: I think you mean that if there are too many failures > to deliver when using MTA-STS, regular SMTP rules for generating a bounce > apply? I think this needs rewording to say that. > Fixed, and included a reference to rfc5321's relevant section, to hopefully make clear we expect existing rules to apply. > > 8) If you want to allow for extensibility, you probably need an IANA > registry of fields allowed, so that developers can find them easily. I can > help with some text. > I'd appreciate any suggestions. Is there a need for that now, though? I would not want to overengineer this, either. :) > > 9) On page 13: I think pseudocode should make it clear that you retrieve > DNS-ID SAN. > Thanks, done. > > Best Regards, > Alexey > > P.S. I might have a couple of extra items, but I need to double check a > few things first. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --94eb2c05a3507062ff054dd4351b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks. Comments inline, mostly ticking off changes. = :)=C2=A0

I have pushed all my changes in response = to this to the git repo and they should appear in our next draft.

=

On Wed, Apr 19, 2= 017 at 1:05 PM, Alexey Melnikov <alexey.melnikov@isode.com>= wrote:
Hi,
Below is my early "AD review" of the document. I think it is in p= retty good shape and is ready for WG Last Call (I am Ok with the question o= f JSON versa something else be settled during or after WGLC.)

1) In 1.1:

=C2=A0 =C2=A0o=C2=A0 Policy Domain: The domain for which an MTA-STS Policy = is defined.
=C2=A0 =C2=A0 =C2=A0 This is the next-hop domain; when sending mail to
=C2=A0 =C2=A0 =C2=A0 "alice@example.com" this would ordinarly be "example.com&q= uot;, but
=C2=A0 =C2=A0 =C2=A0 this may be overriden by explicit routing rules (as de= scribed in
=C2=A0 =C2=A0 =C2=A0 "Policy Selection for Smart Hosts").

Nit: This needs an internal section reference.
I think there was another place in the document when an internal section nu= mber is not mentioned.

Done. Thanks.=C2= =A0
=C2=A0

2) In 3.1:

=C2=A0 =C2=A0 =C2=A0 sts-version=C2=A0 =C2=A0 =C2=A0=3D "v" *WSP = "=3D" *WSP %x53 %x54=C2=A0 =C2=A0 =C2=A0 =C2=A0 ; "STSv1&quo= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 %x53 %x76 %x31

Do you intend for this to be matched case-sensitively?
What you wrote above is that "v" is case-insensitive, but "S= TSv1" is.

Good point. I actually w= ould have intended the field names to also be case-sensitive. (At any rate,= the code I have is case sensitive.) I see no reason to tolerate mixed case= here given we're requiring specific strings anyway.=C2=A0
= =C2=A0

3) Section 3.2 says that unrecognized fields are to be ignored, so you need= to update ABNF in 3.1 to make it clear.

Current ABNF:

=C2=A0 =C2=A0 =C2=A0 sts-text-record =3D sts-version *WSP %x3B *WSP sts-id = [%x3B]

=C2=A0 =C2=A0 =C2=A0 sts-version=C2=A0 =C2=A0 =C2=A0=3D "v" *WSP = "=3D" *WSP %x53 %x54=C2=A0 =C2=A0 =C2=A0 =C2=A0 ; "STSv1&quo= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 %x53 %x76 %x31

=C2=A0 =C2=A0 =C2=A0 sts-id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D "id&= quot; *WSP "=3D" *WSP 1*32(ALPHA / DIGIT)

I suggest something like the following (this implies that position of the f= irst 2 fields is fixed, extensions at the end. If you prefer that any field= s are in any order (other than the version), I can update the ABNF):

Good point.

Looking = at SPF, DMARC, and DKIM, all three require the v=3D to be first in the reco= rd (which makes some sense, I suppose, to allow future versions to have dif= ferent parsing syntaxes), so I suppose we can just keep it as you have it h= ere. Thanks for that!
=C2=A0

=C2=A0 =C2=A0 =C2=A0 sts-text-record =3D sts-version *WSP field-delim *WSP = sts-id [field-delim [sts-extensions]]

=C2=A0 =C2=A0 =C2=A0 field-delim=C2=A0 =C2=A0 =C2=A0=3D %x3B

=C2=A0 =C2=A0 =C2=A0 sts-version=C2=A0 =C2=A0 =C2=A0=3D "v" *WSP = "=3D" *WSP %x53 %x54=C2=A0 =C2=A0 =C2=A0 =C2=A0 ; "STSv1&quo= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 %x53 %x76 %x31

=C2=A0 =C2=A0 =C2=A0 sts-id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D "id&= quot; *WSP "=3D" *WSP 1*32(ALPHA / DIGIT)

=C2=A0 =C2=A0 =C2=A0 sts-extensions=C2=A0 =3D sts-extension *(field-delim s= ts-extension) [field-delim]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ; Extension fields at the end in any order

=C2=A0 =C2=A0 =C2=A0 sts-extension=C2=A0 =C2=A0=3D sts-ext-name *WSP "= =3D" *WSP sts-ext-value

=C2=A0 =C2=A0 =C2=A0 sts-ext-name=C2=A0 =C2=A0 =3D (ALPHA / DIGIT) *31(ALPH= A / DIGIT / "_" / "-" / ".")

=C2=A0 =C2=A0 =C2=A0 sts-ext-value=C2=A0 =C2=A0=3D 1*(%x21-3A / %x3C / %x3E= -7E)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ; like esmtp-value from RFC 5321, but doesn't allow ";&= quot;.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ; So basically any CHAR excluding "=3D", ";"= , SP, and control
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ; characters.

4) In 3.2: Should "SHOULD ignore unrecognized fields" be a MUST? = I.e., why would it not be Ok to ignore unrecognized fields?

It's a bug. Thanks. :)=C2=A0
=C2=A0

5) In 3.3: RFC 6125 use needs more details, because you need to specify ans= wers to every question in section 3 of RFC 6125.
In particular you should say that when checking certificates, you only use = DNS-ID and CN-ID (SRV-ID and URI-ID are not used) and that you allow wildca= rds in them.

Thanks, I've clarified= this.
=C2=A0
6) Last para on page 7: this is also true in RFC 6125.

=C2=A0Correct.=C2=A0

7) In 5.1, last para: I think you mean that if there are too many failures = to deliver when using MTA-STS, regular SMTP rules for generating a bounce a= pply? I think this needs rewording to say that.

Fixed, and included a reference to rfc5321's relevant section,= to hopefully make clear we expect existing rules to apply.=C2=A0
=C2=A0

8) If you want to allow for extensibility, you probably need an IANA regist= ry of fields allowed, so that developers can find them easily. I can help w= ith some text.

I'd appreciate any s= uggestions.=C2=A0

Is there a need for that now, th= ough? I would not want to overengineer this, either. :)=C2=A0
=C2= =A0

9) On page 13: I think pseudocode should make it clear that you retrieve DN= S-ID SAN.

Thanks, done.=C2=A0
=C2=A0

Best Regards,
Alexey

P.S. I might have a couple of extra items, but I need to double check a few= things first.

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

--94eb2c05a3507062ff054dd4351b-- --94eb2c05a35079bcdd054dd43597 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 K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCC5GqG8GHhZs54L NDYznqEnunzoXNpz6ZGF6XlNE0w2PTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA0MjMxMTU4MjlaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAGLkEEeH2U8JMq2iMSgZzKdWQLW5DvsKY db3bio4Dj0ao2LiOFtiaQu+Hwgo9f87XEXdP2cESmNX7U+MjdfYuSaV+gMKkGO7XsIzexRZpvhtO vRq/6f80khuiQINYuRt6Ae6odje0rTGQKQHyIobY+oXdRaNPEgdx5niSrNdAwUcbJPBKsEPk6//u hP9HkzATT87bzsSmv2y8yM3/kEr++RzhSBMev3CRZgznwoP1ofOVP93T+SgCMsxKsWtMN7Y+MZe0 T3LF7+e7+JFgU970zKBVMkC3Q3aDI7gfWTQ6KkLzaFB9XAaNsA4A/pv6UP/phqPndjw12AHgLW9e fEEB2Q== --94eb2c05a35079bcdd054dd43597-- From nobody Sun Apr 23 05:43:02 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 5FF4612941A for ; Sun, 23 Apr 2017 05:43:01 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ZLPzwbbKS3vF for ; Sun, 23 Apr 2017 05:42:59 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 DC2851270A0 for ; Sun, 23 Apr 2017 05:42:58 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id r16so151255437ioi.2 for ; Sun, 23 Apr 2017 05:42:58 -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=LKizw3XwtXt6Yl+yzeX3CqGsvbYSwWJGSyAVntgsu3s=; b=dqtswlywsB0+c6rfn+gBtXsZoYnToGR6QrP3J3ZCjGfPmJg7ZHMSnfKCIMo4yuyaCc DxRX+mbCd71fcV55ePr+zC4snhMaAj4zmQvWIS/5te/CWZ5buMMpseEVKZGXBUCYuswz Mgt3v79r/0Z4UgHGodupVHQwBK9SEKUH1jGtc3CMfNkHLdJH1Ct6zwfiRoBXIvxuPfUP r3Ia6XUgaxPpDUXyRCnkoIFXtQcwdOPOZ+DV0s5LrL6PQxcaIDCND1a5miHC2uyDYEwu TJzNpWKo6oEq9vow4Dybv0WDENaLY/Gc4/KniFjEvpITMFGc+Dh1sFVHTvVh6VsQld5g eiLw== 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=LKizw3XwtXt6Yl+yzeX3CqGsvbYSwWJGSyAVntgsu3s=; b=IW1fshOOwJChaWGDmWPvIsMNLxBZJ7Frk507vjd9ErVQsttdpXYorTd1/OPu2OY2sM 94MXIDA6kkbMNGrcr+JHVfIUs3kSCIUzXhUxqqvHTsSz5aXw0qNT/w9EcoSy6+1lWPk7 sbRPO86NytqxNoU1SnCg1Ibz68Q7Yq1NrFsxJ6Nbzo8yWwMrWxkX3c6x95ioCKbqNtmb WwZthDYhAV1lplGlXeefg1osEuGI00zXQr7CYXEU5hpwyiNFVschncZK2RDoc23qkwPl kA3ZhNruBpJXBKbv16ueJSN6XAeWDCX4EKJ6slAyXFwYAWIiK8LHb4aq7vPnRW6ZaXEg YI3w== X-Gm-Message-State: AN3rC/7B0rB+gJvYMFQ85LudvbPSTh8HaJJBmiqus6wpQFebckc7vbf2 RrH7Zl/0SHNS/M5SGazdv86bBEGeUASjPjU= X-Received: by 10.107.6.134 with SMTP id f6mr1470218ioi.96.1492951377408; Sun, 23 Apr 2017 05:42:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.111.11 with HTTP; Sun, 23 Apr 2017 05:42:56 -0700 (PDT) In-Reply-To: References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> From: Daniel Margolis Date: Sun, 23 Apr 2017 14:42:56 +0200 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113ee09c8ea256054dd4d4f1" Archived-At: Subject: Re: [Uta] back to smtp-sts-04 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, 23 Apr 2017 12:43:01 -0000 --001a113ee09c8ea256054dd4d4f1 Content-Type: multipart/alternative; boundary=001a113ee09c85179e054dd4d442 --001a113ee09c85179e054dd4d442 Content-Type: text/plain; charset=UTF-8 On Sun, Apr 23, 2017 at 4:50 AM, Viktor Dukhovni wrote: > > > > >> Speaking of the policy, what should be done if the HTTPS policy > >> contains multiple JSON objects, no JSON objects, or broken JSON? > > > > "If a valid TXT record is found but no policy can be fetched via > > HTTPS, and there is no valid (non-expired) previously-cached policy, > > senders MUST treat the recipient domain as one that has not > > implemented MTA-STS." > > > > If you can't parse it, it's not a valid policy, so you fall back to > cached-non-expired or none. > > Same as if there's an HTTP timeout, an HTTPS cert validation error, etc. > > Getting an authenticated invalid policy seems rather different from failure > to retrieve the policy. The latter is obviously a temporary condition and > one can stick with what's cached. On the other hand when an authentic > policy > fails to parse, it seems clear whatever we had in the cache is no longer > the > current policy. So what is the right course of action is not so clear. > It's not clear, to be sure, but any other strategy is complex. If we can't parse the new policy, do we assume a misconfiguration and fail open? It's a corner case where the most predictable behavior, to me, would be to ignore new policies which are unparseable. I think predictability here is a virtue. Of course, my intuition about expected behavior may be wrong. But if I'm correct on what's "predictable", overriding that intuition with explicitly specified behavior (like, "unparseable policies should be taken as a sign that the recipient domain is confused and has opted out of STS, despite any valid cached policy") seems not desirable to me, unless the risks are very high. > >> How does a domain get rid of its STS policy? I thought we had discussed > >> using "max_age = 0" for this, which after being in place long enough to > >> assure that all previously cached policies have expired can be removed. > >> Or might just "404" suffice > > > > Yes, I remember discussing this. But I am not sure such a mechanism is > needed. > > I rather think it is needed. When a domain changes hands, or no longer > wishes > to deal with the hassles of certificate expiration, it must be possible to > revoke the policy. > > > 1. Domains can publish a "report" policy (with or without a TLSRPT > record!) > > with a low expiration > > What happens when that expires? It is again found and refreshed unless > there's > a way to ultimate say "no policy". > Sure, but as I explained, given *any *hypothetical "opt-out" mechanism, it is theoretically not possible to design one which you do not have to keep publishing until $time_you_last_had_a_different_policy + $that_policy's_max_age has passed. (Since I'm referring to this time below, let's call it "old policy expiration time.") In other words, publishing a report-only policy with a low expiration is just as good as publishing an "opt out" policy, in the sense that in the former case you have to publish the report-only up until the old policy has expired everywhere, and in the latter case it's identical. > > 2. They have to keep this policy published until "last time the old > policy was > > published" + "old policy's max_age" > > Yes, but that's not actually policy removal. Clients will likely still > end up > collecting stats for reports, even if they later prove undeliverable or > there's > no address to send them to. > As I discussed, the only consideration here seems to be one if, "Are the costs of 'reporting' (i.e. stats collection, etc) sufficiently high to warrant the need for an explicit opt-out mechanism?" I don't personally think so, but I may be wrong here. > > Let's consider in comparison an implementation with a special "opt out" > mechanism > > (however it works). Would it avoid the above two knock-on effects, or be > easier > > to publish? > > It seems to me that "age=0" is simpler and more clear than "report". > Combined with > ultimate removal of the DNS TXT record the policy is eventually flushed > from caches. > Here and below in your email, it seems your main question is (to paraphrase), "When will senders know to stop caching a policy, even if it is a 'report only' policy?" In fact there are two different things to consider here: 1. When can the recipient stop publishing the "opt out" policy? 2. When can the sender stop caching the policy? The point I attempted to make in my previous email is that #1 is invariant, regardless of mechanism: in all cases, the recipient must publish the "opt out" signal until the max time at which the previous policy was published *plus* that policy's max_age has passed. (I believe this is obvious.) However, #2 is also mostly unchanged in most of these various designs: assuming any "opt out" indicator that uses the usual TXT "id" string as an indicator of presence, senders will want to cache the "id" seen in order to see if the "opt out" policy has been supplanted by an "opt in", if only to avoid repeated policy refreshes. (Of course senders could merely cache the last version seen for that domain and a null policy; they don't need to cache anything else for the sake of supporting opt-outs. And in fact, we could achieve the same security properties as exist now by purging the cache on opt-out and instead embedding one new boolean indicator in the TXT record, indicating that the new policy is an opt-out policy, to be fetched only by senders who have cached a non-opt-out policy. I trust the functioning of this approach is obvious, but regardless, it's needless complexity and I would rather not explain it if it's not. :) ) So the long and short of it is that one *cannot* design a system in which the recipient does not have to publish the "opt out" signal for this amount of time; I'm fairly sure that's an invariant. Contrarily, one *could* design a system in which senders do not have to cache anything at all for domains that have opted out, but, at least as far as I can see, only by modifying the TXT record format, which is not desirable to me. Two questions for you: 1. Is your main concern point 1 above (i.e. when can recipients stop publishing) or point 2 (i.e. how can we save cache space of cached "opt out" policies)? 2. If #2, can you propose with more detail how you suggest a different mechanism to work? Does it involve the TXT modification I describe above? Or is there a simpler way? > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a113ee09c85179e054dd4d442 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Apr 23, 2017 at 4:50 AM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:

>
>> Speaking of the policy, what should be done if the HTTPS policy >> contains multiple JSON objects, no JSON objects, or broken JSON? >
>=C2=A0 =C2=A0 "If a valid TXT record is found but no policy can be= fetched via
>=C2=A0 =C2=A0 HTTPS, and there is no valid (non-expired) previously-cac= hed policy,
>=C2=A0 =C2=A0 senders MUST treat the recipient domain as one that has n= ot
>=C2=A0 =C2=A0 implemented MTA-STS."
>
> If you can't parse it, it's not a valid policy, so you fall ba= ck to cached-non-expired or none.
> Same as if there's an HTTP timeout, an HTTPS cert validation error= , etc.

Getting an authenticated invalid policy seems rather different from = failure
to retrieve the policy.=C2=A0 The latter is obviously a temporary condition= and
one can stick with what's cached.=C2=A0 On the other hand when an authe= ntic policy
fails to parse, it seems clear whatever we had in the cache is no longer th= e
current policy.=C2=A0 So what is the right course of action is not so clear= .

It's not clear, to be sure, but a= ny other strategy is complex. If we can't parse the new policy, do we a= ssume a misconfiguration and fail open? It's a corner case where the mo= st predictable behavior, to me, would be to ignore new policies which are u= nparseable. I think predictability here is a virtue.=C2=A0

Of course, my intuition about expected behavior may be wrong. But = if I'm correct on what's "predictable", overriding that i= ntuition with explicitly specified behavior (like, "unparseable polici= es should be taken as a sign that the recipient domain is confused and has = opted out of STS, despite any valid cached policy") seems not desirabl= e to me, unless the risks are very high.=C2=A0
=C2=A0
>> How does a domain get rid of its STS policy?=C2=A0 I thought we ha= d discussed
>> using "max_age =3D 0" for this, which after being in pla= ce long enough to
>> assure that all previously cached policies have expired can be rem= oved.
>> Or might just "404" suffice
>
> Yes, I remember discussing this. But I am not = sure such a mechanism is needed.

I rather think it is needed.=C2=A0 When a domain changes hands, or n= o longer wishes
to deal with the hassles of certificate expiration, it must be possible to<= br> revoke the policy.

> 1. Domains can publish a "report" policy (with or without a = TLSRPT record!)
> with a low expiration

What happens when that expires?=C2=A0 It is again found and refreshe= d unless there's
a way to ultimate say "no policy".

Sure, but as I explained, given any hypothetical "opt-out= " mechanism, it is theoretically not possible to design one which you = do not have to keep publishing until $time_you_last_had_a_different_policy = + $that_policy's_max_age has passed.=C2=A0

(Si= nce I'm referring to this time below, let's call it "old polic= y expiration time.")=C2=A0

In other words, pu= blishing a report-only policy with a low expiration is just as good as publ= ishing an "opt out" policy, in the sense that in the former case = you have to publish the report-only up until the old policy has expired eve= rywhere, and in the latter case it's identical.=C2=A0
=C2=A0<= /div>
> 2. They have to keep this policy published until "last time the o= ld policy was
> published" + "old policy's max_age"

Yes, but that's not actually policy removal.=C2=A0 Clients will = likely still end up
collecting stats for reports, even if they later prove undeliverable or the= re's
no address to send them to.

As I discus= sed, the only consideration here seems to be one if, "Are the costs of= 'reporting' (i.e. stats collection, etc) sufficiently high to warr= ant the need for an explicit opt-out mechanism?"=C2=A0

<= /div>
I don't personally think so, but I may be wrong here.=C2=A0
=C2=A0
> Let's consider in comparison an implementation with a special &quo= t;opt out" mechanism
> (however it works). Would it avoid the above two knock-on effects, or = be easier
> to publish?

It seems to me that "age=3D0" is simpler and more clear th= an "report".=C2=A0 Combined with
ultimate removal of the DNS TXT record the policy is eventually flushed fro= m caches.

Here and below in your email,= it seems your main question is (to paraphrase), "When will senders kn= ow to stop caching a policy, even if it is a 'report only' policy?&= quot;

In fact there are two different things to co= nsider here:

1. When can the recipient stop publis= hing the "opt out" policy?
2. When can the sender stop = caching the policy?

The point I attempted to make = in my previous email is that #1 is invariant, regardless of mechanism: in a= ll cases, the recipient must publish the "opt out" signal until t= he max time at which the previous policy was published plus=C2=A0tha= t policy's max_age has passed. (I believe this is obvious.)
<= br>
However, #2 is also mostly unchanged in most of these various= designs: assuming any "opt out" indicator that uses the usual TX= T "id" string as an indicator of presence, senders will want to c= ache the "id" seen in order to see if the "opt out" pol= icy has been supplanted by an "opt in", if only to avoid repeated= policy refreshes.

(Of course senders could merely= cache the last version seen for that domain and a null policy; they don= 9;t need to cache anything else for the sake of supporting opt-outs. And in= fact, we could achieve the same security properties as exist now by purgin= g the cache on opt-out and instead embedding one new boolean indicator in t= he TXT record, indicating that the new policy is an opt-out policy, to be f= etched only by senders who have cached a non-opt-out policy. I trust the fu= nctioning of this approach is obvious, but regardless, it's needless co= mplexity and I would rather not explain it if it's not. :) )=C2=A0

So the long and short of it is that one cannot= =C2=A0design a system in which the recipient does not have to publish the &= quot;opt out" signal for this amount of time; I'm fairly sure that= 's an invariant.=C2=A0

Contrarily, one coul= d=C2=A0design a system in which senders do not have to cache anything a= t all for domains that have opted out, but, at least as far as I can see, o= nly by modifying the TXT record format, which is not desirable to me.=C2=A0=

Two questions for you:

1= . Is your main concern point 1 above (i.e. when can recipients stop publish= ing) or point 2 (i.e. how can we save cache space of cached "opt out&q= uot; policies)?=C2=A0
2. If #2, can you propose with more detail = how you suggest a different mechanism to work? Does it involve the TXT modi= fication I describe above? Or is there a simpler way?
=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

--001a113ee09c85179e054dd4d442-- --001a113ee09c8ea256054dd4d4f1 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 K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCABMh/aQNz1+p9/ NrXHApvR1uzR/NkrtBQdIE1tAgXlrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA0MjMxMjQyNThaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAN8/vXGVdMyELpIXDNbFR0nMSTqVaRhDM P01Qlvxeuv7q7P+E0QUC5p1l+aea45c4O8TEvJkyOw1MuMrRjh9yin+sQCKupAMCzE3hBrFUp2rL Y9xSBjGxEf3NfrJCubgzqp+vTfG96IJrnZ5cYyQFV+EpeIeBZ0nJZKT7mBioY/OgoAupn0xBxqw7 ywp64QJADP9KkjHMs32OtctB1zXsXQNvZpCa/EPaK3x4aqcQOTX2p6heQgKEE9lDMJCC7IAGVLuY sjmnKA+6qHHckccXyGK7JsI534hHJyVKPeiW2YLtLCljDY13VHY4Y084ZuPWxI/Tac0gzeUDQydL 70v8hg== --001a113ee09c8ea256054dd4d4f1-- From nobody Sun Apr 23 05:48:45 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 D3B1C127978 for ; Sun, 23 Apr 2017 05:48:44 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 xfI_pXvEkszK for ; Sun, 23 Apr 2017 05:48:43 -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 1BDE612943C for ; Sun, 23 Apr 2017 05:48:43 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id g66so30014202ite.1 for ; Sun, 23 Apr 2017 05:48: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; bh=HFOvRND1+vaNvKIESk6+3564DkmwAWMjnEMKlB8W7E4=; b=gJqUGjFR7Ljm4XmZcMy9Vo/hH7oDP654Jp886ejBG7n7iPvMCRQoSI25PVRcoo7Jwu /nWpIfkJnvhxgbZWDb1n52t5D/1MnDVnRT2Fm0XVqBv9J05BfpMPvsH7GFfo75PD15eq IYdoISU1WwlURdxOUk79T8UMzFClxdfPmA+nod9vE+WT1XLMOztVrQHWQAJTF8MDs5tE 0uV1cBe7UNJNX1euH8dGrm/oLXf0V3qDfFEkXxr4WbmV74dUsF4zyTmLvjqVnBwJeBCh tukrSNaDg3Mu5KQ9HAOjzM9ThLwaBazd3+mk9V7fHvAiYXq0YSMvXArMYuwopp4Tjy/8 2L/g== 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=HFOvRND1+vaNvKIESk6+3564DkmwAWMjnEMKlB8W7E4=; b=EwyAAZ/jKrxU+P7Sf3e4nOhFFEUrx6lZkh+QbwUQLVjaYgKnVSciQI5HXjsHklv4H/ ONUtYxJ4yM1mh3jKLhBsPFWZDjpLXPQugfLVhXnkdTl8kpoW8eIxZ/EeCtDthTW0JQMj L+U/o06z0Ps0mxrJxRit4gG9FcQ3IaN6M+rGbGU/jxwJDazHzOdth0goCiOg48AeNhoh iGMBaiEutK0GqmjgiLzpKHQUvOixRYpmB2frgFFiSzEr8+eHsWfd3TKAWiSvyLJR1Qj3 TRZT0tRn28CO0mrJTBHNe1hkNMJVPMGlePo+Sx/7DTwDinjPdzAptuqZ901hCyzp+0Tt hf3Q== X-Gm-Message-State: AN3rC/5pq+yZ2Awv4Vnla5HtgFL72icP4HNDtP0McnEizlifiMCj2F1E cJy6TJ/j6Dn7Xj3Oc6zMdKSDON4K/dx4vN9iVw== X-Received: by 10.36.35.129 with SMTP id u123mr7630280itu.105.1492951721701; Sun, 23 Apr 2017 05:48:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.111.11 with HTTP; Sun, 23 Apr 2017 05:48:40 -0700 (PDT) In-Reply-To: References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> From: Daniel Margolis Date: Sun, 23 Apr 2017 14:48:40 +0200 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1146030a13deb4054dd4e9a4" Archived-At: Subject: Re: [Uta] smtp-sts-04 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: Sun, 23 Apr 2017 12:48:45 -0000 --001a1146030a13deb4054dd4e9a4 Content-Type: multipart/alternative; boundary=001a1146030a0a8e94054dd4e93c --001a1146030a0a8e94054dd4e93c Content-Type: text/plain; charset=UTF-8 In the interests of not looking like I'm ignoring your mail, just to reiterate, I have no personal feeling about this. My read at the meeting in Chicago was that consensus was not totally obvious, but I'm really happy to defer to the chairs here on what the consensus seems to be or how to unblock this. As I have said before, while this is certainly an issue people have legitimately strong feelings about, it's not really a *fundamental* issue, and, speaking personally (and I think for the other authors), I would be happy with any resolution in any direction--the main point here is to provide some additional security to email-in-transit, not to provide security to email-in-transit by leveraging JSON. ;) Dan On Sun, Apr 23, 2017 at 4:58 AM, Viktor Dukhovni wrote: > > > On Apr 22, 2017, at 1:35 PM, Daniel Margolis > wrote: > > > > That does not jive with relatively easy to parse... > > > > JSON supports comments, elements that are integers, strings, > > arrays or associative arrays (nested JSON objects). JSON > > strings are UTF-8 and allow embedded NUL octets. > > > > Your JSON reference is to the obsolete RFC4627, the non-obsolete > > reference is RFC7159. > > So any compelling arguments for JSON from MTA implementors? > > A much simpler format would be a block of lines (CRLF terminated), > with each line either a boolean propery name, or a name value pair. > > version STSv1 > mode report > max_age 8640000 > mx mx1.example.com > mx mx2.example.com > ... > > Line length is limited to the usual 1000 bytes including the > terminating CRLF. > > This simplifies parsing, because a simple line-orienter parser > can now process the entire policy. It is no longer possible > to have multiple policies, as with JSON, because there is no > way to express multiple objects. The JSON format is much > too general for the needs at hand. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a1146030a0a8e94054dd4e93c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In the interests of not looking like I'm ignoring your= mail, just to reiterate, I have no personal feeling about this. My read at= the meeting in Chicago was that consensus was not totally obvious, but I&#= 39;m really happy to defer to the chairs here on what the consensus seems t= o be or how to unblock this.=C2=A0

As I have said before= , while this is certainly an issue people have legitimately strong feelings= about, it's not really a fundamental=C2=A0issue, and, speaking = personally (and I think for the other authors), I would be happy with any r= esolution in any direction--the main point here is to provide some addition= al security to email-in-transit, not to provide security to email-in-transi= t by leveraging JSON. ;)=C2=A0

Dan

On Sun, Apr 23, 2017 = at 4:58 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wr= ote:

> On Apr 22, 2017, at 1:35 PM, Daniel Margolis <dmargolis@google.com> wrote:
>
> That does not jive with relatively easy to parse...
>
> JSON supports comments, elements that are integers, strings,
> arrays or associative arrays (nested JSON objects).=C2=A0 JSON
> strings are UTF-8 and allow embedded NUL octets.
>
> Your JSON reference is to the obsolete RFC4627, the non-obsolete
> reference is RFC7159.

So any compelling arguments for JSON from MTA implementors?

A much simpler format would be a block of lines (CRLF terminated),
with each line either a boolean propery name, or a name value pair.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 version STSv1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mode report
=C2=A0 =C2=A0 =C2=A0 =C2=A0 max_age 8640000
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mx mx1.example.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mx mx2.example.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...

Line length is limited to the usual 1000 bytes including the
terminating CRLF.

This simplifies parsing, because a simple line-orienter parser
can now process the entire policy.=C2=A0 It is no longer possible
to have multiple policies, as with JSON, because there is no
way to express multiple objects.=C2=A0 The JSON format is much
too general for the needs at hand.

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

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

--001a1146030a0a8e94054dd4e93c-- --001a1146030a13deb4054dd4e9a4 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 K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAAM4m11J/UqWNT x8LumuIUiPIMkADvelbCCwv1fr50DjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA0MjMxMjQ4NDJaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEArhZEmx3HbprcslgRnPn8rhjyUv2JaTpM oaaCkGYRYCTv8iFppUhPZtYTZNRssF8vfWcgefzoK/yLW8s24/Me5hIYmQfu0n+I4b1G8ayPqOLE wku2XQeXIOVFG5KWeN6d8UsqiC7etuUjbPNCTQB8IUZM9OECaUDfIBZWprkV2/RAb3qc6iofoGf/ TZS/9A/9wfJSRf0oFJ0tTsfjtP3hhxcD8tZeUgbEJ1jz0Jfde9Q5CYDIo5S4UQ07booUS93u75tc Lhceds081d1xWTkqT/5EZd/DYTs0BvFP4rLhD/g3oCHnzsU/RoWPzW8pwipIRA87NpDpwspL+MSB cEbMeg== --001a1146030a13deb4054dd4e9a4-- From nobody Sun Apr 23 13:06:22 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 D267F1272E1 for ; Sun, 23 Apr 2017 13:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 NV3M_BF_zaiz for ; Sun, 23 Apr 2017 13:06:20 -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 115DD126B6E for ; Sun, 23 Apr 2017 13:06:19 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id A0B2C1F416; Sun, 23 Apr 2017 20:06:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1492977977; bh=FEV5K9dxrcIv7gnCxDr+5Wq2v/YZsI3lLogARWRgYFg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=TIQTKj4YnkfuhuJaFqFkNWA/ZDmF0v+t6A6k8iLnTKt9vHt8BplBUfQi1xxW8Y2YV Ldd+e5FHs5eilN42FCzJvnLrgDS9Ck4EqrCNY8Pa6Ge4VFEY8SJabztv0cnGm+Sqzv HfhRVB79DUmD3xGvKmY2fnLrO4puHuC7LDBhcyEk= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 3C2AC107AC45B; Sun, 23 Apr 2017 20:03:26 +0000 (UTC) From: James Cloos To: uta@ietf.org Cc: Viktor Dukhovni In-Reply-To: (Viktor Dukhovni's message of "Sat, 22 Apr 2017 22:58:25 -0400") References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2016 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: Sun, 23 Apr 2017 16:03:26 -0400 Message-ID: Lines: 13 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:170423:uta@ietf.org::g/+uvXFqrALZ9vLS:00003DgTK X-Hashcash: 1:28:170423:ietf-dane@dukhovni.org::bGLHyNyYdrf698Zh:00000000000000000000000000000000000000lHNnM Archived-At: Subject: Re: [Uta] smtp-sts-04 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: Sun, 23 Apr 2017 20:06:22 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> A much simpler format would be a block of lines (CRLF terminated), VD> with each line either a boolean propery name, or a name value pair. CRs should not be required in such a format. It should be possible to serve a static text file in that case, and not have to worry about (or muck around with) line endings. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Apr 24 15:34: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 0E132131955 for ; Mon, 24 Apr 2017 15:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 IdKbo33mcw9h for ; Mon, 24 Apr 2017 15:34:09 -0700 (PDT) Received: from nm8-vm4.bullet.mail.sg3.yahoo.com (nm8-vm4.bullet.mail.sg3.yahoo.com [106.10.148.195]) (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 E69D9131953 for ; Mon, 24 Apr 2017 15:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1493073246; bh=i2xjfYhONu0+OZ085LGcqODhIj5AuF1IthGTgAbnq3c=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=qKTKBxYKXK7SmvvAuJydMCPv5zQeD7ZkuZSoYH7TcG7XDE8lHg7QwQAbTQmuymcs6WuMfQbRytqrR/FX6Ha+vMVi0W2y+K+GjOfp+C6bJg4/1VRG59OkorUkIkIRKxUfElPEkiK4RsylWA6yJ6hnWunogFGRa60ay8hu/IYjpaYGt2usoKWvkUH6nUGce0ZUSOiHKoypb0yakXg7ooUudl4zTOQu9NtdlL/nxyvruAe75XuHssqsF7DdaI/uCQBltWVd2RF9pHHOHgInrzFZauZPxggRURSJUiCrmanfFXzWcooylispptRYDfKn0pCK7wtmYNMQzM4uqO/dsIQK+g== Received: from [106.10.166.115] by nm8.bullet.mail.sg3.yahoo.com with NNFMP; 24 Apr 2017 22:34:06 -0000 Received: from [106.10.150.29] by tm4.bullet.mail.sg3.yahoo.com with NNFMP; 24 Apr 2017 22:34:06 -0000 Received: from [127.0.0.1] by omp1030.mail.sg3.yahoo.com with NNFMP; 24 Apr 2017 22:34:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 816935.39310.bm@omp1030.mail.sg3.yahoo.com X-YMail-OSG: aQcDpocVM1l5TooUf3SgSy_K.h6O_coNzdFM3s9RmhK.qtI3H1VXqiZTCo.7gIi kFTqZL0zo0yqC3nVK5rGCuRExyGwLfarbyiMsrimvVqYn68F4ZEBk5XZc2j1omfnywyx0iDvFQzL FEiPxERKnQOkinnz4RbPGjE3cZ5sVAfKU5O1x6zpvEd28z6otI6RhN3zExGcORCxY_kiHxIKon3F Km6LUTxa4Pfv.qCctuZg_Y_PRHWoTIh6F1Bj6gdvzLl6US31p44t.z.GrOCUq4PzMz2IFoAI16VZ wHNwA8iRdtvEpUp_efO7V6TNlD59WQ_GLbia08HfMefQNvg_EK7VIaBWGiQ6mgTtaaxklB9uaor4 _QAUDAHjMRZbkljTaQSn6Z2GZ0iWiwT8.C83tCwRXbXKThBxuVqgRBiRByVPcIHYAmPoHzZ4CWtH edOXT18pYXPWkqqC_.eRD4fAjjCG9d5Unf81U9NXdU7FpqJk.VlhROAmEr.6U8GOHI91JrrIlv0f A5ATJ.piOVk.1sdYd8dVdxEgFzY44L3tSZcg0sWJH_h94CXghjLPnCIqE5NmC5a3MWJix0D5Zupm 4kOR0aLheWw-- Received: from jws600005.mail.sg3.yahoo.com by sendmailws104.mail.sg3.yahoo.com; Mon, 24 Apr 2017 22:34:06 +0000; 1493073246.442 Date: Mon, 24 Apr 2017 22:34:06 +0000 (UTC) From: Binu Ramakrishnan Reply-To: Binu Ramakrishnan To: Daniel Margolis , "uta@ietf.org" Message-ID: <907547420.8067868.1493073246224@mail.yahoo.com> In-Reply-To: References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8067867_1001381462.1493073246221" X-Mailer: WebService/1.1.9408 YahooMailNeo Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.1 Safari/603.1.30 Archived-At: Subject: Re: [Uta] smtp-sts-04 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, 24 Apr 2017 22:34:11 -0000 ------=_Part_8067867_1001381462.1493073246221 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable IMO the main hurdle with key-value format is that we do not have a standard= format, and by extension off-the-shelf library support. So the question is= - whether to write custom kv parsers or use a standard format - JSON. Thanks,-binu From: Daniel Margolis To: uta@ietf.org=20 Sent: Sunday, 23 April 2017 5:48 AM Subject: Re: [Uta] smtp-sts-04 JSON =20 In the interests of not looking like I'm ignoring your mail, just to reiter= ate, I have no personal feeling about this. My read at the meeting in Chica= go was that consensus was not totally obvious, but I'm really happy to defe= r to the chairs here on what the consensus seems to be or how to unblock th= is.=C2=A0 As I have said before, while this is certainly an issue people have legitim= ately strong feelings about, it's not really a fundamental=C2=A0issue, and,= speaking personally (and I think for the other authors), I would be happy = with any resolution in any direction--the main point here is to provide som= e additional security to email-in-transit, not to provide security to email= -in-transit by leveraging JSON. ;)=C2=A0 Dan On Sun, Apr 23, 2017 at 4:58 AM, Viktor Dukhovni w= rote: > On Apr 22, 2017, at 1:35 PM, Daniel Margolis wrote= : > > That does not jive with relatively easy to parse... > > JSON supports comments, elements that are integers, strings, > arrays or associative arrays (nested JSON objects).=C2=A0 JSON > strings are UTF-8 and allow embedded NUL octets. > > Your JSON reference is to the obsolete RFC4627, the non-obsolete > reference is RFC7159. So any compelling arguments for JSON from MTA implementors? A much simpler format would be a block of lines (CRLF terminated), with each line either a boolean propery name, or a name value pair. =C2=A0 =C2=A0 =C2=A0 =C2=A0 version STSv1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mode report =C2=A0 =C2=A0 =C2=A0 =C2=A0 max_age 8640000 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mx mx1.example.com =C2=A0 =C2=A0 =C2=A0 =C2=A0 mx mx2.example.com =C2=A0 =C2=A0 =C2=A0 =C2=A0 ... Line length is limited to the usual 1000 bytes including the terminating CRLF. This simplifies parsing, because a simple line-orienter parser can now process the entire policy.=C2=A0 It is no longer possible to have multiple policies, as with JSON, because there is no way to express multiple objects.=C2=A0 The JSON format is much too general for the needs at hand. -- =C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor. ______________________________ _________________ 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 =20 ------=_Part_8067867_1001381462.1493073246221 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IMO the main hurdle with key-value format = is that we do not have a standard format, and by extension off-the-shelf li= brary support. So the question is - whether to write custom kv parsers or u= se a standard format - JSON.

Thanks,
-binu

=
From: Daniel Margolis <dmargolis@google.com>
= To: uta@ietf.org
Sent: Sunday, 23 April 2017 5:48 = AM
Subject: Re: [Uta] = smtp-sts-04 JSON

In the interests of not looking like I'm igno= ring your mail, just to reiterate, I have no personal feeling about this. M= y read at the meeting in Chicago was that consensus was not totally obvious= , but I'm really happy to defer to the chairs here on what the consensus se= ems to be or how to unblock this. 

As I have said before, while this is certainly an issue peopl= e have legitimately strong feelings about, it's not really a fundamental issue, and, speaking= personally (and I think for the other authors), I would be happy with any = resolution in any direction--the main point here is to provide some additio= nal security to email-in-transit, not to provide security to email-in-trans= it by leveraging JSON. ;) 

Dan

On Sun, Apr 2= 3, 2017 at 4:58 AM, Viktor Dukhovni <ietf-dane@dukhovni= .org> wrote:

> On Apr 22, 2017, at 1:35 PM, Daniel Margolis <dmargolis@google.com> wrote:
>
> That does not jive with relatively easy to parse...
>
> JSON supports comments, elements that are integers, strings,
> arrays or associative arrays (nested JSON objects).  JSON
> strings are UTF-8 and allow embedded NUL octets.
>
> Your JSON reference is to the obsolete RFC4627, the non-obsolete
> reference is RFC7159.

So any compelling arguments for JSON from MTA implementors?

A much simpler format would be a block of lines (CRLF terminated),
with each line either a boolean propery name, or a name value pair.

        version STSv1
        mode report
        max_age 8640000
        mx mx1.example.com
        mx mx2.example.com
        ...

Line length is limited to the usual 1000 bytes including the
terminating CRLF.

This simplifies parsing, because a simple line-orienter parser
can now process the entire policy.  It is no longer possible
to have multiple policies, as with JSON, because there is no
way to express multiple objects.  The JSON format is much
too general for the needs at hand.

--
        Viktor.

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

_____________________________= __________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailma= n/listinfo/uta


------=_Part_8067867_1001381462.1493073246221-- From nobody Mon Apr 24 15:49: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 EF177131838 for ; Mon, 24 Apr 2017 15:49:39 -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 t3JADgAAq_Ha for ; Mon, 24 Apr 2017 15:49:38 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66127131952 for ; Mon, 24 Apr 2017 15:49:38 -0700 (PDT) Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 6A4817A32F1 for ; Mon, 24 Apr 2017 22:49:37 +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: <907547420.8067868.1493073246224@mail.yahoo.com> Date: Mon, 24 Apr 2017 18:49:36 -0400 Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Message-Id: <271D533C-7C48-438C-8BBE-0EEC0DFB92DF@dukhovni.org> References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> <907547420.8067868.1493073246224@mail.yahoo.com> To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] smtp-sts-04 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, 24 Apr 2017 22:49:40 -0000 > On Apr 24, 2017, at 6:34 PM, Binu Ramakrishnan wrote: > > IMO the main hurdle with key-value format is that we do not have a standard > format, and by extension off-the-shelf library support. So the question is > - whether to write custom kv parsers or use a standard format - JSON. SMTP MTAs already parse key-value pairs in EHLO responses, and ESMTP extensions to the MAIL FROM and RCPT TO commands. No additional code is required to do similar parsing of the policy in question. JSON is not a standard "format" it is a general syntax, that can represent a stream of composite objects. This is a poor fit in terms of the libraries needed to support JSON and having to deal with attributes that hold the wrong kind of data (list instead of scalar) or multiple objects instead of one... -- Viktor. From nobody Mon Apr 24 21:22: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 C2F6E1314D9 for ; Mon, 24 Apr 2017 21:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 UViMZX2RwjHj for ; Mon, 24 Apr 2017 21:22:13 -0700 (PDT) Received: from nm22-vm2.bullet.mail.sg3.yahoo.com (nm22-vm2.bullet.mail.sg3.yahoo.com [106.10.151.49]) (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 11E01120326 for ; Mon, 24 Apr 2017 21:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1493094130; bh=EleaaBetJhZRHkDwgmoFeztsDPChvj9SpBNXT15s7Tw=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=Yuo+RGKp9Eq7ugKI4stByHStDkFrMTUWa3fzhIjxA/7Z4s2+0ziUl82Zka3aUUO0y/n2Uv23fU6dYrghIY/7jTXYbrXrknzyZVyb4ObJoMR6cKalZj2CTKADVi8jPCvsDB6n8xo9dBwoV+FNn7991Bf/Fh4pseqQbIVXjbnRDdpR6Rs30e4ZUsDWfz5rLPT1fXlNwZ9AJIcXLcRyIznwYlltmavapTwS0djsVDCdtb+K8pvAhl1THiHHXrI6ido8U8rKpUZAQG0oCq1QVYzD9pwXHrT7mAavqNN9THMEzdaH2yNgdAzqPXS4gm+CpQq8UEmbrnjsuwx1vpV142iFzA== Received: from [106.10.166.113] by nm22.bullet.mail.sg3.yahoo.com with NNFMP; 25 Apr 2017 04:22:10 -0000 Received: from [106.10.151.254] by tm2.bullet.mail.sg3.yahoo.com with NNFMP; 25 Apr 2017 04:22:10 -0000 Received: from [127.0.0.1] by omp1003.mail.sg3.yahoo.com with NNFMP; 25 Apr 2017 04:22:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 962158.19623.bm@omp1003.mail.sg3.yahoo.com X-YMail-OSG: zDpmtawVM1mxHES13fURZvTt5l5oSJPQGQEZ4UR_74Td8xqanFMMY.XKsIbJKPi HwVRXw2X9lgwZQf3Jnf5EabO8QmiDqc_jKeuh4NorHc8.SP4BEg5o6lLgrVFkhXamI1U0fnV_Lmv blS1FdMCm6f3VBdm.YjbVenOzr51mTMQlWwJfXdwEOKwv_e1JhhNJQNQXl2qwjCkZSAyfrXtw1DG gqpWzIAgrV6dE9eVvbDwDtL4N0wgIYVSv4p_.4nwa3mVzQzYba13FPlM7uV49InLRJy4O0nmxk3R WigXNWr4mNyjPsJZnSykOViOjBFruSbmTCMVpbVK.pHh2JPXWP06SumrnATAGVg2vfoGg4azPCDr 2azoGuPp05QJT3_emz0xGEeecD.1aWq04NMAAPw5YeqL89lZMYnK5mvXJQKosDl.K4fhZEZRlLJG 7wyglupg5wczOCZ2oLtKbNh7yA.zdCh45B3OdzSgreXr3TO5TRXDM_.v2QNa4wexAh_URPw.4m9M xh3d3sMKBfyFYX_pMNKSNSd9E Received: from jws600031.mail.sg3.yahoo.com by sendmailws114.mail.sg3.yahoo.com; Tue, 25 Apr 2017 04:22:10 +0000; 1493094130.590 Date: Tue, 25 Apr 2017 04:21:53 +0000 (UTC) From: Binu Ramakrishnan Reply-To: Binu Ramakrishnan To: "uta@ietf.org" Message-ID: <1706958889.8319848.1493094113668@mail.yahoo.com> In-Reply-To: <271D533C-7C48-438C-8BBE-0EEC0DFB92DF@dukhovni.org> References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> <907547420.8067868.1493073246224@mail.yahoo.com> <271D533C-7C48-438C-8BBE-0EEC0DFB92DF@dukhovni.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8319847_287722899.1493094113665" X-Mailer: WebService/1.1.9408 YahooMailNeo Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.1 Safari/603.1.30 Archived-At: Subject: Re: [Uta] smtp-sts-04 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: Tue, 25 Apr 2017 04:22:15 -0000 ------=_Part_8319847_287722899.1493094113665 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As an engineer I agree with you and would be hesitant to add additional dep= endencies to my software. But when we talk about IETF and standards, is it = not better to promote widely accepted syntax/format? Wondering why IETF=C2=A0doesn't have a RFC doc for kv pair syntax. thanks-binu From: Viktor Dukhovni To: uta@ietf.org=20 Sent: Monday, 24 April 2017 3:49 PM Subject: Re: [Uta] smtp-sts-04 JSON =20 > On Apr 24, 2017, at 6:34 PM, Binu Ramakrishnan wrote: >=20 > IMO the main hurdle with key-value format is that we do not have a standa= rd > format, and by extension off-the-shelf library support. So the question i= s > - whether to write custom kv parsers or use a standard format - JSON. SMTP MTAs already parse key-value pairs in EHLO responses, and ESMTP extensions to the MAIL FROM and RCPT TO commands.=C2=A0 No additional code is required to do similar parsing of the policy in question. JSON is not a standard "format" it is a general syntax, that can=20 represent a stream of composite objects.=C2=A0 This is a poor fit in terms of the libraries needed to support JSON and having to deal with attributes that hold the wrong kind of data (list instead of scalar) or multiple objects instead of one... --=20 =C2=A0=C2=A0=C2=A0 Viktor. _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta =20 ------=_Part_8319847_287722899.1493094113665 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As an engineer I agree with you and would be hesitant to add addit= ional dependencies to my software. But when we talk about IETF and standard= s, is it not better to promote widely accepted syntax/format?
<= div id=3D"yui_3_16_0_ym19_1_1492819511003_43035">
Wondering why IETF doesn't have a RFC do= c for kv pair syntax.

thanks
<= div id=3D"yui_3_16_0_ym19_1_1492819511003_43035">-binu


From: = Viktor Dukhovni <ietf-dane@dukhovni.org>
To: uta@ietf.org
Sent: Monday, 24 April 2017 3:49 PM
Subject: Re: [Uta] smtp-s= ts-04 JSON


> On Apr 24, 2017, at 6:34 PM, = Binu Ramakrishnan <prbinu@yahoo.com> wrote:
>
> IMO the main hurdle with key-value f= ormat is that we do not have a standard
> format, and = by extension off-the-shelf library support. So the question is
> - whether to write custom kv parsers or use a standard format - = JSON.

SMTP MTAs already parse key-valu= e pairs in EHLO responses, and ESMTP
extensions to the MA= IL FROM and RCPT TO commands.  No additional code
is= required to do similar parsing of the policy in question.

JSON is not a standard "format" it is a general syntax= , that can
represent a stream of composite objects. = ; This is a poor fit in
terms of the libraries needed to = support JSON and having to deal
with attributes that hold= the wrong kind of data (list instead
of scalar) or multi= ple objects instead of one...


--
  &n= bsp; Viktor.

_________________________= ______________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/ma= ilman/listinfo/uta


=
------=_Part_8319847_287722899.1493094113665-- From nobody Mon Apr 24 22:20: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 C3125126C25 for ; Mon, 24 Apr 2017 22:20: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 TaNdFPmwPZMM for ; Mon, 24 Apr 2017 22:20:01 -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 3C0591319B7 for ; Mon, 24 Apr 2017 22:20:01 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (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 1B5577A32F1 for ; Tue, 25 Apr 2017 05:20: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: <1706958889.8319848.1493094113668@mail.yahoo.com> Date: Tue, 25 Apr 2017 01:19:59 -0400 Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Message-Id: <3BFAA188-A456-4159-B529-1CB1EFA4AAA5@dukhovni.org> References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> <907547420.8067868.1493073246224@mail.yahoo.com> <271D533C-7C48-438C-8BBE-0EEC0DFB92DF@dukhovni.org> <1706958889.8319848.1493094113668@mail.yahoo.com> To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] smtp-sts-04 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: Tue, 25 Apr 2017 05:20:03 -0000 > On Apr 25, 2017, at 12:21 AM, Binu Ramakrishnan wrote: > > As an engineer I agree with you and would be hesitant to add additional > dependencies to my software. But when we talk about IETF and standards, > is it not better to promote widely accepted syntax/format? That should be sufficient. We should use the simplest thing that does the job and no simpler. Key-value fits the bill. > Wondering why IETF doesn't have a RFC doc for kv pair syntax. There's no reason for an RFC to describe trivial lists of pairs. In ESMTP some of the values are xtext encoded, because the context is restricted to US-ASCII and does not permit whitespace in the values. Here, if we emit one KV pair per line, there's no need for xtext. The simplest design (perhaps either LF or CRLF terminated) is to one line per item of multi-valued attributes like "mx". That way, there's no need to parse internal delimiters in a value list. version STSv1 ... mx smtp1.example.com mx smtp2.example.com ... -- Viktor. From nobody Tue Apr 25 05:05: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 D29DB12EC56 for ; Tue, 25 Apr 2017 05:05:12 -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, RP_MATCHES_RCVD=-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=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 bU5QkF-fO-ey for ; Tue, 25 Apr 2017 05:05:11 -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 C4DE712EC54 for ; Tue, 25 Apr 2017 05:05:10 -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=1493121910; x=1524657910; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ACVsP+teOW8Tfoj55SaUZmaKfIuIkeQrze/HfHE4wsE=; b=ehiXrUiK64yISYT5QizIXlUPxVAtG8LD/Z464ESK38CkauMVYLbD0VmW 4t7AP2zf1fuA1kVB2jvGrbv8XCOTqF4LrJXhSnrkB78JMrygaNOZWF/rl keJS67059Lc/YvqSDe1cLTb5djTBXjvloDQuBShzU/Ppma1njcFoYTN3v CMpp/h5C7j/7bIA8tXAuXX+HqjRYeSnJs0VoPIJz86XnOZcQs2xEe1hYb UgE6znbZmEbrzODKLSR6S3zaleLxhgcb4DeHHu3kuAKLgrW2EWTaDWdRM YS6G1QV0GifpVjx9sMNeE6CUhaoBZ5amNyZVf8Z2UwVOtT5RAMBArwFBO w==; X-IronPort-AV: E=Sophos;i="5.37,249,1488798000"; d="scan'208";a="151488207" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from uxcn13-ogg-b.uoa.auckland.ac.nz ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 26 Apr 2017 00:05:08 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.3) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Apr 2017 00:05:08 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92%14]) with mapi id 15.00.1263.000; Wed, 26 Apr 2017 00:05:08 +1200 From: Peter Gutmann To: "uta@ietf.org" Thread-Topic: [Uta] back to smtp-sts-04 Thread-Index: AQHSu47czL90jqtgOkSZJiQUBJW6XaHV//8f Date: Tue, 25 Apr 2017 12:05:07 +0000 Message-ID: <1493121905461.20126@cs.auckland.ac.nz> References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> , In-Reply-To: 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] back to smtp-sts-04 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, 25 Apr 2017 12:05:13 -0000 Viktor Dukhovni writes:=0A= =0A= >Here are the line counts for the "*.[ch]" files from what appears to be a= =0A= >popular JSON parsing API for C:=0A= >[...]=0A= >That does not jive with relatively easy to parse...=0A= =0A= JSON is simple to parse in the same way that LDAP is lightweight, CIFS is= =0A= common, and anything whose name begins with "People's Democratic Republic o= f"=0A= is neither of the people, democratic, or a republic.=0A= =0A= Peter.=0A= = From nobody Tue Apr 25 05:31: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 6432412EC6B for ; Tue, 25 Apr 2017 05:31: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=akamai.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 r82rSshJn9wl for ; Tue, 25 Apr 2017 05:31:29 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 AD1CD12EB32 for ; Tue, 25 Apr 2017 05:31:29 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v3PCRZPS019403 for ; Tue, 25 Apr 2017 13:31:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=tTyz2pfk/UDcESNvZruVNv2eHq8fC2kUlRoOwLHFca8=; b=hlXBd1hM9Dzrwn89hNUYdAa5XmhdDmP11WEr5HQHUtVDFPHZdeoov1meELPgf4p9K2wU soDWrmetE5Y6RUwVdg6oHD2mhz+YimNfnaNT729VscVe2aaDZeD0J8rs/0WzeGhXiUd3 GdDdfu5AL4W8Ft9OlKAgt+Yc1HiOyyFvcKP5fCSxldgtzcOaMua9T/VgtNQI3+irba5q gZHBeJ2r7KaNJJtxlq0Y5eOtjcn0QlKk+EpBO5f0t/eiFxu3oRgV5B9YTGPZ0FWSF30E 2PwqIx2JHsTVdWA90HdQlfJm3/9vFAkheaD0AKPNh1E4Zo/P0owu0/8BkxC175zCJKV2 cQ== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2a22q19rds-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 25 Apr 2017 13:31:27 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v3PCV1Z4028220 for ; Tue, 25 Apr 2017 08:31:26 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2a02gvm9ah-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 25 Apr 2017 08:31:26 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 25 Apr 2017 08:31:25 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 25 Apr 2017 08:31:24 -0400 From: "Salz, Rich" To: "uta@ietf.org" Thread-Topic: [Uta] smtp-sts-04 JSON Thread-Index: AQHSu91/8Hbw5ZA8kUC6IhF1mlTclaHTKzAAgAI15gCAAARVAIAAXNeAgAAQO4CAADVVAA== Date: Tue, 25 Apr 2017 12:31:24 +0000 Message-ID: <13bc4a95d8a44bb8a40a0fbb75eb6221@usma1ex-dag1mb1.msg.corp.akamai.com> References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> <907547420.8067868.1493073246224@mail.yahoo.com> <271D533C-7C48-438C-8BBE-0EEC0DFB92DF@dukhovni.org> <1706958889.8319848.1493094113668@mail.yahoo.com> <3BFAA188-A456-4159-B529-1CB1EFA4AAA5@dukhovni.org> In-Reply-To: <3BFAA188-A456-4159-B529-1CB1EFA4AAA5@dukhovni.org> 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: [172.19.33.199] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-25_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704250226 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-25_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704250225 Archived-At: Subject: Re: [Uta] smtp-sts-04 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: Tue, 25 Apr 2017 12:31:31 -0000 > > Wondering why IETF doesn't have a RFC doc for kv pair syntax. >=20 > There's no reason for an RFC to describe trivial lists of pairs. Sure there is, because folks will want whitespace, want to linearize it, su= pport Unicode, etc. The MIME parameter lists, maybe? From nobody Tue Apr 25 07:20:40 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 0E7AF131462 for ; Tue, 25 Apr 2017 07:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gzyHpvZam_t for ; Tue, 25 Apr 2017 07:20:37 -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 5BED2131453 for ; Tue, 25 Apr 2017 07:20:37 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (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 A389D7A32F1 for ; Tue, 25 Apr 2017 14:20:36 +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: <13bc4a95d8a44bb8a40a0fbb75eb6221@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Tue, 25 Apr 2017 10:20:35 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: <50C47476-2C98-4C65-B6AC-43C166771369@dukhovni.org> References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> <907547420.8067868.1493073246224@mail.yahoo.com> <271D533C-7C48-438C-8BBE-0EEC0DFB92DF@dukhovni.org> <1706958889.8319848.1493094113668@mail.yahoo.com> <3BFAA188-A456-4159-B529-1CB1EFA4AAA5@dukhovni.org> <13bc4a95d8a44bb8a40a0fbb75eb6221@usma1ex-dag1mb1.msg.corp.akamai.com> To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] smtp-sts-04 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: Tue, 25 Apr 2017 14:20:39 -0000 > On Apr 25, 2017, at 8:31 AM, Salz, Rich wrote: >=20 >>=20 >> There's no reason for an RFC to describe trivial lists of pairs. >=20 > Sure there is, because folks will want whitespace, want to linearize = it, support Unicode, etc. As soon as you ask for a generally applicable syntax you end with ASN.1, JSON, XML, ... There's no shortage of power tools, but our needs here are trivial, and the sensible thing to do is to specify the simplest grammar that meets all the needs. * No nested lists * No multiple objects * No DTDs * No separate string, array, integer types * No complex libraries with CVEs = (https://www.suse.com/security/cve/CVE-2015-8863/) Parsing a line that contains a key and a value is trivial. There's a = bit of mostly irrelevant bike-shedding over whether that syntax should be: 1* VALUE 0* or 0* =3D 0* 0* where is either of or just , and each character of KEY and VALUE is ASCII alphanumeric or one of ".", "-", "+". The value encoding is "xtext" from https://tools.ietf.org/html/rfc3461#section-4, but none of the STSv1 keys require or shall permit hex-encoded xtext characters. Thus "+" may appear only in presently ignored keys from some future update of the protocol in which some additional policy element requires extended characters. Therefore parsers don't need, and will likely never need to actually implement xtext, that's just there to avoid objections that we may need (however unlikely) something more general some day. Speaking of extensibility, I don't see any reasonable migration path from STSv1 to STSv2, except by changing the .well-known URI, in which case putting the version in the policy, rather than the URL is of little value. I doubt any site will want to shut out all the deployed STSv1 clients by switching to a hypothetical STSv2. Therefore, we can either put a list of supported STS versions in the DNS TXT record or live with STSv1 for ever (likely the simplest approach, just add more key/value pairs as needed and maintain a backwards compatible interface). A needlessly complex alternative is either multiple blocks of key/value pairs separated by a blank line with block specific to its own STS version, which must come first, or, worse still, a list of JSON objects. --=20 Viktor.= From nobody Tue Apr 25 08:09:44 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 2C2E4131BFF for ; Tue, 25 Apr 2017 08:09:42 -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 vmjBj3hb1ipX for ; Tue, 25 Apr 2017 08:09: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 4EDF7131BC9 for ; Tue, 25 Apr 2017 08:08:33 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (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 6BB867A32F1 for ; Tue, 25 Apr 2017 15:08:32 +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: Tue, 25 Apr 2017 11:08:31 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] 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, 25 Apr 2017 15:09:42 -0000 > On Apr 23, 2017, at 8:42 AM, Daniel Margolis = wrote: >=20 >>>> How does a domain get rid of its STS policy? I thought we had = discussed >>>> using "max_age =3D 0" for this, which after being in place long = enough to >>>> assure that all previously cached policies have expired can be = removed. >>>> Or might just "404" suffice >>>=20 >>> Yes, I remember discussing this. But I am not sure such a mechanism = is needed. >>=20 >> I rather think it is needed. When a domain changes hands, or no = longer wishes >> to deal with the hassles of certificate expiration, it must be = possible to >> revoke the policy. >>=20 >>> 1. Domains can publish a "report" policy (with or without a TLSRPT = record!) >>> with a low expiration >>=20 >> What happens when that expires? It is again found and refreshed = unless there's >> a way to ultimate say "no policy". >=20 > Sure, but as I explained, given any hypothetical "opt-out" mechanism, = it is > theoretically not possible to design one which you do not have to keep = publishing > until $time_you_last_had_a_different_policy + $that_policy's_max_age = has passed. That's not the problem. The problem is that even after that time = expires the current specification does not appear to provide a means to *ever* stop = publishing a policy. A "report" policy will get cached and then be subject to = another timer, lather/rinse/repeat. How does the "report" policy ever transition out = of existence, without looking like a downgrade attack? Are you suggesting to rely just on eventual flushing of expired cache = entries that fail to refresh? And in the mean-time clients may burn some cycles = keeping reporting data that is unwanted, and may never be sent. There ought to be a way to cleanly stop the process without failing = retries at the end of the cycle. A "max_age =3D 0" should suffice (published for the = previous max_age + DNS TTL). --=20 Viktor.= From nobody Tue Apr 25 09:40:44 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 8CE331316A6 for ; Tue, 25 Apr 2017 09:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.591 X-Spam-Level: * X-Spam-Status: No, score=1.591 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 fWg79zjG7Jzc for ; Tue, 25 Apr 2017 09:40:40 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0108.outbound.protection.outlook.com [104.47.34.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B9C131618 for ; Tue, 25 Apr 2017 09:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0BttmixP6oOGwMz5gRjZPVOzXGlDThnoGIVG/DBn5WM=; b=JJeczWFZpk+rODZnTtBnNac7kIMOxTzeTiRMihwJVrmizxUQtRkhCZMw7plXs07qRFQztKgiMOo9OOyCmCXr/kq8wCPOQJ6LjQFPLbR/wmLg1NuIh9Ydxame6zzcgZoAOfO00CO+qdNmlP9uXsGRgcKZFh/ioJhHUhbo6Ve8UEY= Received: from SN2PR03MB2318.namprd03.prod.outlook.com (10.166.210.27) by SN2PR03MB2320.namprd03.prod.outlook.com (10.166.210.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Tue, 25 Apr 2017 16:40:38 +0000 Received: from SN2PR03MB2318.namprd03.prod.outlook.com ([10.166.210.27]) by SN2PR03MB2318.namprd03.prod.outlook.com ([10.166.210.27]) with mapi id 15.01.1047.019; Tue, 25 Apr 2017 16:40:39 +0000 From: Janet Jones To: Daniel Margolis , Alexey Melnikov CC: "uta@ietf.org" Thread-Topic: [Uta] Review of draft-ietf-uta-mta-sts-04 Thread-Index: AQHSuPz575MVwH2I7EKWfa8ep5y2caHS39uAgANy8sA= Date: Tue, 25 Apr 2017 16:40:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:9::ee] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2320; 7:uVBT64F3a6qqV4O0VMkE5roAPgkkgw1AYQZtYfY8dQ05muf+l1smC8eUvUrNe8qnu4hBTMxlb9Tyd42YSCtdZBWTyf5wdfya+u30mtWbiilZFhNTrNTCVJhBmiZQVtrOUFK8AibEZY6ISZzsqEfO3VySlHIWtOr6nS2al2gXsV7FShI8ALOHFzUUscIXas4fgWhk9zQ0sCSTh3RJPv4VkdAlSky2+Q3/sYZYprvnNVt67D5oXMDx1hodFyPNRXicAVUSFOINfZIG8syzcgqyAXIkhtx+sl0iHIsuD4pa1EQxXDNkMFGABhVXS/O72gVOWvqVvBxq4IiuNYyUtgHSzCB6m/JTKwUv4B4bRT05bsQ= x-ms-office365-filtering-correlation-id: b87e91af-4952-4c6e-3d3e-08d48bf9ce63 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:SN2PR03MB2320; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(189930954265078)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:SN2PR03MB2320; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2320; x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39400400002)(39410400002)(39840400002)(39860400002)(39450400003)(24454002)(377454003)(53546009)(6246003)(76176999)(236005)(3280700002)(5660300001)(9686003)(54356999)(790700001)(86612001)(50986999)(102836003)(25786009)(6116002)(2900100001)(8936002)(74316002)(230783001)(10090500001)(86362001)(2906002)(81166006)(5005710100001)(9326002)(53936002)(3660700001)(7736002)(77096006)(8676002)(122556002)(33656002)(38730400002)(7696004)(19609705001)(606005)(7906003)(6436002)(189998001)(6506006)(54896002)(4326008)(2950100002)(55016002)(99286003)(229853002)(6306002)(10290500003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR03MB2320; H:SN2PR03MB2318.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2318B66DDAB5684C346B77BEE61E0SN2PR03MB2318namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2017 16:40:39.0589 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2320 Archived-At: Subject: Re: [Uta] Review of draft-ietf-uta-mta-sts-04 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, 25 Apr 2017 16:40:42 -0000 --_000_SN2PR03MB2318B66DDAB5684C346B77BEE61E0SN2PR03MB2318namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxleGV5LA0KDQpSZXNlbmRpbmcgbGlua3MgdG8gY2xvc2VkIGlzc3VlcyAgYW5kIGN1cnJl bnQgcHVsbCByZXF1ZXN0cyB0byBiZSBpbmNvcnBvcmF0ZWQgYmFzZWQgb24gZmVlZGJhY2suDQoN Cmh0dHBzOi8vZ2l0aHViLmNvbS9tcmlzaGVyL3NtdHAtc3RzL2lzc3Vlcw0KDQpodHRwczovL2dp dGh1Yi5jb20vbXJpc2hlci9zbXRwLXN0cy9wdWxscw0KDQpUaGFua3MgYWdhaW4gZm9yIHlvdXIg ZmVlZGJhY2shDQpKYW5ldA0KDQoNCkZyb206IFV0YSBbbWFpbHRvOnV0YS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgRGFuaWVsIE1hcmdvbGlzDQpTZW50OiBTdW5kYXksIEFwcmlsIDIz LCAyMDE3IDQ6NTggQU0NClRvOiBBbGV4ZXkgTWVsbmlrb3YgPGFsZXhleS5tZWxuaWtvdkBpc29k ZS5jb20+DQpDYzogdXRhQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1V0YV0gUmV2aWV3IG9mIGRy YWZ0LWlldGYtdXRhLW10YS1zdHMtMDQNCg0KVGhhbmtzLiBDb21tZW50cyBpbmxpbmUsIG1vc3Rs eSB0aWNraW5nIG9mZiBjaGFuZ2VzLiA6KQ0KDQpJIGhhdmUgcHVzaGVkIGFsbCBteSBjaGFuZ2Vz IGluIHJlc3BvbnNlIHRvIHRoaXMgdG8gdGhlIGdpdCByZXBvIGFuZCB0aGV5IHNob3VsZCBhcHBl YXIgaW4gb3VyIG5leHQgZHJhZnQuDQoNCg0KT24gV2VkLCBBcHIgMTksIDIwMTcgYXQgMTowNSBQ TSwgQWxleGV5IE1lbG5pa292IDxhbGV4ZXkubWVsbmlrb3ZAaXNvZGUuY29tPG1haWx0bzphbGV4 ZXkubWVsbmlrb3ZAaXNvZGUuY29tPj4gd3JvdGU6DQpIaSwNCkJlbG93IGlzIG15IGVhcmx5ICJB RCByZXZpZXciIG9mIHRoZSBkb2N1bWVudC4gSSB0aGluayBpdCBpcyBpbiBwcmV0dHkgZ29vZCBz aGFwZSBhbmQgaXMgcmVhZHkgZm9yIFdHIExhc3QgQ2FsbCAoSSBhbSBPayB3aXRoIHRoZSBxdWVz dGlvbiBvZiBKU09OIHZlcnNhIHNvbWV0aGluZyBlbHNlIGJlIHNldHRsZWQgZHVyaW5nIG9yIGFm dGVyIFdHTEMuKQ0KDQoxKSBJbiAxLjE6DQoNCiAgIG8gIFBvbGljeSBEb21haW46IFRoZSBkb21h aW4gZm9yIHdoaWNoIGFuIE1UQS1TVFMgUG9saWN5IGlzIGRlZmluZWQuDQogICAgICBUaGlzIGlz IHRoZSBuZXh0LWhvcCBkb21haW47IHdoZW4gc2VuZGluZyBtYWlsIHRvDQogICAgICAiYWxpY2VA ZXhhbXBsZS5jb208bWFpbHRvOmFsaWNlQGV4YW1wbGUuY29tPiIgdGhpcyB3b3VsZCBvcmRpbmFy bHkgYmUgImV4YW1wbGUuY29tPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZleGFtcGxlLmNvbSZkYXRhPTAyJTdDMDElN0NKYW5l dC5Kb25lcyU0MG1pY3Jvc29mdC5jb20lN0M4ZjlhNTVkZTZhZjk0N2FjNTQ1NTA4ZDQ4YTQwMTRm NyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYyODU0NTUy Mzk0MTk1OTgmc2RhdGE9TVZ5YWx3QVl2OXlmUGVXbThScEsyQ3FhMnpWUUVZaFFsVlR5TVJKbFd2 ZyUzRCZyZXNlcnZlZD0wPiIsIGJ1dA0KICAgICAgdGhpcyBtYXkgYmUgb3ZlcnJpZGVuIGJ5IGV4 cGxpY2l0IHJvdXRpbmcgcnVsZXMgKGFzIGRlc2NyaWJlZCBpbg0KICAgICAgIlBvbGljeSBTZWxl Y3Rpb24gZm9yIFNtYXJ0IEhvc3RzIikuDQoNCk5pdDogVGhpcyBuZWVkcyBhbiBpbnRlcm5hbCBz ZWN0aW9uIHJlZmVyZW5jZS4NCkkgdGhpbmsgdGhlcmUgd2FzIGFub3RoZXIgcGxhY2UgaW4gdGhl IGRvY3VtZW50IHdoZW4gYW4gaW50ZXJuYWwgc2VjdGlvbiBudW1iZXIgaXMgbm90IG1lbnRpb25l ZC4NCg0KRG9uZS4gVGhhbmtzLg0KDQoNCjIpIEluIDMuMToNCg0KICAgICAgc3RzLXZlcnNpb24g ICAgID0gInYiICpXU1AgIj0iICpXU1AgJXg1MyAleDU0ICAgICAgICA7ICJTVFN2MSINCiAgICAg ICAgICAgICAgICAgICAgICAgICV4NTMgJXg3NiAleDMxDQoNCkRvIHlvdSBpbnRlbmQgZm9yIHRo aXMgdG8gYmUgbWF0Y2hlZCBjYXNlLXNlbnNpdGl2ZWx5Pw0KV2hhdCB5b3Ugd3JvdGUgYWJvdmUg aXMgdGhhdCAidiIgaXMgY2FzZS1pbnNlbnNpdGl2ZSwgYnV0ICJTVFN2MSIgaXMuDQoNCkdvb2Qg cG9pbnQuIEkgYWN0dWFsbHkgd291bGQgaGF2ZSBpbnRlbmRlZCB0aGUgZmllbGQgbmFtZXMgdG8g YWxzbyBiZSBjYXNlLXNlbnNpdGl2ZS4gKEF0IGFueSByYXRlLCB0aGUgY29kZSBJIGhhdmUgaXMg Y2FzZSBzZW5zaXRpdmUuKSBJIHNlZSBubyByZWFzb24gdG8gdG9sZXJhdGUgbWl4ZWQgY2FzZSBo ZXJlIGdpdmVuIHdlJ3JlIHJlcXVpcmluZyBzcGVjaWZpYyBzdHJpbmdzIGFueXdheS4NCg0KDQoz KSBTZWN0aW9uIDMuMiBzYXlzIHRoYXQgdW5yZWNvZ25pemVkIGZpZWxkcyBhcmUgdG8gYmUgaWdu b3JlZCwgc28geW91IG5lZWQgdG8gdXBkYXRlIEFCTkYgaW4gMy4xIHRvIG1ha2UgaXQgY2xlYXIu DQoNCkN1cnJlbnQgQUJORjoNCg0KICAgICAgc3RzLXRleHQtcmVjb3JkID0gc3RzLXZlcnNpb24g KldTUCAleDNCICpXU1Agc3RzLWlkIFsleDNCXQ0KDQogICAgICBzdHMtdmVyc2lvbiAgICAgPSAi diIgKldTUCAiPSIgKldTUCAleDUzICV4NTQgICAgICAgIDsgIlNUU3YxIg0KICAgICAgICAgICAg ICAgICAgICAgICAgJXg1MyAleDc2ICV4MzENCg0KICAgICAgc3RzLWlkICAgICAgICAgID0gImlk IiAqV1NQICI9IiAqV1NQIDEqMzIoQUxQSEEgLyBESUdJVCkNCg0KSSBzdWdnZXN0IHNvbWV0aGlu ZyBsaWtlIHRoZSBmb2xsb3dpbmcgKHRoaXMgaW1wbGllcyB0aGF0IHBvc2l0aW9uIG9mIHRoZSBm aXJzdCAyIGZpZWxkcyBpcyBmaXhlZCwgZXh0ZW5zaW9ucyBhdCB0aGUgZW5kLiBJZiB5b3UgcHJl ZmVyIHRoYXQgYW55IGZpZWxkcyBhcmUgaW4gYW55IG9yZGVyIChvdGhlciB0aGFuIHRoZSB2ZXJz aW9uKSwgSSBjYW4gdXBkYXRlIHRoZSBBQk5GKToNCg0KR29vZCBwb2ludC4NCg0KTG9va2luZyBh dCBTUEYsIERNQVJDLCBhbmQgREtJTSwgYWxsIHRocmVlIHJlcXVpcmUgdGhlIHY9IHRvIGJlIGZp cnN0IGluIHRoZSByZWNvcmQgKHdoaWNoIG1ha2VzIHNvbWUgc2Vuc2UsIEkgc3VwcG9zZSwgdG8g YWxsb3cgZnV0dXJlIHZlcnNpb25zIHRvIGhhdmUgZGlmZmVyZW50IHBhcnNpbmcgc3ludGF4ZXMp LCBzbyBJIHN1cHBvc2Ugd2UgY2FuIGp1c3Qga2VlcCBpdCBhcyB5b3UgaGF2ZSBpdCBoZXJlLiBU aGFua3MgZm9yIHRoYXQhDQoNCg0KICAgICAgc3RzLXRleHQtcmVjb3JkID0gc3RzLXZlcnNpb24g KldTUCBmaWVsZC1kZWxpbSAqV1NQIHN0cy1pZCBbZmllbGQtZGVsaW0gW3N0cy1leHRlbnNpb25z XV0NCg0KICAgICAgZmllbGQtZGVsaW0gICAgID0gJXgzQg0KDQogICAgICBzdHMtdmVyc2lvbiAg ICAgPSAidiIgKldTUCAiPSIgKldTUCAleDUzICV4NTQgICAgICAgIDsgIlNUU3YxIg0KICAgICAg ICAgICAgICAgICAgICAgICAgJXg1MyAleDc2ICV4MzENCg0KICAgICAgc3RzLWlkICAgICAgICAg ID0gImlkIiAqV1NQICI9IiAqV1NQIDEqMzIoQUxQSEEgLyBESUdJVCkNCg0KICAgICAgc3RzLWV4 dGVuc2lvbnMgID0gc3RzLWV4dGVuc2lvbiAqKGZpZWxkLWRlbGltIHN0cy1leHRlbnNpb24pIFtm aWVsZC1kZWxpbV0NCiAgICAgICAgICAgICAgICAgICAgICAgIDsgRXh0ZW5zaW9uIGZpZWxkcyBh dCB0aGUgZW5kIGluIGFueSBvcmRlcg0KDQogICAgICBzdHMtZXh0ZW5zaW9uICAgPSBzdHMtZXh0 LW5hbWUgKldTUCAiPSIgKldTUCBzdHMtZXh0LXZhbHVlDQoNCiAgICAgIHN0cy1leHQtbmFtZSAg ICA9IChBTFBIQSAvIERJR0lUKSAqMzEoQUxQSEEgLyBESUdJVCAvICJfIiAvICItIiAvICIuIikN Cg0KICAgICAgc3RzLWV4dC12YWx1ZSAgID0gMSooJXgyMS0zQSAvICV4M0MgLyAleDNFLTdFKQ0K ICAgICAgICAgICAgICAgICAgICAgICAgOyBsaWtlIGVzbXRwLXZhbHVlIGZyb20gUkZDIDUzMjEs IGJ1dCBkb2Vzbid0IGFsbG93ICI7Ii4NCiAgICAgICAgICAgICAgICAgICAgICAgIDsgU28gYmFz aWNhbGx5IGFueSBDSEFSIGV4Y2x1ZGluZyAiPSIsICI7IiwgU1AsIGFuZCBjb250cm9sDQogICAg ICAgICAgICAgICAgICAgICAgICA7IGNoYXJhY3RlcnMuDQoNCjQpIEluIDMuMjogU2hvdWxkICJT SE9VTEQgaWdub3JlIHVucmVjb2duaXplZCBmaWVsZHMiIGJlIGEgTVVTVD8gSS5lLiwgd2h5IHdv dWxkIGl0IG5vdCBiZSBPayB0byBpZ25vcmUgdW5yZWNvZ25pemVkIGZpZWxkcz8NCg0KSXQncyBh IGJ1Zy4gVGhhbmtzLiA6KQ0KDQoNCjUpIEluIDMuMzogUkZDIDYxMjUgdXNlIG5lZWRzIG1vcmUg ZGV0YWlscywgYmVjYXVzZSB5b3UgbmVlZCB0byBzcGVjaWZ5IGFuc3dlcnMgdG8gZXZlcnkgcXVl c3Rpb24gaW4gc2VjdGlvbiAzIG9mIFJGQyA2MTI1Lg0KSW4gcGFydGljdWxhciB5b3Ugc2hvdWxk IHNheSB0aGF0IHdoZW4gY2hlY2tpbmcgY2VydGlmaWNhdGVzLCB5b3Ugb25seSB1c2UgRE5TLUlE IGFuZCBDTi1JRCAoU1JWLUlEIGFuZCBVUkktSUQgYXJlIG5vdCB1c2VkKSBhbmQgdGhhdCB5b3Ug YWxsb3cgd2lsZGNhcmRzIGluIHRoZW0uDQoNClRoYW5rcywgSSd2ZSBjbGFyaWZpZWQgdGhpcy4N Cg0KNikgTGFzdCBwYXJhIG9uIHBhZ2UgNzogdGhpcyBpcyBhbHNvIHRydWUgaW4gUkZDIDYxMjUu DQoNCiBDb3JyZWN0Lg0KDQo3KSBJbiA1LjEsIGxhc3QgcGFyYTogSSB0aGluayB5b3UgbWVhbiB0 aGF0IGlmIHRoZXJlIGFyZSB0b28gbWFueSBmYWlsdXJlcyB0byBkZWxpdmVyIHdoZW4gdXNpbmcg TVRBLVNUUywgcmVndWxhciBTTVRQIHJ1bGVzIGZvciBnZW5lcmF0aW5nIGEgYm91bmNlIGFwcGx5 PyBJIHRoaW5rIHRoaXMgbmVlZHMgcmV3b3JkaW5nIHRvIHNheSB0aGF0Lg0KDQpGaXhlZCwgYW5k IGluY2x1ZGVkIGEgcmVmZXJlbmNlIHRvIHJmYzUzMjEncyByZWxldmFudCBzZWN0aW9uLCB0byBo b3BlZnVsbHkgbWFrZSBjbGVhciB3ZSBleHBlY3QgZXhpc3RpbmcgcnVsZXMgdG8gYXBwbHkuDQoN Cg0KOCkgSWYgeW91IHdhbnQgdG8gYWxsb3cgZm9yIGV4dGVuc2liaWxpdHksIHlvdSBwcm9iYWJs eSBuZWVkIGFuIElBTkEgcmVnaXN0cnkgb2YgZmllbGRzIGFsbG93ZWQsIHNvIHRoYXQgZGV2ZWxv cGVycyBjYW4gZmluZCB0aGVtIGVhc2lseS4gSSBjYW4gaGVscCB3aXRoIHNvbWUgdGV4dC4NCg0K SSdkIGFwcHJlY2lhdGUgYW55IHN1Z2dlc3Rpb25zLg0KDQpJcyB0aGVyZSBhIG5lZWQgZm9yIHRo YXQgbm93LCB0aG91Z2g/IEkgd291bGQgbm90IHdhbnQgdG8gb3ZlcmVuZ2luZWVyIHRoaXMsIGVp dGhlci4gOikNCg0KDQo5KSBPbiBwYWdlIDEzOiBJIHRoaW5rIHBzZXVkb2NvZGUgc2hvdWxkIG1h a2UgaXQgY2xlYXIgdGhhdCB5b3UgcmV0cmlldmUgRE5TLUlEIFNBTi4NCg0KVGhhbmtzLCBkb25l Lg0KDQoNCkJlc3QgUmVnYXJkcywNCkFsZXhleQ0KDQpQLlMuIEkgbWlnaHQgaGF2ZSBhIGNvdXBs ZSBvZiBleHRyYSBpdGVtcywgYnV0IEkgbmVlZCB0byBkb3VibGUgY2hlY2sgYSBmZXcgdGhpbmdz IGZpcnN0Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KVXRhIG1haWxpbmcgbGlzdA0KVXRhQGlldGYub3JnPG1haWx0bzpVdGFAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3V0YTxodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRm Lm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnV0YSZkYXRhPTAyJTdDMDElN0NKYW5ldC5Kb25l cyU0MG1pY3Jvc29mdC5jb20lN0M4ZjlhNTVkZTZhZjk0N2FjNTQ1NTA4ZDQ4YTQwMTRmNyU3Qzcy Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYyODU0NTUyMzk0MTk1 OTgmc2RhdGE9NnNqc0pQNWZ3Nm1GcXQ4RkJLSHdlQWVtTjElMkZoJTJGZDFHJTJCSFZWTnpqcGtR WSUzRCZyZXNlcnZlZD0wPg0KDQo= --_000_SN2PR03MB2318B66DDAB5684C346B77BEE61E0SN2PR03MB2318namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEFsZXhleSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmVzZW5kaW5n IGxpbmtzIHRvIGNsb3NlZCBpc3N1ZXMgJm5ic3A7YW5kIGN1cnJlbnQgcHVsbCByZXF1ZXN0cyB0 byBiZSBpbmNvcnBvcmF0ZWQgYmFzZWQgb24gZmVlZGJhY2suPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhy ZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9tcmlzaGVyL3NtdHAtc3RzL2lzc3VlcyI+aHR0cHM6Ly9n aXRodWIuY29tL21yaXNoZXIvc210cC1zdHMvaXNzdWVzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YSBo cmVmPSJodHRwczovL2dpdGh1Yi5jb20vbXJpc2hlci9zbXRwLXN0cy9wdWxscyI+aHR0cHM6Ly9n aXRodWIuY29tL21yaXNoZXIvc210cC1zdHMvcHVsbHM8L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5r cyBhZ2FpbiBmb3IgeW91ciBmZWVkYmFjayE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkphbmV0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBv c2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBVdGEgW21haWx0bzp1dGEtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+RGFuaWVsIE1hcmdvbGlzPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgQXByaWwg MjMsIDIwMTcgNDo1OCBBTTxicj4NCjxiPlRvOjwvYj4gQWxleGV5IE1lbG5pa292ICZsdDthbGV4 ZXkubWVsbmlrb3ZAaXNvZGUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gdXRhQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVXRhXSBSZXZpZXcgb2YgZHJhZnQtaWV0Zi11dGEtbXRh LXN0cy0wNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFu a3MuIENvbW1lbnRzIGlubGluZSwgbW9zdGx5IHRpY2tpbmcgb2ZmIGNoYW5nZXMuIDopJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg aGF2ZSBwdXNoZWQgYWxsIG15IGNoYW5nZXMgaW4gcmVzcG9uc2UgdG8gdGhpcyB0byB0aGUgZ2l0 IHJlcG8gYW5kIHRoZXkgc2hvdWxkIGFwcGVhciBpbiBvdXIgbmV4dCBkcmFmdC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBcHIgMTksIDIwMTcgYXQgMTowNSBQTSwg QWxleGV5IE1lbG5pa292ICZsdDs8YSBocmVmPSJtYWlsdG86YWxleGV5Lm1lbG5pa292QGlzb2Rl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFsZXhleS5tZWxuaWtvdkBpc29kZS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I aSw8YnI+DQpCZWxvdyBpcyBteSBlYXJseSAmcXVvdDtBRCByZXZpZXcmcXVvdDsgb2YgdGhlIGRv Y3VtZW50LiBJIHRoaW5rIGl0IGlzIGluIHByZXR0eSBnb29kIHNoYXBlIGFuZCBpcyByZWFkeSBm b3IgV0cgTGFzdCBDYWxsIChJIGFtIE9rIHdpdGggdGhlIHF1ZXN0aW9uIG9mIEpTT04gdmVyc2Eg c29tZXRoaW5nIGVsc2UgYmUgc2V0dGxlZCBkdXJpbmcgb3IgYWZ0ZXIgV0dMQy4pPGJyPg0KPGJy Pg0KMSkgSW4gMS4xOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtvJm5ic3A7IFBvbGljeSBEb21h aW46IFRoZSBkb21haW4gZm9yIHdoaWNoIGFuIE1UQS1TVFMgUG9saWN5IGlzIGRlZmluZWQuPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhpcyBpcyB0aGUgbmV4dC1ob3AgZG9tYWluOyB3aGVu IHNlbmRpbmcgbWFpbCB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90OzxhIGhyZWY9 Im1haWx0bzphbGljZUBleGFtcGxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFsaWNlQGV4YW1wbGUu Y29tPC9hPiZxdW90OyB0aGlzIHdvdWxkIG9yZGluYXJseSBiZSAmcXVvdDs8YSBocmVmPSJodHRw czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJG JTJGZXhhbXBsZS5jb20mYW1wO2RhdGE9MDIlN0MwMSU3Q0phbmV0LkpvbmVzJTQwbWljcm9zb2Z0 LmNvbSU3QzhmOWE1NWRlNmFmOTQ3YWM1NDU1MDhkNDhhNDAxNGY3JTdDNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjI4NTQ1NTIzOTQxOTU5OCZhbXA7c2RhdGE9 TVZ5YWx3QVl2OXlmUGVXbThScEsyQ3FhMnpWUUVZaFFsVlR5TVJKbFd2ZyUzRCZhbXA7cmVzZXJ2 ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmV4YW1wbGUuY29tPC9hPiZxdW90OywNCiBidXQ8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyB0aGlzIG1heSBiZSBvdmVycmlkZW4gYnkgZXhwbGljaXQgcm91 dGluZyBydWxlcyAoYXMgZGVzY3JpYmVkIGluPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1 b3Q7UG9saWN5IFNlbGVjdGlvbiBmb3IgU21hcnQgSG9zdHMmcXVvdDspLjxicj4NCjxicj4NCk5p dDogVGhpcyBuZWVkcyBhbiBpbnRlcm5hbCBzZWN0aW9uIHJlZmVyZW5jZS48YnI+DQpJIHRoaW5r IHRoZXJlIHdhcyBhbm90aGVyIHBsYWNlIGluIHRoZSBkb2N1bWVudCB3aGVuIGFuIGludGVybmFs IHNlY3Rpb24gbnVtYmVyIGlzIG5vdCBtZW50aW9uZWQuPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb25lLiBUaGFua3MuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjIpIEluIDMuMTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBzdHMt dmVyc2lvbiZuYnNwOyAmbmJzcDsgJm5ic3A7PSAmcXVvdDt2JnF1b3Q7ICpXU1AgJnF1b3Q7PSZx dW90OyAqV1NQICV4NTMgJXg1NCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA7ICZxdW90O1NU U3YxJnF1b3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJXg1MyAleDc2ICV4MzE8 YnI+DQo8YnI+DQpEbyB5b3UgaW50ZW5kIGZvciB0aGlzIHRvIGJlIG1hdGNoZWQgY2FzZS1zZW5z aXRpdmVseT88YnI+DQpXaGF0IHlvdSB3cm90ZSBhYm92ZSBpcyB0aGF0ICZxdW90O3YmcXVvdDsg aXMgY2FzZS1pbnNlbnNpdGl2ZSwgYnV0ICZxdW90O1NUU3YxJnF1b3Q7IGlzLjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R29vZCBw b2ludC4gSSBhY3R1YWxseSB3b3VsZCBoYXZlIGludGVuZGVkIHRoZSBmaWVsZCBuYW1lcyB0byBh bHNvIGJlIGNhc2Utc2Vuc2l0aXZlLiAoQXQgYW55IHJhdGUsIHRoZSBjb2RlIEkgaGF2ZSBpcyBj YXNlIHNlbnNpdGl2ZS4pIEkgc2VlIG5vIHJlYXNvbiB0byB0b2xlcmF0ZSBtaXhlZCBjYXNlIGhl cmUgZ2l2ZW4gd2UncmUgcmVxdWlyaW5nIHNwZWNpZmljIHN0cmluZ3MgYW55d2F5LiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQozKSBTZWN0aW9uIDMuMiBzYXlzIHRoYXQgdW5yZWNvZ25pemVkIGZpZWxkcyBhcmUg dG8gYmUgaWdub3JlZCwgc28geW91IG5lZWQgdG8gdXBkYXRlIEFCTkYgaW4gMy4xIHRvIG1ha2Ug aXQgY2xlYXIuPGJyPg0KPGJyPg0KQ3VycmVudCBBQk5GOjxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7IHN0cy10ZXh0LXJlY29yZCA9IHN0cy12ZXJzaW9uICpXU1AgJXgzQiAqV1NQIHN0 cy1pZCBbJXgzQl08YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBzdHMtdmVyc2lvbiZu YnNwOyAmbmJzcDsgJm5ic3A7PSAmcXVvdDt2JnF1b3Q7ICpXU1AgJnF1b3Q7PSZxdW90OyAqV1NQ ICV4NTMgJXg1NCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA7ICZxdW90O1NUU3YxJnF1b3Q7 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJXg1MyAleDc2ICV4MzE8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyBzdHMtaWQmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ID0gJnF1b3Q7aWQmcXVvdDsgKldTUCAmcXVvdDs9JnF1b3Q7ICpXU1AgMSozMihBTFBI QSAvIERJR0lUKTxicj4NCjxicj4NCkkgc3VnZ2VzdCBzb21ldGhpbmcgbGlrZSB0aGUgZm9sbG93 aW5nICh0aGlzIGltcGxpZXMgdGhhdCBwb3NpdGlvbiBvZiB0aGUgZmlyc3QgMiBmaWVsZHMgaXMg Zml4ZWQsIGV4dGVuc2lvbnMgYXQgdGhlIGVuZC4gSWYgeW91IHByZWZlciB0aGF0IGFueSBmaWVs ZHMgYXJlIGluIGFueSBvcmRlciAob3RoZXIgdGhhbiB0aGUgdmVyc2lvbiksIEkgY2FuIHVwZGF0 ZSB0aGUgQUJORik6PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Hb29kIHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Mb29raW5nIGF0IFNQRiwgRE1BUkMsIGFuZCBES0lN LCBhbGwgdGhyZWUgcmVxdWlyZSB0aGUgdj0gdG8gYmUgZmlyc3QgaW4gdGhlIHJlY29yZCAod2hp Y2ggbWFrZXMgc29tZSBzZW5zZSwgSSBzdXBwb3NlLCB0byBhbGxvdyBmdXR1cmUgdmVyc2lvbnMg dG8gaGF2ZSBkaWZmZXJlbnQgcGFyc2luZyBzeW50YXhlcyksIHNvIEkgc3VwcG9zZSB3ZSBjYW4g anVzdCBrZWVwIGl0IGFzIHlvdSBoYXZlIGl0IGhlcmUuDQogVGhhbmtzIGZvciB0aGF0ITxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBzdHMtdGV4dC1yZWNvcmQgPSBzdHMtdmVyc2lvbiAq V1NQIGZpZWxkLWRlbGltICpXU1Agc3RzLWlkIFtmaWVsZC1kZWxpbSBbc3RzLWV4dGVuc2lvbnNd XTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGZpZWxkLWRlbGltJm5ic3A7ICZuYnNw OyAmbmJzcDs9ICV4M0I8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBzdHMtdmVyc2lv biZuYnNwOyAmbmJzcDsgJm5ic3A7PSAmcXVvdDt2JnF1b3Q7ICpXU1AgJnF1b3Q7PSZxdW90OyAq V1NQICV4NTMgJXg1NCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA7ICZxdW90O1NUU3YxJnF1 b3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJXg1MyAleDc2ICV4MzE8YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBzdHMtaWQmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ID0gJnF1b3Q7aWQmcXVvdDsgKldTUCAmcXVvdDs9JnF1b3Q7ICpXU1AgMSozMihB TFBIQSAvIERJR0lUKTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHN0cy1leHRlbnNp b25zJm5ic3A7ID0gc3RzLWV4dGVuc2lvbiAqKGZpZWxkLWRlbGltIHN0cy1leHRlbnNpb24pIFtm aWVsZC1kZWxpbV08YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA7IEV4dGVuc2lvbiBm aWVsZHMgYXQgdGhlIGVuZCBpbiBhbnkgb3JkZXI8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyBzdHMtZXh0ZW5zaW9uJm5ic3A7ICZuYnNwOz0gc3RzLWV4dC1uYW1lICpXU1AgJnF1b3Q7 PSZxdW90OyAqV1NQIHN0cy1leHQtdmFsdWU8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyBzdHMtZXh0LW5hbWUmbmJzcDsgJm5ic3A7ID0gKEFMUEhBIC8gRElHSVQpICozMShBTFBIQSAv IERJR0lUIC8gJnF1b3Q7XyZxdW90OyAvICZxdW90Oy0mcXVvdDsgLyAmcXVvdDsuJnF1b3Q7KTxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHN0cy1leHQtdmFsdWUmbmJzcDsgJm5ic3A7 PSAxKigleDIxLTNBIC8gJXgzQyAvICV4M0UtN0UpPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgOyBsaWtlIGVzbXRwLXZhbHVlIGZyb20gUkZDIDUzMjEsIGJ1dCBkb2Vzbid0IGFsbG93 ICZxdW90OzsmcXVvdDsuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOyBTbyBiYXNp Y2FsbHkgYW55IENIQVIgZXhjbHVkaW5nICZxdW90Oz0mcXVvdDssICZxdW90OzsmcXVvdDssIFNQ LCBhbmQgY29udHJvbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDsgY2hhcmFjdGVy cy48YnI+DQo8YnI+DQo0KSBJbiAzLjI6IFNob3VsZCAmcXVvdDtTSE9VTEQgaWdub3JlIHVucmVj b2duaXplZCBmaWVsZHMmcXVvdDsgYmUgYSBNVVNUPyBJLmUuLCB3aHkgd291bGQgaXQgbm90IGJl IE9rIHRvIGlnbm9yZSB1bnJlY29nbml6ZWQgZmllbGRzPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQncyBhIGJ1Zy4gVGhhbmtz LiA6KSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo1KSBJbiAzLjM6IFJGQyA2MTI1IHVzZSBuZWVkcyBtb3JlIGRl dGFpbHMsIGJlY2F1c2UgeW91IG5lZWQgdG8gc3BlY2lmeSBhbnN3ZXJzIHRvIGV2ZXJ5IHF1ZXN0 aW9uIGluIHNlY3Rpb24gMyBvZiBSRkMgNjEyNS48YnI+DQpJbiBwYXJ0aWN1bGFyIHlvdSBzaG91 bGQgc2F5IHRoYXQgd2hlbiBjaGVja2luZyBjZXJ0aWZpY2F0ZXMsIHlvdSBvbmx5IHVzZSBETlMt SUQgYW5kIENOLUlEIChTUlYtSUQgYW5kIFVSSS1JRCBhcmUgbm90IHVzZWQpIGFuZCB0aGF0IHlv dSBhbGxvdyB3aWxkY2FyZHMgaW4gdGhlbS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcywgSSd2ZSBjbGFyaWZpZWQgdGhp cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+NikgTGFzdCBwYXJhIG9uIHBhZ2UgNzogdGhpcyBpcyBhbHNvIHRydWUgaW4gUkZDIDYx MjUuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDtDb3JyZWN0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj43KSBJbiA1LjEsIGxhc3QgcGFyYTogSSB0 aGluayB5b3UgbWVhbiB0aGF0IGlmIHRoZXJlIGFyZSB0b28gbWFueSBmYWlsdXJlcyB0byBkZWxp dmVyIHdoZW4gdXNpbmcgTVRBLVNUUywgcmVndWxhciBTTVRQIHJ1bGVzIGZvciBnZW5lcmF0aW5n IGEgYm91bmNlIGFwcGx5PyBJIHRoaW5rIHRoaXMgbmVlZHMgcmV3b3JkaW5nIHRvIHNheSB0aGF0 LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Rml4ZWQsIGFuZCBpbmNsdWRlZCBhIHJlZmVyZW5jZSB0byByZmM1MzIxJ3MgcmVsZXZh bnQgc2VjdGlvbiwgdG8gaG9wZWZ1bGx5IG1ha2UgY2xlYXIgd2UgZXhwZWN0IGV4aXN0aW5nIHJ1 bGVzIHRvIGFwcGx5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo4KSBJZiB5b3Ugd2FudCB0byBhbGxvdyBmb3Ig ZXh0ZW5zaWJpbGl0eSwgeW91IHByb2JhYmx5IG5lZWQgYW4gSUFOQSByZWdpc3RyeSBvZiBmaWVs ZHMgYWxsb3dlZCwgc28gdGhhdCBkZXZlbG9wZXJzIGNhbiBmaW5kIHRoZW0gZWFzaWx5LiBJIGNh biBoZWxwIHdpdGggc29tZSB0ZXh0LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdkIGFwcHJlY2lhdGUgYW55IHN1Z2dlc3Rpb25z LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JcyB0aGVyZSBhIG5lZWQgZm9yIHRoYXQgbm93LCB0aG91Z2g/IEkgd291bGQgbm90IHdh bnQgdG8gb3ZlcmVuZ2luZWVyIHRoaXMsIGVpdGhlci4gOikmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KOSkgT24g cGFnZSAxMzogSSB0aGluayBwc2V1ZG9jb2RlIHNob3VsZCBtYWtlIGl0IGNsZWFyIHRoYXQgeW91 IHJldHJpZXZlIEROUy1JRCBTQU4uPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsIGRvbmUuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkJl c3QgUmVnYXJkcyw8YnI+DQpBbGV4ZXk8YnI+DQo8YnI+DQpQLlMuIEkgbWlnaHQgaGF2ZSBhIGNv dXBsZSBvZiBleHRyYSBpdGVtcywgYnV0IEkgbmVlZCB0byBkb3VibGUgY2hlY2sgYSBmZXcgdGhp bmdzIGZpcnN0Ljxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KVXRhIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpV dGFAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5VdGFAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ1dGEmYW1wO2Rh dGE9MDIlN0MwMSU3Q0phbmV0LkpvbmVzJTQwbWljcm9zb2Z0LmNvbSU3QzhmOWE1NWRlNmFmOTQ3 YWM1NDU1MDhkNDhhNDAxNGY3JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mx JTdDMCU3QzYzNjI4NTQ1NTIzOTQxOTU5OCZhbXA7c2RhdGE9NnNqc0pQNWZ3Nm1GcXQ4RkJLSHdl QWVtTjElMkZoJTJGZDFHJTJCSFZWTnpqcGtRWSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdXRhPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_SN2PR03MB2318B66DDAB5684C346B77BEE61E0SN2PR03MB2318namp_-- From nobody Tue Apr 25 10:01: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 69663129457 for ; Tue, 25 Apr 2017 10:01:17 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 8BsdTgZC3JSI for ; Tue, 25 Apr 2017 10:01:14 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 4E6C112945C for ; Tue, 25 Apr 2017 10:01:12 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id f187so17853437ite.1 for ; Tue, 25 Apr 2017 10:01:12 -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=+bF6sWEGmDqX/jBVaZz6g6Yf7NMXXX4RbeONfj3AnbY=; b=cm1BZBuijbNz+VVSsGII1OHwlMXyCLmabPXrFii6xeCSx+mFRTIJk0jqfVuk8Rs4aR bvn4c/5SkZMzGHkzCGqKi+pu7feUfqm2SLuPXFKxBXKa8uSdJGUYsnpJoUrrMQmIBvW3 PIRFR+tAFjoR3DMfOcUfxhoV16RFbqoSWIdZKwPbL+5iA/XGPFPASi5F4jPzS88riwHs tFfRhmQss4GmK5CAJzlFu6T+hOJBCKsLPAUACiyqurRId2AiNWkh531XjEyp/O3MwA8b S38qaKtl1LEjkHx+8CGALj82dniVn4IUOk1muvATgZw07OLEdEV8itSZ90v3xhAo1rsD 3aRg== 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=+bF6sWEGmDqX/jBVaZz6g6Yf7NMXXX4RbeONfj3AnbY=; b=uLa+9cEBXDKD7ycyMvEjuS35c9NFZoTsqefJl7uPJikTggO2Pv0a7qgVe1Pw68RM7b 2OMsPlNaLHvkO+HVFBmflp8CrWHvBchv4122phin8xeC03ScwxqOI+Ji26bb6gz16qM9 PYbmn6RMMaaVw6E3N6ir+lTXTyp8N+FYxfsmLZSDyKQa3n45ztkNSfofDcvd0+6IEJBb +IFUc/oPTVaEr5KDvMJ5syifZEhtW+GH0Vi2x9actfevmUt45V0uz1YXaKlGZ8HipmZV 5bPdZChP3+LQmAIwcfqVDZesMpI9NIw7ZHyjRacDP3EIX8F9YpHroMKL5stt8TUfnROe IXVA== X-Gm-Message-State: AN3rC/40LowF1gcdH157HC8ie7zVPZaNFaOysUjbmanBq/ybLtVG9CPX ZEgNyWg1scRBedHfXKnS7DZ+tw1CoU+aI+evqA== X-Received: by 10.36.58.14 with SMTP id m14mr1550714itm.26.1493139670803; Tue, 25 Apr 2017 10:01:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.111.11 with HTTP; Tue, 25 Apr 2017 10:01:09 -0700 (PDT) In-Reply-To: References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> From: Daniel Margolis Date: Tue, 25 Apr 2017 19:01:09 +0200 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114414e2bab5e5054e00abb7" Archived-At: Subject: Re: [Uta] 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, 25 Apr 2017 17:01:18 -0000 --001a114414e2bab5e5054e00abb7 Content-Type: multipart/alternative; boundary=001a114414e2ae41ca054e00ab88 --001a114414e2ae41ca054e00ab88 Content-Type: text/plain; charset=UTF-8 > > > That's not the problem. The problem is that even after that time expires > the > current specification does not appear to provide a means to *ever* stop > publishing > a policy. A "report" policy will get cached and then be subject to > another timer, > lather/rinse/repeat. How does the "report" policy ever transition out of > existence, > without looking like a downgrade attack? > > Are you suggesting to rely just on eventual flushing of expired cache > entries that > fail to refresh? Yes. A "report-only" policy with a short max_age (like 1 day) means a client will continue to refresh the policy once/day and, once the time period we have already discussed has passed, will forget it in a day. In terms of optimizing this period of time, there are no options that I see: as I previously noted (though this is trimmed in your reply; just for casual readers I am referring to https://www.ietf.org/mail-archive/web/uta/current/msg01983.html), absent (complex) changes to the TXT records, senders will have to cache some policy existence data anyway, for some period of time, so they will have to cache *something* for *some period*, essentially equivalent to "some period after the expiration time we have discussed", e.g. 1 day. :) > And in the mean-time clients may burn some cycles keeping reporting > data that is unwanted, and may never be sent. > Yes, indeed. So my point was that you could solve this by having a "none" mode (i.e. neither enforce nor report), but the only part of this issue we can optimize is the one you note here (keeping reporting data); *not* (at least without reworking the DNS advertising model, which I think is needless complexity) the caching time. > There ought to be a way to cleanly stop the process without failing > retries at the > end of the cycle. A "max_age = 0" should suffice (published for the > previous > max_age + DNS TTL). > It's still not clear to me whether you are trying to save sender cache entries, sender reporting cycles, or both. I think it would be more clear to split the discussion on those two things. As I noted, you could certainly set "report=false" and "enforce=false" (effectively) by adding some mode switch for this, but the only thing it would optimize is the "keeping stats for reporting is expensive" concern. (I am not really convinced this is that expensive, but it's a fair point.) *Separately*, I do not believe "max_age=0" makes cache expiration easier. As I have already noted, senders who purge a cache entry upon seeing "max_age=0" will then...see the _mta_sts TXT record for this domain next time they check and fetch the policy! So they have to cache the policy to avoid hitting the HTTPS endpoint all the time. How do you propose this should work? It may help me to better understand your suggestion if you flesh it out a little bit more. For example, would senders cache the presence of a "max_age=0" policy for a hardcoded amount of time? > > -- > Viktor. > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a114414e2ae41ca054e00ab88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

That's not the problem.=C2=A0 The problem is that even after that time = expires the
current specification does not appear to provide a means to *ever* stop pub= lishing
a policy.=C2=A0 A "report" policy will get cached and then be sub= ject to another timer,
lather/rinse/repeat.=C2=A0 How does the "report" policy ever tran= sition out of existence,
without looking like a downgrade attack?

Are you suggesting to rely just on eventual flushing of expired cache entri= es that
fail to refresh?=C2=A0

Yes. A "report-= only" policy with a short max_age (like 1 day) means a client will con= tinue to refresh the policy once/day and, once the time period we have alre= ady discussed has passed, will forget it in a day.=C2=A0

In terms of optimizing this period of time, there are no options tha= t I see: as I previously noted (though this is trimmed in your reply; just = for casual readers I am referring to=C2=A0https://www.ietf.org/mail-archiv= e/web/uta/current/msg01983.html), absent (complex) changes to the TXT r= ecords, senders will have to cache some policy existence data anyway, for s= ome period of time, so they will have to cache *something* for *some period= *, essentially equivalent to "some period after the expiration time we= have discussed", e.g. 1 day. :)=C2=A0
=C2=A0
And in the mean-time clients may = burn some cycles keeping reporting
data that is unwanted, and may never be sent.

Yes, indeed. So my point was that you could solve this by having a &= quot;none" mode (i.e. neither enforce nor report), but the only part o= f this issue we can optimize is the one you note here (keeping reporting da= ta); *not* (at least without reworking the DNS advertising model, which I t= hink is needless complexity) the caching time.=C2=A0
=C2=A0
=
There ought to be a way to cleanly stop the process without failing retries= at the
end of the cycle.=C2=A0 A "max_age =3D 0" should suffice (publish= ed for the previous
max_age + DNS TTL).

It's still not = clear to me whether you are trying to save sender cache entries, sender rep= orting cycles, or both. I think it would be more clear to split the discuss= ion on those two things.=C2=A0

As I noted, you cou= ld certainly set "report=3Dfalse" and "enforce=3Dfalse"= (effectively) by adding some mode switch for this, but the only thing it w= ould optimize is the "keeping stats for reporting is expensive" c= oncern. (I am not really convinced this is that expensive, but it's a f= air point.)

*Separately*, I do not believe "m= ax_age=3D0" makes cache expiration easier. As I have already noted, se= nders who purge a cache entry upon seeing "max_age=3D0" will then= ...see the _mta_sts TXT record for this domain next time they check and fet= ch the policy! So they have to cache the policy to avoid hitting the HTTPS = endpoint all the time.=C2=A0

How do you propose th= is should work? It may help me to better understand your suggestion if you = flesh it out a little bit more. For example, would senders cache the presen= ce of a "max_age=3D0" policy for a hardcoded amount of time?
=C2=A0

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

--001a114414e2ae41ca054e00ab88-- --001a114414e2bab5e5054e00abb7 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 K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCD4HpRbS87DU9qC lP859OTi2CFpsz5WQuf2Rraw84M8+zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA0MjUxNzAxMTFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAR480oNwmXIzqW3rZ8u5NwXnGI76PX+J4 AXVpjH4lXtwgMLlA35d6ADHvmVQ8MtNDoL9XURAKISQNcf0LISGjQ2hHId3WUGEWfLaJskbf9CxD ugEX0nPydahSANyHmZE6FwTjFJnnIvxdZBlPyxNk/5O4WLLESu5MsztBXf/gZ77mLrqh9LH96A54 675Ww98P53rV/D4nBDU/QdS9SArEe7D6REgB87cVM3S0D1WDhLJZjKsADbqMo+WwS6/iZI6tZMPs XEyW+ova/gkfwemBI2QZComa2nfPS+kP306VKym/jQN1ia+oGxlcgYCDJfkItTh+cx8dhPXG5FkY lwiS+Q== --001a114414e2bab5e5054e00abb7-- From nobody Fri Apr 28 05:25: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 9B875129C56 for ; Fri, 28 Apr 2017 05:25:03 -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, HTML_MESSAGE=0.001, 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 jKSZBtT0z8Ye for ; Fri, 28 Apr 2017 05:25:02 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 387A7129C5A for ; Fri, 28 Apr 2017 05:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1493382083; d=isode.com; s=june2016; i=@isode.com; bh=2I1KAZKk30/KE47BIC6vRYJ0uX6/9PEtYBL6UHlDTUc=; 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=oFwaR/9fb9Bv1Ogf+6TnFWvX9vQEAOTXEGSxOxpPQFh+xDXrPKzODMsRlk2yN8XbetnJJ/ ylIXmDohdpVBCUS1AMBeQx81lcWsfsXqrYnaRlYZlU27NxOFDo5DAmW0+CTofLq7qKXlVj aDy7EmIFpScd1qfRO2fQCTVp2Y/huTk=; 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 ; Fri, 28 Apr 2017 13:21:23 +0100 To: Daniel Margolis References: Cc: "uta@ietf.org" From: Alexey Melnikov Message-ID: <56420a3c-0176-3f16-681a-6f7265d28f93@isode.com> Date: Fri, 28 Apr 2017 13:21:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------F528360C1A7432218D9333AC" Archived-At: Subject: Re: [Uta] Review of draft-ietf-uta-mta-sts-04 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, 28 Apr 2017 12:25:03 -0000 --------------F528360C1A7432218D9333AC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 23/04/2017 12:58, Daniel Margolis wrote: > Thanks. Comments inline, mostly ticking off changes. :) > > I have pushed all my changes in response to this to the git repo and > they should appear in our next draft. > > > On Wed, Apr 19, 2017 at 1:05 PM, Alexey Melnikov > > wrote: [snip] > > 8) If you want to allow for extensibility, you probably need an > IANA registry of fields allowed, so that developers can find them > easily. I can help with some text. > > > I'd appreciate any suggestions. > > Is there a need for that now, though? I would not want to overengineer > this, either. :) All IETF documents are required to have the "IANA Considerations" section. IANA will manage registries if they are created by an RFC. If you know that a particular protocol or format field is going to be extensible, it is much better to define a registry now than be forced to create one in a hurry later on. So just create an issue for this (if you haven't already). I can help with some text. --------------F528360C1A7432218D9333AC Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On 23/04/2017 12:58, Daniel Margolis wrote:

Thanks. Comments inline, mostly ticking off changes. :)=C2=A0

I have pushed all my changes in response to this to the git repo and they should appear in our next draft.


On Wed, Apr 19, 2017 at 1:05 PM, Alexey Melnikov <= alexey.melnikov@isode.com> wrote:
=C2=A0[snip]
8) If you want to allow for extensibility, you probably need an IANA registry of fields allowed, so that developers can find them easily. I can help with some text.

I'd appreciate any suggestions.=C2=A0

Is there a need for that now, though? I would not want to overengineer this, either. :)

All IETF documents are required to have the "IANA Considerations" section. IANA will manage registries if they are created by an RFC.
If you know that a particular protocol or format field is going to be extensible, it is much better to define a registry now than be forced to create one in a hurry later on.

So just create an issue for this (if you haven't already). I can help with some text.



--------------F528360C1A7432218D9333AC--