From nobody Sat Jul 1 11:13: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 A0E92120454 for ; Sat, 1 Jul 2017 11:13:48 -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 kSuhQeor_l9b for ; Sat, 1 Jul 2017 11:13:47 -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 293BA1201F8 for ; Sat, 1 Jul 2017 11:13:47 -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 6811D7A330A for ; Sat, 1 Jul 2017 18:13:46 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Content-Type: text/plain; charset=us-ascii From: Viktor Dukhovni Resent-From: Viktor Dukhovni In-Reply-To: <6a908497-a342-322a-e0eb-ce8d4a7244f6@cs.tcd.ie> Date: Sat, 1 Jul 2017 14:13:14 -0400 Reply-To: uta@ietf.org Resent-Date: Sat, 1 Jul 2017 14:13:46 -0400 Message-Id: Resent-To: uta@ietf.org References: <6a908497-a342-322a-e0eb-ce8d4a7244f6@cs.tcd.ie> Content-Transfer-Encoding: quoted-printable To: Stephen Farrell X-Mailer: Apple Mail (2.3273) Resent-Message-Id: <20170701181347.293BA1201F8@ietfa.amsl.com> Archived-At: Subject: Re: [Uta] json vs kv in draft-ietf-uta-mta-sts 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, 01 Jul 2017 18:13:48 -0000 > On Jun 29, 2017, at 9:23 AM, Stephen Farrell = wrote: >=20 > The library point is relevant because some people > will already have json support, at which point there > is no additional complexity, for them. (That said, I've > always been neutral in religious debates about data > definition language fashions, but do realise that a > lot of people have much stronger feelings. In any > case, the use of terms like "bloat" etc doesn't > convince me of anything:-) Postfix, et. al. are part of the "base" footprint of a number of operating system platforms. The release engineering teams of those operating system platforms very much prefer to keep the number of dependencies in check, and to not introduce unnecessary new components into the base build. If folks want to see STS support in the base Postfix version in, e.g., NetBSD then it is best to avoid introducing avoidable dependencies on additional libraries that would otherwise not be required for the base system. JSON *is* complex. My processing of the Rapid7 FDNS feed (22GB compressed) burns hours of CPU since they switched from simple white-space separated files to JSON, which I parse with "jq". JSON is not needed for the problem at hand. Sure, if inertia trumps simplicity of design, we'll stumble along with JSON, but I am rather surprised that it is getting such avid support. --=20 Viktor. From nobody Mon Jul 3 15:43:57 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 36D7E12EB27; Mon, 3 Jul 2017 15:43:56 -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.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149912183618.16062.18280572606102663591@ietfa.amsl.com> Date: Mon, 03 Jul 2017 15:43:56 -0700 Archived-At: Subject: [Uta] I-D Action: draft-ietf-uta-email-deep-07.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: Mon, 03 Jul 2017 22:43:56 -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 : Cleartext Considered Obsolete: Best Current Practices for Use of TLS for Email Submission and Access Authors : Keith Moore Chris Newman Filename : draft-ietf-uta-email-deep-07.txt Pages : 27 Date : 2017-07-03 Abstract: This specification outlines best current practices for use of Transport Layer Security (TLS) to provide confidentiality of email traffic between a mail user agent (MUA) and a mail submission or mail access server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-email-deep/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-uta-email-deep-07 https://datatracker.ietf.org/doc/html/draft-ietf-uta-email-deep-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-email-deep-07 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 Jul 12 03:11: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 25A55129B4B for ; Wed, 12 Jul 2017 03:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LD5dierBqHSv for ; Wed, 12 Jul 2017 03:11:19 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B60813182A for ; Wed, 12 Jul 2017 03:11:18 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id z78so11955834lff.0 for ; Wed, 12 Jul 2017 03:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=IQ8VGvyCT5feKixZieRvfZk3bjL8GoBj+ylWHXI5WBw=; b=LYA8C2zRHNqFs08QgnUfw1i0dVKsedSNvZu2UHrrbs1aTHVws4MtO8C4X3PRmDpT+e JiXXjDAa5kqGoBgYbG8kIOjcPHKqlbKOVyYKMQInQrX0B2t3KORObjrcb2v9Wg/EQu1r UAKTjWax8b39BcXEQjGr0ePJd8qzreQTAt5zPcvE+4nJPgjP+Vjs3E2rzIYW+xpgjGBe FhO0SIO0hTpd7rxSSjblOs0f27ivgwV2wyf4VFvqCDcMIcw7DCQbcSVLDsvJRnD9uFjL th0dQJRjlYjKPbZ7gB4gqrGqPBDOAmpnM0h/tYRFhCA8pobQ4ao4CLTqnv2+yJAuMx8i mG2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=IQ8VGvyCT5feKixZieRvfZk3bjL8GoBj+ylWHXI5WBw=; b=fGUs+UKoIi5yXWO0txZPkY6KZXN5FNjRKOOl1fNMnQBami/hZ/iE7EaPCoY3dWsrmz nk+/wdoox2aNbgDdoy4DWPA3ELnlt2Dp0ooK47WSRxxCZIp11Dw0MHR3kXzI25h5QOJK uyT9akvLkq2TbLCYsgH+W5bAEWc8oakGV3GOvxiF70MWN4ffMr7efIXz97XiUm+BEbuw 39Y2Nhms5xzdZbykOsQsQygGTFjos4guuxZrcKBwSt3f6hMIl0QYVEzsjcp5y0S4YFAA yfw3UrsRqMtHpjbi0wKsTZMiedhUq8qCo/RlPxMyvxDBzYzHyiLiaTJgX4abpq3GZ7sd mzzg== X-Gm-Message-State: AIVw1120sUsKu3KRDLpmekjTAgHHyBQ3rFCbpX4ltjZ2iwXGcIFmp5l7 l/YpODhJmuBaxt4srSi5Sw== X-Received: by 10.46.76.1 with SMTP id z1mr1673559lja.124.1499854276716; Wed, 12 Jul 2017 03:11:16 -0700 (PDT) Received: from [10.0.0.129] (h-155-4-129-189.NA.cust.bahnhof.se. [155.4.129.189]) by smtp.gmail.com with ESMTPSA id r203sm400733lff.67.2017.07.12.03.11.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 03:11:16 -0700 (PDT) To: uta@ietf.org From: Leif Johansson Message-ID: Date: Wed, 12 Jul 2017 12:11:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 10:11:21 -0000 This starts a 3 week working group last call (WGLC) on draft-ietf-uta-smtp-tlsrpt-06. Please provide your comments to the list by Wednesday August 2nd. Best R Leif & Orit From nobody Mon Jul 17 12:17: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 83A99129A92 for ; Mon, 17 Jul 2017 12:17:12 -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 b9S7f9dsJ5kQ for ; Mon, 17 Jul 2017 12:17:11 -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 5FE7C12702E for ; Mon, 17 Jul 2017 12:17:11 -0700 (PDT) X-AuditID: a2962c47-fdbff70000027289-1d-596d0d356d63 Received: from COPDCEX19.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 04.53.29321.53D0D695; Mon, 17 Jul 2017 13:17:10 -0600 (MDT) Received: from COPDCEX19.cable.comcast.com (147.191.124.150) by COPDCEX19.cable.comcast.com (147.191.124.150) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 17 Jul 2017 13:17:08 -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.1293.002; Mon, 17 Jul 2017 13:17:08 -0600 From: "Brotman, Alexander" To: "uta@ietf.org" Thread-Topic: MTA-STS: A Key-Value Alternative Thread-Index: AdL/LuICRkjKTXCsSNqXJIkuwNLrjQ== Date: Mon, 17 Jul 2017 19:17:08 +0000 Message-ID: <6eae98161ea442b5920a28814ee3ec1d@COPDCEX19.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA11TW2zTVhjWSdzUTXOK65Dk1KOseAJpUHoZCFA3pj1s2qhWLg8DGRQRJzFJ FOciO6G0DyiiqtAqJm0DhhYBK7QrCKGpnTqtiMBDKJNSqUJUFCSoxAPl0iJEb6ytKJRzcikO T/78ff7/7/+/c0zr2Y4ijvYFI5ISFGXeYKQcyunj6zfBgFCTaNmwZeBmC/gKfNfZOa/bCfYa v3BLsu+gpFR/6TB6z4z3F4b/Kzh0PDZHxUAf1QZoGjEbUd/1HW3ASLPMRR06cW8GZF6SAN08 2WFoA0X4JQXQxPOtBBuYOvRi8aie4OXMKvRs4WUhaWRmPkX/99gzdBX6986QgdAEtw5uIzTF rEYnWsYAwZCpR4/vxCiCAWNFswOXdQTrGRu6P/pHGiOGQZ2JW/oMtqCxR28LMrgG/fPn9ez4 H6PJM9nSStR+dcqQwetQ17nn+oxVKUr9PkplSm3oRn9fwc/AEte4xTXlcU15XFPeDqhLYKUr FHa7At5QNFJTW+USnbJU5QoFXKIaIc+/AT6P879VftsHJm7Zk4ChAW+C9KwssAXiQbUpkAR+ Wsdb4G2DX2BLnCF3k1dUvfuVqCyp/HI4VxwQWLhEO6Oyn+fgNGHNS2xQalRlKYIvAL8SnieN bEuaGlXDPpcvFFX3RxUZnyCtx22/foMHgG6xqVlSQhmzJPiIpngb1Olxb8YjRiS/JIUlJac2 0jSP4DcmrJYqkkc6dMAnR3IyrutawC0ZrZIethxu6fcJrFUraOZdBT8nMqeVPxxZRxclgYc2 4bmH03GoYTGg+jxZazPsncLWphybti2DXeRTNkdqLMvh7kIckTUn5dsNgFZAH5nondGxVDAU lDgb7CedGPK5NxpcWpmzwtQuh8Au0wjEmlsBjxHeouHfu3MV8BlRyzRq/gC5H3gcuPBdMcMe 4m7Cv/f7jVl4g5DFWTK9MIIJwpVmOc2+K6BA9rVklXy3cRysDgdrbiAXQo2IEW2wIw3pYLNs NtghQrI5Mi/YU0Sy5qR8Jy4GTr7atdn/en6w8a/uskquJTVz98L6oUX7qeqHsLYePLlX8euG +Ma6lPtpSfH2wz8NDG9z7hzdW9L6xtA++eOwoF4p7xjc2ryp5+zIvvpr3GVH8y+fGceehAbt s8KO7rPREYcnwdRN1z89veaHmN+euPK4d9l0d/DYNeeDT9jv99QsunlK9Yq1a/WKKr4Dhqv2 5jYFAAA= Archived-At: Subject: [Uta] MTA-STS: A Key-Value Alternative 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, 17 Jul 2017 19:17:12 -0000 Hello, The authors of the MTA-STS draft and the UTA group have been attempting to = reach a consensus on the issue of JSON versus KV for the policy file that i= s served via HTTPS. In order to attempt to get over that issue, we've mad= e a rough draft[1] that now uses key-value pairs instead of JSON. Overall,= our preference would be to stay with JSON as the alteration will break exi= sting and in-progress implementations, but we'd really like to move forward= . We'd like to work toward a conclusion and welcome comments from the grou= p. [1] https://raw.githubusercontent.com/mrisher/smtp-sts/KV_Version/mta-sts.t= xt -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast x5364 From nobody Mon Jul 17 12:36:53 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 5429912EC01 for ; Mon, 17 Jul 2017 12:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMf_xRfeRoHg for ; Mon, 17 Jul 2017 12:36:50 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 44A79129B30 for ; Mon, 17 Jul 2017 12:36:50 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id q86so81092772pfl.3 for ; Mon, 17 Jul 2017 12:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W053ZFRNhy8emPy59LS2PE0gBRMhZYVAMldikxVQ6+8=; b=Ym0NsSLKv/Xs/HxCCpLHbQ/MKAcCyreIMv0yz0SjInx7x0EZienmrUP3d0aVLmyTxq tbx0RptM6w5I6/N38WsjA1GJnL75iBYOqe8y0/utDqgawlYu64XROjv6BhpVGAur0x+n nh82uep1gAy4Sa8JE/piGxH2VBJrxVRIxonjdFkt9eswkNhzcAZyvnaSEIUmCH6QhfDx LXpTXdKX7OPEjS/jp1hRZijqgSzlhurZ/HL99g9ZLa+gpFXq3cUfCV4ussX7w4xTs9Bk 7f0iaTDqmo16NvyPGBr2OWtMFAEfAXCYCQwNn9oWL02ZwRX9hTvkk/Fvh34WcDkyPTpP 4CNQ== 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=W053ZFRNhy8emPy59LS2PE0gBRMhZYVAMldikxVQ6+8=; b=FxpLP+2fCH0A5DuMFE4yNulJDTY2V2YCoH5bDq6EPWGV6Np12sHQqzoFQO7qEmvCYO o3ITzK7nV6ob0rRReMowJKUJn0twaOiDljk/V/arS9kEi4eEivZu1sVc5uOUGooeykMJ leJLlDv3ZIer0fh5v7a1f+a8uHHeDc/5lUl0UhETuvBvTV/49NJbAzW7COX+widT1sY3 ZuFZD8hw5tu4896uoYKB2YMTZ5GuJAUlREEUg5i+PzYqUp/9V+YQgTcIbGf4bTwMlSbV 0HSP2EZy6HxvG4CppHj1crF5Cqw6ammNv1/zccYYHOM6Hme13BpZyYuOoDv2X0gwHGU4 oTUw== X-Gm-Message-State: AIVw113E3lRg8q11gswJEWUODlyN3MNTL4TGnqC2tHlSdGBkBjFnMhaM mJ2roYYXWj4xaL/TRjDZHSGIqkLVqA== X-Received: by 10.98.57.4 with SMTP id g4mr20475425pfa.155.1500320209945; Mon, 17 Jul 2017 12:36:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.170.74 with HTTP; Mon, 17 Jul 2017 12:36:49 -0700 (PDT) In-Reply-To: <6eae98161ea442b5920a28814ee3ec1d@COPDCEX19.cable.comcast.com> References: <6eae98161ea442b5920a28814ee3ec1d@COPDCEX19.cable.comcast.com> From: David Illsley Date: Mon, 17 Jul 2017 20:36:49 +0100 Message-ID: To: "Brotman, Alexander" Cc: "uta@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c114af429c9900554888592" Archived-At: Subject: Re: [Uta] MTA-STS: A Key-Value Alternative 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, 17 Jul 2017 19:36:52 -0000 --94eb2c114af429c9900554888592 Content-Type: text/plain; charset="UTF-8" Is there a proposed Media Type/Content Type header value for this (can't see one in the diff)? One of the nice things about JSON is that web servers are likely to serve .json files as something appropriate out of the box. On Mon, Jul 17, 2017 at 8:17 PM, Brotman, Alexander < Alexander_Brotman@comcast.com> wrote: > Hello, > > The authors of the MTA-STS draft and the UTA group have been attempting to > reach a consensus on the issue of JSON versus KV for the policy file that > is served via HTTPS. In order to attempt to get over that issue, we've > made a rough draft[1] that now uses key-value pairs instead of JSON. > Overall, our preference would be to stay with JSON as the alteration will > break existing and in-progress implementations, but we'd really like to > move forward. We'd like to work toward a conclusion and welcome comments > from the group. > > [1] https://raw.githubusercontent.com/mrisher/smtp-sts/KV_ > Version/mta-sts.txt > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse > Comcast > x5364 > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --94eb2c114af429c9900554888592 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Is there a proposed Media Type/Content Type header value f= or this (can't see one in the diff)? One of the nice things about JSON = is that web servers are likely to serve .json files as something appropriat= e out of the box.

On Mon, Jul 17, 2017 at 8:17 PM, Brotman, Alexander <Alexander_Brotman@comcast.com> wrote:
Hello,

The authors of the MTA-STS draft and the UTA group have been attempting to = reach a consensus on the issue of JSON versus KV for the policy file that i= s served via HTTPS.=C2=A0 =C2=A0In order to attempt to get over that issue,= we've made a rough draft[1] that now uses key-value pairs instead of J= SON.=C2=A0 Overall, our preference would be to stay with JSON as the altera= tion will break existing and in-progress implementations, but we'd real= ly like to move forward.=C2=A0 We'd like to work toward a conclusion an= d welcome comments from the group.

[1] https://raw.githubuserc= ontent.com/mrisher/smtp-sts/KV_Version/mta-sts.txt

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


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

--94eb2c114af429c9900554888592-- From nobody Mon Jul 17 13:09:09 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 33B6D129AEB for ; Mon, 17 Jul 2017 13:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 CV_i9r9IZPJT for ; Mon, 17 Jul 2017 13:09:06 -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 660AC13167F for ; Mon, 17 Jul 2017 13:09:06 -0700 (PDT) X-AuditID: 60729ed4-f25ff70000007520-4b-596d19614753 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 54.56.29984.1691D695; Mon, 17 Jul 2017 14:09:05 -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.1293.2; Mon, 17 Jul 2017 14:09:04 -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.1293.002; Mon, 17 Jul 2017 14:09:04 -0600 From: "Brotman, Alexander" To: David Illsley CC: "uta@ietf.org" Thread-Topic: [Uta] MTA-STS: A Key-Value Alternative Thread-Index: AdL/LuICRkjKTXCsSNqXJIkuwNLrjQAN3DqAAAuKL3A= Date: Mon, 17 Jul 2017 20:09:03 +0000 Message-ID: References: <6eae98161ea442b5920a28814ee3ec1d@COPDCEX19.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.11] Content-Type: multipart/alternative; boundary="_000_fe051513ca954006a384f4695473355bCOPDCEX19cablecomcastco_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA11Uf2wTVRzPu17bt9I3rlfWvtUN5aIRMcBQEhY0xBiiixFw/xCqifTWnmu3 a6+768GG/zDmmBn+oQ4DnhsTHMYAOkVYgE2dXUVWSQz+QDMlaNgfY0YTMDoHy/S9u3Zc/efd 5z6f9/1+vu/zLgcd/B5PCCZSGUlNibLg8rARtbdnpViZDNeMnV1Ze3lq2F2b/6IDPMbUnTWu uOsGBmaZZ5hnPY/GJDmxQ1JXb4h44h/9xKVfrm8d7Gh37QZTm7sBhJhbiz8cdnUDD+S59xjc dfE0sF6yAH/Wuc/RDcrIyzjAYzcUil3cevz7v10mv4RbgSevDLoodnDL8KnDPzgp9nMP43cm Zt3WnrX489zxAl6Pc4c7GIpZ7j78460LZi3insLGzZusZfwawKMj8ywVyrh6/PH1AbMAcAE8 kz/BWGZBPDHZb2LMcXhg5GuHhSvw9WvzTgvX4NNHP2WtU96Nb/QVShXcdXXIbfn68Pibk6y1 PYjHcmecr4KgYXMwbCWGrcQgXR3cA3jw3GqjcPr9+351W3g57uztc9v5t4H7GFgaVdKxaDKu 6Jmah1ZFxQZZWhVVklFRy9DnSWBe66HvzoBvD9RlAQeB4EVNvmSYd4o7tLZkFjRDRqhAl1zN Yb68QYm1xUUtvl3VZUkTlqB/FpGdaIFu0OVmIYSaMGH9C2xK2qnJUoZ8R8JSdIQ2Ci5omq6l E9GEomvbdVUm9w8dpC3iaNuY2LZLUhXLLAvugqwQRKyDSFyjmJGaJSktqUV1J4QCRuXU2adK jVLrCwk5U5RJ3btzMqmzK+aw1ag2lwjzAbtgm3cZeoTKIbv8/5EZWJYFjdBL5n6J2iMtLSa1 RGPB2o8mvIT1FlnTthJtCxKSL5I2y2q01U0iChSlUrs86APQODj7NwNPmuup2xdmGJg11/N0 5dmUkpJCQfQcdeBom7ieWogiFEDj9ZEwv9gm0JFCVegVylfY+DtThe5BU1SttKmlgxX/D9Mg Sr4hPzpC3b3k73EnCR49HiDkogJpBoFRE93oK3C2HKpQmOZQUVBK3aZJ4AwJ3L9JpoFnxIw9 8J8p6y2yhcC/oSRfJEsCP0ClQFEqdQrtBvk37r3YzsQ6p5Nte51KS/vc/nV1sCceYbK3m2DX +eGha/DPFt31W++azdonTx/P6+OXttzCB3/R/3pCOVf+5fvzPfdv29vf2zG468HK1nx7bvHQ i9En/7h8bMMHMXbPurmpkav5VGZjv6/aODo6Mtq68auq+Ezue9/zry9/q2UT2hIRWC0urlnh UDXxP5OiiBKVBQAA Archived-At: Subject: Re: [Uta] MTA-STS: A Key-Value Alternative 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, 17 Jul 2017 20:09:08 -0000 --_000_fe051513ca954006a384f4695473355bCOPDCEX19cablecomcastco_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBjcmVhdGVkIHRoaXMgYXMgYSDigJwucG9saWN54oCdLCBidXQgdW5mb3J0dW5hdGVseSBsZWZ0 IG91dCB0aGUgbmV3IENvbnRlbnQtVHlwZSB0aGF0IHdvdWxkIG5lZWQgdG8gYmUgZGVjbGFyZWQu ICBUaGUgaWRlYSBvZiB0aGUgcm91Z2ggZHJhZnQgd2FzIHJlYWxseSB0byBnaXZlIGZvbGtzIGFu IGlkZWEgb2Ygd2hhdCBpdCB3b3VsZCBsaWtlLCBhbmQgc3RpciB0aGUgZGlzY3Vzc2lvbi4gIFdl IGNvdWxkIG9idmlvdXNseSBjaGFuZ2UgdGhpcyB0byBzb21ldGhpbmcgdGhhdCBpcyBtb3JlIHdl bGwta25vd24gKHR4dCBvciBzaW1pbGFyKSBzbyB0aGF0IHdlIGRvbuKAmXQgbmVlZCB0byBkbyB0 aGlzLg0KDQotLQ0KQWxleCBCcm90bWFuDQpTci4gRW5naW5lZXIsIEFudGktQWJ1c2UNCkNvbWNh c3QNCng1MzY0DQoNCkZyb206IERhdmlkIElsbHNsZXkgW21haWx0bzpkYXZpZGlsbHNsZXlAZ21h aWwuY29tXQ0KU2VudDogTW9uZGF5LCBKdWx5IDE3LCAyMDE3IDM6MzcgUE0NClRvOiBCcm90bWFu LCBBbGV4YW5kZXIgPEFsZXhhbmRlcl9Ccm90bWFuQGNhYmxlLmNvbWNhc3QuY29tPg0KQ2M6IHV0 YUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtVdGFdIE1UQS1TVFM6IEEgS2V5LVZhbHVlIEFsdGVy bmF0aXZlDQoNCklzIHRoZXJlIGEgcHJvcG9zZWQgTWVkaWEgVHlwZS9Db250ZW50IFR5cGUgaGVh ZGVyIHZhbHVlIGZvciB0aGlzIChjYW4ndCBzZWUgb25lIGluIHRoZSBkaWZmKT8gT25lIG9mIHRo ZSBuaWNlIHRoaW5ncyBhYm91dCBKU09OIGlzIHRoYXQgd2ViIHNlcnZlcnMgYXJlIGxpa2VseSB0 byBzZXJ2ZSAuanNvbiBmaWxlcyBhcyBzb21ldGhpbmcgYXBwcm9wcmlhdGUgb3V0IG9mIHRoZSBi b3guDQoNCk9uIE1vbiwgSnVsIDE3LCAyMDE3IGF0IDg6MTcgUE0sIEJyb3RtYW4sIEFsZXhhbmRl ciA8QWxleGFuZGVyX0Jyb3RtYW5AY29tY2FzdC5jb208bWFpbHRvOkFsZXhhbmRlcl9Ccm90bWFu QGNvbWNhc3QuY29tPj4gd3JvdGU6DQpIZWxsbywNCg0KVGhlIGF1dGhvcnMgb2YgdGhlIE1UQS1T VFMgZHJhZnQgYW5kIHRoZSBVVEEgZ3JvdXAgaGF2ZSBiZWVuIGF0dGVtcHRpbmcgdG8gcmVhY2gg YSBjb25zZW5zdXMgb24gdGhlIGlzc3VlIG9mIEpTT04gdmVyc3VzIEtWIGZvciB0aGUgcG9saWN5 IGZpbGUgdGhhdCBpcyBzZXJ2ZWQgdmlhIEhUVFBTLiAgIEluIG9yZGVyIHRvIGF0dGVtcHQgdG8g Z2V0IG92ZXIgdGhhdCBpc3N1ZSwgd2UndmUgbWFkZSBhIHJvdWdoIGRyYWZ0WzFdIHRoYXQgbm93 IHVzZXMga2V5LXZhbHVlIHBhaXJzIGluc3RlYWQgb2YgSlNPTi4gIE92ZXJhbGwsIG91ciBwcmVm ZXJlbmNlIHdvdWxkIGJlIHRvIHN0YXkgd2l0aCBKU09OIGFzIHRoZSBhbHRlcmF0aW9uIHdpbGwg YnJlYWsgZXhpc3RpbmcgYW5kIGluLXByb2dyZXNzIGltcGxlbWVudGF0aW9ucywgYnV0IHdlJ2Qg cmVhbGx5IGxpa2UgdG8gbW92ZSBmb3J3YXJkLiAgV2UnZCBsaWtlIHRvIHdvcmsgdG93YXJkIGEg Y29uY2x1c2lvbiBhbmQgd2VsY29tZSBjb21tZW50cyBmcm9tIHRoZSBncm91cC4NCg0KWzFdIGh0 dHBzOi8vcmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbS9tcmlzaGVyL3NtdHAtc3RzL0tWX1ZlcnNp b24vbXRhLXN0cy50eHQNCg0KLS0NCkFsZXggQnJvdG1hbg0KU3IuIEVuZ2luZWVyLCBBbnRpLUFi dXNlDQpDb21jYXN0DQp4NTM2NA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpVdGEgbWFpbGluZyBsaXN0DQpVdGFAaWV0Zi5vcmc8bWFpbHRvOlV0 YUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdXRhDQoN Cg== --_000_fe051513ca954006a384f4695473355bCOPDCEX19cablecomcastco_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgY3JlYXRlZCB0aGlzIGFzIGEg4oCcLnBv bGljeeKAnSwgYnV0IHVuZm9ydHVuYXRlbHkgbGVmdCBvdXQgdGhlIG5ldyBDb250ZW50LVR5cGUg dGhhdCB3b3VsZCBuZWVkIHRvIGJlIGRlY2xhcmVkLiZuYnNwOyBUaGUgaWRlYSBvZiB0aGUgcm91 Z2ggZHJhZnQgd2FzIHJlYWxseSB0byBnaXZlDQogZm9sa3MgYW4gaWRlYSBvZiB3aGF0IGl0IHdv dWxkIGxpa2UsIGFuZCBzdGlyIHRoZSBkaXNjdXNzaW9uLiZuYnNwOyBXZSBjb3VsZCBvYnZpb3Vz bHkgY2hhbmdlIHRoaXMgdG8gc29tZXRoaW5nIHRoYXQgaXMgbW9yZSB3ZWxsLWtub3duICh0eHQg b3Igc2ltaWxhcikgc28gdGhhdCB3ZSBkb27igJl0IG5lZWQgdG8gZG8gdGhpcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi0tPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFs ZXggQnJvdG1hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Tci4gRW5naW5lZXIsIEFudGktQWJ1c2U8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Q29tY2FzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj54NTM2NDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBE YXZpZCBJbGxzbGV5IFttYWlsdG86ZGF2aWRpbGxzbGV5QGdtYWlsLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiBNb25kYXksIEp1bHkgMTcsIDIwMTcgMzozNyBQTTxicj4NCjxiPlRvOjwvYj4gQnJv dG1hbiwgQWxleGFuZGVyICZsdDtBbGV4YW5kZXJfQnJvdG1hbkBjYWJsZS5jb21jYXN0LmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IHV0YUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W1V0YV0gTVRBLVNUUzogQSBLZXktVmFsdWUgQWx0ZXJuYXRpdmU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyB0aGVyZSBhIHByb3Bvc2VkIE1lZGlhIFR5cGUvQ29udGVu dCBUeXBlIGhlYWRlciB2YWx1ZSBmb3IgdGhpcyAoY2FuJ3Qgc2VlIG9uZSBpbiB0aGUgZGlmZik/ IE9uZSBvZiB0aGUgbmljZSB0aGluZ3MgYWJvdXQgSlNPTiBpcyB0aGF0IHdlYiBzZXJ2ZXJzIGFy ZSBsaWtlbHkgdG8gc2VydmUgLmpzb24gZmlsZXMgYXMgc29tZXRoaW5nIGFwcHJvcHJpYXRlIG91 dCBvZiB0aGUgYm94LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gTW9uLCBKdWwgMTcsIDIwMTcgYXQgODoxNyBQTSwgQnJvdG1hbiwgQWxleGFuZGVyICZs dDs8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyX0Jyb3RtYW5AY29tY2FzdC5jb20iIHRhcmdldD0i X2JsYW5rIj5BbGV4YW5kZXJfQnJvdG1hbkBjb21jYXN0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvLDxicj4N Cjxicj4NClRoZSBhdXRob3JzIG9mIHRoZSBNVEEtU1RTIGRyYWZ0IGFuZCB0aGUgVVRBIGdyb3Vw IGhhdmUgYmVlbiBhdHRlbXB0aW5nIHRvIHJlYWNoIGEgY29uc2Vuc3VzIG9uIHRoZSBpc3N1ZSBv ZiBKU09OIHZlcnN1cyBLViBmb3IgdGhlIHBvbGljeSBmaWxlIHRoYXQgaXMgc2VydmVkIHZpYSBI VFRQUy4mbmJzcDsgJm5ic3A7SW4gb3JkZXIgdG8gYXR0ZW1wdCB0byBnZXQgb3ZlciB0aGF0IGlz c3VlLCB3ZSd2ZSBtYWRlIGEgcm91Z2ggZHJhZnRbMV0gdGhhdCBub3cgdXNlcw0KIGtleS12YWx1 ZSBwYWlycyBpbnN0ZWFkIG9mIEpTT04uJm5ic3A7IE92ZXJhbGwsIG91ciBwcmVmZXJlbmNlIHdv dWxkIGJlIHRvIHN0YXkgd2l0aCBKU09OIGFzIHRoZSBhbHRlcmF0aW9uIHdpbGwgYnJlYWsgZXhp c3RpbmcgYW5kIGluLXByb2dyZXNzIGltcGxlbWVudGF0aW9ucywgYnV0IHdlJ2QgcmVhbGx5IGxp a2UgdG8gbW92ZSBmb3J3YXJkLiZuYnNwOyBXZSdkIGxpa2UgdG8gd29yayB0b3dhcmQgYSBjb25j bHVzaW9uIGFuZCB3ZWxjb21lIGNvbW1lbnRzIGZyb20NCiB0aGUgZ3JvdXAuPGJyPg0KPGJyPg0K WzFdIDxhIGhyZWY9Imh0dHBzOi8vcmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbS9tcmlzaGVyL3Nt dHAtc3RzL0tWX1ZlcnNpb24vbXRhLXN0cy50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8v cmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbS9tcmlzaGVyL3NtdHAtc3RzL0tWX1ZlcnNpb24vbXRh LXN0cy50eHQ8L2E+PGJyPg0KPGJyPg0KLS08YnI+DQpBbGV4IEJyb3RtYW48YnI+DQpTci4gRW5n aW5lZXIsIEFudGktQWJ1c2U8YnI+DQpDb21jYXN0PGJyPg0KeDUzNjQ8YnI+DQo8YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClV0 YSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VXRhQGlldGYub3JnIj5VdGFAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby91dGEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3V0YTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_fe051513ca954006a384f4695473355bCOPDCEX19cablecomcastco_-- From nobody Mon Jul 17 14:34:39 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 36293124234 for ; Mon, 17 Jul 2017 14:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 W2eDZ4xZv7Zn for ; Mon, 17 Jul 2017 14:34:35 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.22.87]) (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 109801293E1 for ; Mon, 17 Jul 2017 14:34:35 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 6E74B1E6C2; Mon, 17 Jul 2017 21:34:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1500327273; bh=6sjyR5CkTS2jWbTh4Ezyi+Az8gBYhegpJiiTrPTTmOU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=FyKd6CBhYK4Tqj4Ap6lWqySfp5L2c+oPy3q0Gwbpt+qnsRDESXc4tfC1FKBJeE96T agrH81P85TJCIWgNao7lKPHBOP/Kf9UHUKKVJ8aFl5QOxtPb7sEesY4BspOk5tdWNQ IDEGP3ZLrV7YVrr0du1Wh2SknRD+NdnhTrXEX7vpSpwdZhVv+aNCGQ8PppBBMe/EQT DKlopZRgXJ4g6f1GaZPWWN0iY04VnKs5PPO06JDUIP7exF0gHaNjtr42Bu0Nr8E1i+ kDMs4IrlJGWT4u/ahEdMk0KsDfUBb3hUBXS+H+/GgMcb+MW19luz/9aV3KyxztOqSb Za6fPwC+YvB1g== Received: by carbon.jhcloos.org (Postfix, from userid 500) id A16AE107AC445; Mon, 17 Jul 2017 21:33:55 +0000 (UTC) From: James Cloos To: Cc: "Brotman\, Alexander" In-Reply-To: <6eae98161ea442b5920a28814ee3ec1d@COPDCEX19.cable.comcast.com> (Alexander Brotman's message of "Mon, 17 Jul 2017 19:17:08 +0000") References: <6eae98161ea442b5920a28814ee3ec1d@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: Mon, 17 Jul 2017 17:33:55 -0400 Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:170717:uta@ietf.org::86uIuFEKc0PVuv5i:0000703XJ X-Hashcash: 1:28:170717:alexander_brotman@comcast.com::zkgnwGLFDUP3eH0J:00000000000000000000000000000003L7WS Archived-At: Subject: Re: [Uta] MTA-STS: A Key-Value Alternative 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, 17 Jul 2017 21:34:37 -0000 >>>>> Brotman, Alexander writes: > [1] https://raw.githubusercontent.com/mrisher/smtp-sts/KV_Version/mta-sts.txt First, the KV style will work better than json. +1 The rfc should specify what an sts client do with a mode:report when there is no _smtp-tlsrpt RR? I presume it should just skip reporting, but it should be specified. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Jul 17 14:42: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 2D8A7128BA2 for ; Mon, 17 Jul 2017 14:42:34 -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 (2048-bit key) header.d=jhcloos.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE6NYbo2Luej for ; Mon, 17 Jul 2017 14:42:32 -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 C1312131CC3 for ; Mon, 17 Jul 2017 14:42:32 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 1FB4E1E6C2; Mon, 17 Jul 2017 21:42:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1500327752; bh=BJ3ua5CbNiPgKGgsX6y8eRidxYxo1N6LQybMtoWwMJc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=r5C9aLOk92BEq/Vf7iiP2/21kSe+aDNnl0GDLrjWddNAW/AYyuftX34M2iwrB61Dd c0g0H1d7NkXYERkah+/TJS6GNS1gblw+DOHU+XHWny8wDsQ0fdzi8mLtJtBKWkLVAX 5WkbDjFLEu6JNOMIRG1gVRF0k0XWN2erimPyExZdgDu843rGdZA2zZdvCiMwVNzTg6 4Okg7yorTHQEHUAGDpHqV54HkYUX7ldvdgHYRUZFT7oj5+1yg0faS+4simSO9/FrVr J9MPdaK+qgMZhc095HCWdcbGMFj539rsugs5vWoGP4ydULYlYPziOZl6EYhmhQtitj 5CnGPKW0HEwBA== Received: by carbon.jhcloos.org (Postfix, from userid 500) id CE424107AC445; Mon, 17 Jul 2017 21:40:32 +0000 (UTC) From: James Cloos To: Cc: "Brotman\, Alexander" , David Illsley In-Reply-To: (Alexander Brotman's message of "Mon, 17 Jul 2017 20:09:03 +0000") References: <6eae98161ea442b5920a28814ee3ec1d@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: Mon, 17 Jul 2017 17:40:32 -0400 Message-ID: Lines: 11 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Hashcash: 1:28:170717:uta@ietf.org::lCgw93BA0zMl5EFD:0000Cl4Gv X-Hashcash: 1:28:170717:alexander_brotman@comcast.com::abm0pVDhGfNPr4eF:00000000000000000000000000000006db63 X-Hashcash: 1:28:170717:davidillsley@gmail.com::Gx7ToRrmpFr7S3+o:00000000000000000000000000000000000000FI+wc Archived-At: Subject: Re: [Uta] MTA-STS: A Key-Value Alternative 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, 17 Jul 2017 21:42:34 -0000 >>>>> "AB" == Brotman, Alexander writes: AB> We could obviously change this to something that is AB> more well-known (txt or similar) so that we don’t need to do this. text/plain works. It could be something like text/kv or text/key-value, but the doc should say that all clients MUST accept text/plain. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue Jul 18 06:26: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 13F97131B4B for ; Tue, 18 Jul 2017 06:26:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 6t2TU0wb1Sgn for ; Tue, 18 Jul 2017 06:26:55 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 5A4AF12EC51 for ; Tue, 18 Jul 2017 06:26:53 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id y43so29401442wrd.3 for ; Tue, 18 Jul 2017 06:26:53 -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=E/Yt5PLG9mylWp3K78HLBLpZX0/GJqHXwXFmZaMB6u8=; b=LvBbXmEnU8B1gLZpoWbW8Eudg3I2YVc57W/XEi2lcGmirZ94KT9zDbssOScLz0EIrs 9+yJKMAA/0dLLS9usehAs/8b7I/GRa+kaudl5X0Q63RCNHmrkJLD1RMPzzp1kbH1UhMg uVdfV72m6RNWwipQj9ufDr4MXMNwmJdJQnduGsQKggNb2fi0vk4OFiB92NR1KbqGTemi fALA/BJrcFxR/qnSmg7ND8lwSYtexN/rhvBreK28cLKFmyHlbyobG0V3ynM4dy2kF4EY 8swQRJuUsztLC6FVsLyKHX2KyXcfUl3PRqGJBXYhzxOsIEnEdx6izon5m1NT41sHaOji EcHg== 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=E/Yt5PLG9mylWp3K78HLBLpZX0/GJqHXwXFmZaMB6u8=; b=KGPPhLNjUhshHaWI8C9f57qbkZ8n3LHMIJaO4mQdWhY/venGTjw+Qm3ucm7YYK2rAH Ea5z91TOyEF0yvGJ5h//w8nJGi+dIVSOdh3hNoURJ9y0/NcaY6VhpwF+4LIj5Z6sl34V +QOAz6DaPS8mJhaTd+JmwASunHilQcDfoxfhfgB9npUj8fbqhiJ/hZJVapjOA57mqQGL q5ad96ZhQSoXj7rOKRQYpFaO4hc8TH8WoASxVkpqBDk0fml6BSV0/Sh4YtXzJ6lZSMGg 0ih/bmvV9LybxsysbYnlZa0pNtE7GNH6VvtF27qBibnWf+1YfBWQFz//xD4kWRk1o9ll 0Rsw== X-Gm-Message-State: AIVw112Czr4ZfhigxPhyBu1SfDeLP6++UTENk48Xmte1A5/f9EF5QLmB HrY+0KFsp1h3F3z+QZLZSajkFlcjvbxZ X-Received: by 10.223.133.35 with SMTP id 32mr1193714wrh.30.1500384411622; Tue, 18 Jul 2017 06:26:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.184.200 with HTTP; Tue, 18 Jul 2017 06:26:50 -0700 (PDT) In-Reply-To: References: <6eae98161ea442b5920a28814ee3ec1d@COPDCEX19.cable.comcast.com> From: Daniel Margolis Date: Tue, 18 Jul 2017 15:26:50 +0200 Message-ID: To: James Cloos Cc: uta@ietf.org, "Brotman, Alexander" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0d0e30e74bb905549777d4" Archived-At: Subject: Re: [Uta] MTA-STS: A Key-Value Alternative 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 Jul 2017 13:26:57 -0000 --94eb2c0d0e30e74bb905549777d4 Content-Type: multipart/alternative; boundary="94eb2c0d0e30e256f0055497773a" --94eb2c0d0e30e256f0055497773a Content-Type: text/plain; charset="UTF-8" What to do without any TLSRPT support is sort of implied: 1. "report": In this mode, sending MTAs merely send a report (as described in the TLSRPT specification (TODO: add ref)) indicating policy application failures. Of course, per the TLSRPT specification, if there's no TLSRPT RR, there's no reporting. ;) Granted, it may be isn't quite as explicit as it should be. Do you think we need to call that out (i.e. "if senders and recipients both implement TLSRPT")? On Mon, Jul 17, 2017 at 11:33 PM, James Cloos wrote: > >>>>> Brotman, Alexander writes: > > > [1] https://raw.githubusercontent.com/mrisher/smtp-sts/KV_ > Version/mta-sts.txt > > First, the KV style will work better than json. +1 > > The rfc should specify what an sts client do with a mode:report when > there is no _smtp-tlsrpt RR? > > I presume it should just skip reporting, but it should be specified. > > -JimC > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --94eb2c0d0e30e256f0055497773a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What to do without any TLSRPT support is sort of implied:<= div>

=C2=A0 =C2=A01. =C2=A0"report&q= uot;: In this mode, sending MTAs merely send a report (as
=C2=A0 = =C2=A0 =C2=A0 =C2=A0described in the TLSRPT specification (TODO: add ref)) = indicating
=C2=A0 =C2=A0 =C2=A0 =C2=A0policy application failures= .

Of course, per the TLSRPT specification, i= f there's no TLSRPT RR, there's no reporting. ;)

Granted, it may be isn't quite as explicit as it should be. Do y= ou think we need to call that out (i.e. "if senders and recipients bot= h implement TLSRPT")?=C2=A0

=
On Mon, Jul 17, 2017 at 11:33 PM, James Cloos <= cloos@jhcloos.com> wrote:
&= gt;>>>> Brotman, Alexander <Alexander_Brotman@comcast.com> writes:

> [1] https://raw.github= usercontent.com/mrisher/smtp-sts/KV_Version/mta-sts.txt

First, the KV style will work better than json.=C2=A0 +1

The rfc should specify what an sts client do with a mode:report when
there is no _smtp-tlsrpt RR?

I presume it should just skip reporting, but it should be specified.

-JimC
--
James Cloos <cloos@jhcloos.com&= gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OpenPGP: 0x997A9F17ED7DAEA6

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

--94eb2c0d0e30e256f0055497773a-- --94eb2c0d0e30e74bb905549777d4 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 K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDtFE2V9IdjeR6e 5ESLyaqJ9zMpnmMLbeWGx264UP3u1jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA3MTgxMzI2NTFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAQy2WKmaJT3QAtUGlYIcLEgsV4Be2rp/K 2KvkImlfYf/KVtJJWsQ3Sz1xWcWONdi6KM2ndtSc93TzW7FHgESg0XeSNqx1tn19hSlYBqPlLl2n cHTQ1VU8hZS2XT1fyHJa2tEKr+hqyaH20GdiSNNgNnrl7jLOytwV6QtVI1TEkKKskVergl0BTrSj t+tjKU5gyCXbeulcqCfFUg93spqOVLO2G4hehgQkbbjC3eA5G71xtiPcXRtusrAtZGc6F8bDLpnN TOCdQxoWdTsloM8n7/1djMkcaRciSxkJfJ44BYl7R8oCoFF8TQuMSdeICORv03ssCyQ5yWV/twXR E92QdA== --94eb2c0d0e30e74bb905549777d4-- From nobody Tue Jul 18 08:15: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 02188131686 for ; Tue, 18 Jul 2017 08:15:31 -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 (2048-bit key) header.d=jhcloos.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kj_QyL4bskq for ; Tue, 18 Jul 2017 08:15:29 -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 7CF5D1204DA for ; Tue, 18 Jul 2017 08:15:28 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 275CC1E474; Tue, 18 Jul 2017 15:15:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1500390927; bh=AnLuhAyO+bBmu4T17jcR9muQzZdvyRDofpOCepjIvok=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=snbjFbeDnwZgM5TKHQvs731mFZSdcWZ/ctr4znkoNwUBKBzoQtl7/k+VD0DtVogso eRHIlpNPChW2sUi6VvKek4slH5MBxCDzm4RUbTSpX0QXW38nez+UJubPJFPGRGSZO1 UNz89gRqqzzM7/6c272MnrF2wuT6Leu5xXrm10JJypKbwvs+X942dheKkzSjniJP+v u58dP1Y5S70UaFlmyjeL0RBonVnWa3dZLFxt/GTdEeQVi0MHJOy/49H2M8OQzuuxjf dZDeNqrb1bbS6/9kug63pipPlNmGe55Uu2/09WI6lhMxBPXUjZDWJkvh2PftZFP+66 PN5Q5YvZQHgEg== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 2FCF7107AC442; Tue, 18 Jul 2017 15:12:30 +0000 (UTC) From: James Cloos To: Daniel Margolis Cc: uta@ietf.org, "Brotman\, Alexander" In-Reply-To: (Daniel Margolis's message of "Tue, 18 Jul 2017 15:26:50 +0200") References: <6eae98161ea442b5920a28814ee3ec1d@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: Tue, 18 Jul 2017 11:12:30 -0400 Message-ID: Lines: 16 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:170718:dmargolis@google.com::k6PTZh9nZj27kDy+:0000000000000000000000000000000000000000KTcn9 X-Hashcash: 1:28:170718:uta@ietf.org::vqvBOWp6eWUxJWqJ:0000Sh9Kk X-Hashcash: 1:28:170718:alexander_brotman@comcast.com::Tp+tjf4L5mkRz2J7:00000000000000000000000000000003sVDx Archived-At: Subject: Re: [Uta] MTA-STS: A Key-Value Alternative 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 Jul 2017 15:15:31 -0000 >>>>> "DM" == Daniel Margolis writes: DM> Of course, per the TLSRPT specification, if there's no TLSRPT RR, there's DM> no reporting. ;) DM> Granted, it may be isn't quite as explicit as it should be. Do you think we DM> need to call that out (i.e. "if senders and recipients both implement DM> TLSRPT")? Yes, that was my point. This doc should be explicit in that case. There a lots of ways to word it, your quote above works. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Thu Jul 20 05:28: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 02A62131794 for ; Thu, 20 Jul 2017 05:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 YSD76RGuvXNu for ; Thu, 20 Jul 2017 05:28:28 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 B8F8B13178B for ; Thu, 20 Jul 2017 05:28:28 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6KCSNb3014699 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 20 Jul 2017 12:28:24 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v6KCSNR7001139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 20 Jul 2017 12:28:23 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6KCSMRv029500; Thu, 20 Jul 2017 12:28:22 GMT Received: from [31.133.136.2] (/31.133.136.2) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jul 2017 05:28:22 -0700 From: "Chris Newman" To: "Leif Johansson" Cc: uta@ietf.org Date: Thu, 20 Jul 2017 14:28:19 +0200 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:28:30 -0000 > The report is composed as a plain text file encoded in the JSON > format ([RFC7159]). Can we use I-JSON format instead? RFC 7493. I'd prefer if the report is encoded in UTF-8 rather than an arbitrary Unicode encoding that the recipient has to dynamically detect. > o "email-address": The contact information for a responsible party > of the report. It is provided as a string formatted according to > Section 3.4.1, "Addr-Spec", of [RFC5322]. Can we format according to the "Mailbox" rule in section 4.1.2 of [RFC5321]? I'd prefer not to require receivers to strip out FWS & CFWS from the address. > tlsrpt-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" > %x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:" > domain-name 1*FWS ; from RFC 6376 > %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" > 1*FWS domain-name 1*FWS > %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" > msg-id ; from RFC 5322 Where is 'FWS' defined? If it's the FWS from RFC 5322, then you need to change "1*FWS" to "FWS" in all 5 places. Can you please reference RFC 7405 to improve readability, so this can be rewritten as: tlsrpt-subject = %s"Report" FWS %s"Domain:" FWS domain-name %s"Submitter:" FWS domain-name FWS %s"Report-ID:" msg-id Also, you might want to instead use: %s"Report-ID" FWS "<" id-left "@" id-right ">" [CFWS] so there's no need to skip over comments (CFWS) to extract the report id. - Chris From nobody Thu Jul 20 09:02: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 2E40A131CE7 for ; Thu, 20 Jul 2017 09:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 sJzP6XyIDY7o for ; Thu, 20 Jul 2017 09:02:05 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.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 5B73A131C3E for ; Thu, 20 Jul 2017 09:02:05 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6KG24Mk031506 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 20 Jul 2017 16:02:04 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v6KG23ZD021250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 20 Jul 2017 16:02:04 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6KG23hZ019816 for ; Thu, 20 Jul 2017 16:02:03 GMT Received: from [31.133.136.2] (/31.133.136.2) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jul 2017 09:02:03 -0700 From: "Chris Newman" To: uta@ietf.org Date: Thu, 20 Jul 2017 18:02:00 +0200 Message-ID: <9A41D7B1-4D4C-4605-8161-7985E30B1044@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: [Uta] review of draft-ietf-uta-mta-sts-07 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, 20 Jul 2017 16:02:07 -0000 Overall, I find the document hard to read and the structure problematic. If I'm verifying STS policy, I want to know how to fetch the policy, then I want to know what to fetch. The document structure is awkward for that goal. And if I want to publish STS policy, I want to know where I publish it and then what I need to publish. An editorial pass to reorganize the document to be more useful and clear for an implementer would be helpful. There's also an overuse of "quotes" around terminology which is problematic in a document with JSON strings which need to be quoted in the context of protocol examples. It'd be helpful to have an example workflow, possibly early in the document. Something like: Example: recipient: user@example.com Determine policy domain [section reference], in this case example.com Look up DNS TXT record in _mta-sts.example.com (_mta-sts TXT record in policy domain). [section reference]. If failure or invalid record, stop. If valid cached policy record, skip forward to SMTP connection. Connect to https server at mta-sts.example.com (mta-sts host in policy domain). [section reference] Verify HTTPS TLS certificate as matching domain mta-sts.example.com [section reference]. Fetch policy from /.well-known/mta-sts.json [section reference]. Connect to SMTP server according to SMTP standard. Perform STARTTLS Verify TLS negotiation and hostname matches STS policy [section reference]. > transmission into authenticated, downgrade-resistent encrypted > tarnsmission. Fix spelling: resistent->resistant, tarnsmission => transmission > sts-version = %x76 *WSP "=" *WSP %x53 %x54 ; "v=STSv1" > %x53 %x76 %x31 I recommend you improve ABNF readability by referencing RFC 7405. std-version = %s"v=STSv1" > The policy itself is a JSON [RFC7159] object served via the HTTPS > GET This reference needs to be changed to draft-ietf-jsonbis-rfc7159bis, or you need to explicitly require use of UTF-8 charset, or reference I-JSON (RFC 7493). With RFC 7159 there's a requirement to support and detect UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE charsets (and possibly other Unicode encodings) that I find highly problematic for interoperability. > 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 below), chain to a root CA that is trusted by the After reading the document, I'm not sure I understand how to construct the DNS FQDN that I need to pass to the TLS API in order to validate the mta-sts host. In the example workflow above, I made a guess. But the document presently never says how to construct the FQDN explicitly. > The certificate MAY be checked for revocation via the Online > Certificate Status Protocol (OCSP) [RFC2560], certificate revocation > lists (CRLs), or some other mechanism. Is there a reason this is a MAY rather than a SHOULD? > 3.4. Policy Selection for Smart Hosts and Subdomains It's confusing to group two very different aspects of mail operations into a single section. I'd suggest making this two sections. > certificate MUST have a CN-ID ([RFC6125]) or SAN ([RFC5280]) with a The abbreviation "SAN" doesn't appear in RFC 5280. Please expand it to subjectAltName which does appear. > DNS-ID matching the "mx" pattern. The MX's certificate MAY also be > checked for revocation via OCSP [RFC2560], certificate revocation > lists (CRLs), or some other mechanism. Is there a reason this is a MAY rather than a SHOULD? > New fields are added to this registry using IANA's "Expert Review" > policy. Please add some guidance to the expert reviewer on the criteria that should be met when registering new fields. You can leave the reviewer some wiggle room, but having guidance sets expectations for the person registering the new field, the expert reviewer and for any IESG appeal that might result from a disagreement. > 8. Security Considerations One more security consideration: This mechanism causes an MTA (an automated system) to adopt the role of an HTTPS client in a scenario where the HTTPS server may be hostile to operation of the MTA. A full HTTP stack is a large amount of code that may contain coding errors that expose the MTA to new implementation vulnerabilities. This threat can be partially mitigated by using a hardened HTTPS client library that has been tested against a fuzzing HTTPS test server. This threat can also be partially mitigated by isolating the HTTPS code into a separate process that does not have access to the normal MTA machinery and making sure the MTA machinery gracefully handles a wedged HTTPS client. Sites that are evaluating the cost/benefit of this functionality may wish to compare the new attack surface of this mechanism with the new attack surface of alternate mechanisms such DANE [RFC7672]. - Chris From nobody Thu Jul 20 10:00: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 C3111131C25 for ; Thu, 20 Jul 2017 10:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Ij6jkm6NwYwo for ; Thu, 20 Jul 2017 10:00:14 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 C34DF131AFC for ; Thu, 20 Jul 2017 10:00:05 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id f21so16789008wrf.5 for ; Thu, 20 Jul 2017 10:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:cc:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=J9opimjlhBGKSsYeqXVbkVxw9mUYsTnIHbLZ3iAV4hE=; b=sew/BpKtSx19XAnapVoKjtyHyK4fRC/cLNEFwduNOzfS/ynBsxI5563gku7QGxbT9v QO22UlL2xgV/TCKZiPQTH5GzCvDxSy0fYAkvNZ8FIFCNBbCHBbYG9Oo/bFQpd6VDbe1i r6ceS43gRUuP1BNIMQUob/ebNKShNCDcIvDUt0LjFo2zHfzXE12NB6rJkbtWI6n3o8rS +E3YWpnU0veFcq0fc+EJIJgRSa4GT70celY3YLcWhruMns9wiJy/j78vNvJR/tA2AW3u FL+7459RlMThOdUYeXkf+YMimLp+iru/v+ZJuGNdWB4a/V/ghqgWWxso6RmlhwbPklE1 JpVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:cc:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=J9opimjlhBGKSsYeqXVbkVxw9mUYsTnIHbLZ3iAV4hE=; b=GhetBDFk1BsIaBq1BXMtQgjB1ECG7EPP9Jg7iwiqpHCtuW0WVka0s5T14fBexQsF/e kG2ptXLjqPADpwTJgAgpacr6hOhTvoPt1+ln1RINnB3wIICotuZJOaymb1zjGjHFgwhi teWar1iD1xE33PLRomN8+FMZYGXDx3ll/979atXIWf9PCbrxrev6bMw7gT7ExxC6MibI vNTXASuypZbOo/5nf1RNhJf8/P7R4+9N+iibeOCGKg8N6tMgvp44eCJSH19Oq4OcpbPF 6hMi5wWXo1TFZbEfVVGaxiREi83Kn/lCxQSp81yTPVhhAp45IDu3R8YhQyO9y5VS/KHB yTAQ== X-Gm-Message-State: AIVw111GLS0r1SWH/LGgD6wYdI7Gbxg/3NKUVwvckH4AdOR8xyZI1ZsX cRWG0o4GLdJwRL/pr44= X-Received: by 10.223.138.167 with SMTP id y36mr7498425wry.176.1500570004330; Thu, 20 Jul 2017 10:00:04 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:78cb:f147:e41:b5bd? ([2001:67c:370:128:78cb:f147:e41:b5bd]) by smtp.gmail.com with ESMTPSA id v203sm2930293wmd.2.2017.07.20.10.00.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 10:00:03 -0700 (PDT) From: Yaron Sheffer Cc: uta@ietf.org, Daniel Migault Message-ID: <64b0ca8d-1d57-53bc-742a-dda9690db6e1@gmail.com> Date: Thu, 20 Jul 2017 19:00:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Uta] Ticket Pinning draft 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, 20 Jul 2017 17:00:16 -0000 As I mentioned at the session today, UTA WG members might be interested in our draft on Ticket Pinning, which is an alternative to HPKP (the certificate pinning RFC that has only seen weak adoption). Our solution is much easier to automate, and therefore drastically reduces the risk of a server being "bricked" because of a human error, which we believe has been the main reason hurting HPKP adoption. Possibly more relevant for this group: ticket pinning is at the TLS layer, and does not depend on HTTP. So it could apply to SMTP or IMAP for example. The draft is here [1] but you can just browse the slides instead [2]. If people are interested in identity pinning for non-web applications, please respond privately to Daniel Migault and myself. Thanks, Yaron [1] https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/ [2] https://www.ietf.org/proceedings/97/slides/slides-97-tls-ticket-pinning-00.pdf From nobody Thu Jul 20 11:54:57 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 1F6F9131B7A for ; Thu, 20 Jul 2017 11:54:56 -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 M_tqN-2y1-dD for ; Thu, 20 Jul 2017 11:54:53 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 E4DD2124E15 for ; Thu, 20 Jul 2017 11:54:52 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id x6so9511375ywd.1 for ; Thu, 20 Jul 2017 11:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R9aD2KssKeNT8/FlIkHY307jA29ZNTCJiCveB057F9s=; b=nluFncgBLHzK2ceH7pqiSEmu4AnFRgOatg+pamRSqiz+qKaBgK+eCJjVJLtui6JJTl kfAsRC5CK5tYI4HyiFF95Ay77wJOn4ZQEVjLwCdS582vcFfck9rYLNvlnD+G1Z3wwBZK zN8yfVFNiabDOgPcNWWXeU28q0LYqNDuTWyky4c6eXQ0Js5wnATwEoXMXovfO/z1XPhP TSElK5bdCA26rNi2jRWTZ6nSOfxap3rUHSAL8EcMZyVKE5ZCtC6DHl3n/mjuStsCjvIA dTXomZGYFbg/lIe1mt7NIDlRGWyGwYQ8t5CTXPfPJbC0sAurXFdvi01Bwb64jVLSZFm8 P+dA== 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=R9aD2KssKeNT8/FlIkHY307jA29ZNTCJiCveB057F9s=; b=qd4Y/K5yLZLm6+kXpIaTwwHEuKLsA0bzr94BBadOzUetlRZI4OQyFCvCrwry/rGfQJ kK4daaxIkb1rD6/bfIcI2z9RWAknvFLUOzg9jGn2pv8fXvlnxzc0bdcXzrvvtwr7dLxi TbBRjjw+6ilE/3A1wrdBqz2WVAW2z62/p3/bxS8t9kyhnraUo8IFUVRtPOZCaZ/q63hr 1apEVADpWFXzF1TX51P92iJwfJBgRen5RuafjTZXchjM2904wrMRMl1sEcljQJRZGCVD fvTsHLlwmd+VmlQ4G8+XNX0dq36tIjs6ej4Q56PtVgDx0NCnKEB54Lauwjc3kjEF3N3H AA4Q== X-Gm-Message-State: AIVw111/3pOy0wZ14j4+44EaLfPM50uR3FmDSwlbV8xmjqNCZLV6li0M GnLU92fx2vHve0NG3c3KZbBQwitRAWlZ X-Received: by 10.129.91.135 with SMTP id p129mr3971301ywb.209.1500576891946; Thu, 20 Jul 2017 11:54:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.80.144 with HTTP; Thu, 20 Jul 2017 11:54:51 -0700 (PDT) In-Reply-To: <9A41D7B1-4D4C-4605-8161-7985E30B1044@oracle.com> References: <9A41D7B1-4D4C-4605-8161-7985E30B1044@oracle.com> From: Daniel Margolis Date: Thu, 20 Jul 2017 20:54:51 +0200 Message-ID: To: Chris Newman Cc: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114c929ca0e0ae0554c44814" Archived-At: Subject: Re: [Uta] review of draft-ietf-uta-mta-sts-07 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, 20 Jul 2017 18:54:56 -0000 --001a114c929ca0e0ae0554c44814 Content-Type: multipart/alternative; boundary="001a114c929c9adbd40554c4485f" --001a114c929c9adbd40554c4485f Content-Type: text/plain; charset="UTF-8" Hey, Chris, Thanks for the thorough review. A few inline comments off the cuff; others we will have to address in the draft. On Thu, Jul 20, 2017 at 6:02 PM, Chris Newman wrote: > Overall, I find the document hard to read and the structure problematic. > If I'm verifying STS policy, I want to know how to fetch the policy, then I > want to know what to fetch. The document structure is awkward for that > goal. And if I want to publish STS policy, I want to know where I publish > it and then what I need to publish. An editorial pass to reorganize the > document to be more useful and clear for an implementer would be helpful. Do you have any suggestions of a restructuring? The current structure is (of course) _intended_ to be natural, in that we start with how to discover a policy (i.e., for senders, how to publish a policy), then how to validate a policy (i.e., for senders, how to decide what should go in your policy), then how to apply a policy (i.e. what the different "mode" options mean and how they affect delivery). I'm not at all averse to changing it, but it would help us a bit to have more specific suggestions, if you have any. I and the other authors obviously intended this to be a natural flow, so we may not be in the best position to see what is awkward about it. :) > There's also an overuse of "quotes" around terminology which is > problematic in a document with JSON strings which need to be quoted in the > context of protocol examples. > > It'd be helpful to have an example workflow, possibly early in the > document. Something like: > I think Appendix 2 covers more or less this, but in pseudocode. Are you suggesting that it would be better to have that be textual rather than pseudocode, be in-document rather than an appendix, or both? > Example: > recipient: user@example.com > Determine policy domain [section reference], in this case example.com > Look up DNS TXT record in _mta-sts.example.com (_mta-sts TXT record in > policy domain). [section reference]. > If failure or invalid record, stop. > If valid cached policy record, skip forward to SMTP connection. > Connect to https server at mta-sts.example.com (mta-sts host in policy > domain). [section reference] > Verify HTTPS TLS certificate as matching domain mta-sts.example.com > [section reference]. > Fetch policy from /.well-known/mta-sts.json [section reference]. > Connect to SMTP server according to SMTP standard. > Perform STARTTLS > Verify TLS negotiation and hostname matches STS policy [section > reference]. > > transmission into authenticated, downgrade-resistent encrypted >> tarnsmission. >> > > Fix spelling: resistent->resistant, tarnsmission => transmission > > sts-version = %x76 *WSP "=" *WSP %x53 %x54 ; "v=STSv1" >> %x53 %x76 %x31 >> > > I recommend you improve ABNF readability by referencing RFC 7405. > > std-version = %s"v=STSv1" > > The policy itself is a JSON [RFC7159] object served via the HTTPS GET >> > > This reference needs to be changed to draft-ietf-jsonbis-rfc7159bis, or > you need to explicitly require use of UTF-8 charset, or reference I-JSON > (RFC 7493). With RFC 7159 there's a requirement to support and detect > UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE charsets (and possibly other Unicode > encodings) that I find highly problematic for interoperability. > > 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 below), chain to a root CA that is trusted by the >> > > After reading the document, I'm not sure I understand how to construct the > DNS FQDN that I need to pass to the TLS API in order to validate the > mta-sts host. In the example workflow above, I made a guess. But the > document presently never says how to construct the FQDN explicitly. > > The certificate MAY be checked for revocation via the Online >> Certificate Status Protocol (OCSP) [RFC2560], certificate revocation >> lists (CRLs), or some other mechanism. >> > > Is there a reason this is a MAY rather than a SHOULD? > Yes. The security value of OCSP is contentious (e.g. https://www.imperialviolet.org/2014/04/19/revchecking.html) and support for it in HTTPS client libs is (AFAICT) haphazard; e.g. https://curl.haxx.se/libcurl/c/CURLOPT_SSL_VERIFYSTATUS.htmlhttps://stackoverflow.com/questions/25803455/how-to-add-ocsp-support-into-python-requests-library. Making OCSP a MUST seems to make implementation harder for questionable gain. > > 3.4. Policy Selection for Smart Hosts and Subdomains >> > > It's confusing to group two very different aspects of mail operations into > a single section. I'd suggest making this two sections. > certificate MUST have a CN-ID ([RFC6125]) or SAN ([RFC5280]) with a >> > > The abbreviation "SAN" doesn't appear in RFC 5280. Please expand it to > subjectAltName which does appear. > > DNS-ID matching the "mx" pattern. The MX's certificate MAY also be >> checked for revocation via OCSP [RFC2560], certificate revocation >> lists (CRLs), or some other mechanism. >> > > Is there a reason this is a MAY rather than a SHOULD? > > New fields are added to this registry using IANA's "Expert Review" >> policy. >> > > Please add some guidance to the expert reviewer on the criteria that > should be met when registering new fields. You can leave the reviewer some > wiggle room, but having guidance sets expectations for the person > registering the new field, the expert reviewer and for any IESG appeal that > might result from a disagreement. > > 8. Security Considerations >> > > One more security consideration: > > This mechanism causes an MTA (an automated system) to adopt the role of an > HTTPS client in a scenario where the HTTPS server may be hostile to > operation of the MTA. A full HTTP stack is a large amount of code that may > contain coding errors that expose the MTA to new implementation > vulnerabilities. This threat can be partially mitigated by using a hardened > HTTPS client library that has been tested against a fuzzing HTTPS test > server. This threat can also be partially mitigated by isolating the HTTPS > code into a separate process that does not have access to the normal MTA > machinery and making sure the MTA machinery gracefully handles a wedged > HTTPS client. Sites that are evaluating the cost/benefit of this > functionality may wish to compare the new attack surface of this mechanism > with the new attack surface of alternate mechanisms such DANE [RFC7672]. > > - Chris > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a114c929c9adbd40554c4485f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey, Chris,=C2=A0

Thanks for the thorou= gh review. A few inline comments off the cuff; others we will have to addre= ss in the draft.=C2=A0

On Thu, Jul 20, 2017 at 6:02 PM, Chris Newman = <chris.newm= an@oracle.com> wrote:
Overall, I find the document hard to read and the structure p= roblematic. If I'm verifying STS policy, I want to know how to fetch th= e policy, then I want to know what to fetch. The document structure is awkw= ard for that goal. And if I want to publish STS policy, I want to know wher= e I publish it and then what I need to publish. An editorial pass to reorga= nize the document to be more useful and clear for an implementer would be h= elpful.

Do you have any suggestions of a r= estructuring? The current structure is (of course) _intended_ to be natural= , in that we start with how to discover a policy (i.e., for senders, how to= publish a policy), then how to validate a policy (i.e., for senders, how t= o decide what should go in your policy), then how to apply a policy (i.e. w= hat the different "mode" options mean and how they affect deliver= y).=C2=A0

I'm not at all averse to changing it= , but it would help us a bit to have more specific suggestions, if you have= any. I and the other authors obviously intended this to be a natural flow,= so we may not be in the best position to see what is awkward about it. :)= =C2=A0
=C2=A0
There's also an overuse of "quotes" around terminology wh= ich is problematic in a document with JSON strings which need to be quoted = in the context of protocol examples.

It'd be helpful to have an example workflow, possibly early in the docu= ment. Something like:

I think Appendix = 2 covers more or less this, but in pseudocode. Are you suggesting that it w= ould be better to have that be textual rather than pseudocode, be in-docume= nt rather than an appendix, or both?
=C2=A0
Example:
=C2=A0recipient: user= @example.com
=C2=A0Determine policy domain [section reference], in this case example.com =C2=A0Look up DNS TXT record in _mta-sts.example.com (_mta-sts TXT rec= ord in policy domain). [section reference].
=C2=A0If failure or invalid record, stop.
=C2=A0If valid cached policy record, skip forward to SMTP connection.
=C2=A0Connect to https server at mta-sts.example.com (mta-sts host in = policy domain). [section reference]
=C2=A0Verify HTTPS TLS certificate as matching domain mta-sts.example.com<= /a> [section reference].
=C2=A0Fetch policy from /.well-known/mta-sts.json [section reference].
=C2=A0Connect to SMTP server according to SMTP standard.
=C2=A0Perform STARTTLS
=C2=A0Verify TLS negotiation and hostname matches STS policy [section refer= ence].

transmission into authenticated, downgrade-resistent encrypted
tarnsmission.

Fix spelling: resistent->resistant, tarnsmission =3D> transmission
sts-version=C2=A0 =C2=A0 =C2=A0=3D %x76 *WSP "=3D" *WSP %x53 %x54= =C2=A0 =C2=A0 =C2=A0 =C2=A0; "v=3DSTSv1"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x53 %x76 %x= 31

I recommend you improve ABNF readability by referencing RFC 7405.

=C2=A0std-version=C2=A0 =C2=A0 =3D %s"v=3DSTSv1"

=C2=A0 The policy itself is a JSON [RFC7159] object served via the HTTPS GE= T

This reference needs to be changed to draft-ietf-jsonbis-rfc7159bis, or you= need to explicitly require use of UTF-8 charset, or reference I-JSON (RFC = 7493). With RFC 7159 there's a requirement to support and detect UTF-16= LE, UTF-16BE, UTF-32LE, UTF-32BE charsets (and possibly other Unicode encod= ings) that I find highly problematic for interoperability.

=C2=A0 When fetching a new policy or updating a policy, the HTTPS endpoint<= br> =C2=A0 MUST present a X.509 certificate which is valid for the "mta-st= s"
=C2=A0 host (as described below), chain to a root CA that is trusted by the=

After reading the document, I'm not sure I understand how to construct = the DNS FQDN that I need to pass to the TLS API in order to validate the mt= a-sts host. In the example workflow above, I made a guess. But the document= presently never says how to construct the FQDN explicitly.

=C2=A0 The certificate MAY be checked for revocation via the Online
=C2=A0 Certificate Status Protocol (OCSP) [RFC2560], certificate revocation=
=C2=A0 lists (CRLs), or some other mechanism.

Is there a reason this is a MAY rather than a SHOULD?
=C2=A0

3.4.=C2=A0 Policy Selection for Smart Hosts and Subdomains

It's confusing to group two very different aspects of mail operations i= nto a single section. I'd suggest making this two sections.=C2=A0

=C2=A0 certificate MUST have a CN-ID ([RFC6125]) or SAN ([RFC5280]) with a<= br>

The abbreviation "SAN" doesn't appear in RFC 5280. Please exp= and it to subjectAltName which does appear.

=C2=A0 DNS-ID matching the "mx" pattern.=C2=A0 The MX's certi= ficate MAY also be
=C2=A0 checked for revocation via OCSP [RFC2560], certificate revocation =C2=A0 lists (CRLs), or some other mechanism.

Is there a reason this is a MAY rather than a SHOULD?

=C2=A0 New fields are added to this registry using IANA's "Expert = Review"
=C2=A0 policy.

Please add some guidance to the expert reviewer on the criteria that should= be met when registering new fields. You can leave the reviewer some wiggle= room, but having guidance sets expectations for the person registering the= new field, the expert reviewer and for any IESG appeal that might result f= rom a disagreement.

8.=C2=A0 Security Considerations

One more security consideration:

This mechanism causes an MTA (an automated system) to adopt the role of an = HTTPS client in a scenario where the HTTPS server may be hostile to operati= on of the MTA. A full HTTP stack is a large amount of code that may contain= coding errors that expose the MTA to new implementation vulnerabilities. T= his threat can be partially mitigated by using a hardened HTTPS client libr= ary that has been tested against a fuzzing HTTPS test server. This threat c= an also be partially mitigated by isolating the HTTPS code into a separate = process that does not have access to the normal MTA machinery and making su= re the MTA machinery gracefully handles a wedged HTTPS client. Sites that a= re evaluating the cost/benefit of this functionality may wish to compare th= e new attack surface of this mechanism with the new attack surface of alter= nate mechanisms such DANE [RFC7672].

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Chris

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

--001a114c929c9adbd40554c4485f-- --001a114c929ca0e0ae0554c44814 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 K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAYkrz1Cai+JaCm 4XHoRSA0trtPrUdomPgySj1qyZVeCTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA3MjAxODU0NTJaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAsGg8T4Ek7hqsSzGeDXNTA5lJLa5hb6VS oLn13Sbvn/0gZMFonJZzxXAWpsCDJg3jqzNt3DLHVX06zCqerdHWWkqCilMS0SgTy1sHI57fzDpp DFL8rtljbgamvSeSnIpkCeuxLZIDI82qMkPeR4Q1r4o0YzT8g1kqJYNyNhscAM8EjXCd+3ZFf/wz okYORl9Nko85J8LbVyp/ZbXHju2EoTUhRuRts/XGDkdGMq7uKbIroHkWwapzebSEyHTx2US5tguj kT2K2Rl7rj00LvXF2XGDO7wUThSdV5q3iYrda/6ddv/WDiqV52VEhE+klgLdAjlDAJBZUzg9II+r n6GPBg== --001a114c929ca0e0ae0554c44814-- From nobody Fri Jul 21 01:16: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 E77D5131748 for ; Fri, 21 Jul 2017 01:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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=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 JWX_ebMvrYg2 for ; Fri, 21 Jul 2017 01:16:30 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.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 6711512EC51 for ; Fri, 21 Jul 2017 01:16:30 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6L8GSmg029659 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 21 Jul 2017 08:16:28 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v6L8GRLT014081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 21 Jul 2017 08:16:28 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v6L8GRF5010253; Fri, 21 Jul 2017 08:16:27 GMT Received: from [10.175.206.68] (/10.175.206.68) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 Jul 2017 01:16:27 -0700 From: "Chris Newman" To: "Daniel Margolis" Cc: uta@ietf.org Date: Fri, 21 Jul 2017 10:16:23 +0200 Message-ID: In-Reply-To: References: <9A41D7B1-4D4C-4605-8161-7985E30B1044@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.6r5347) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [Uta] review of draft-ietf-uta-mta-sts-07 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, 21 Jul 2017 08:16:33 -0000 On 20 Jul 2017, at 20:54, Daniel Margolis wrote: > Hey, Chris, > > Thanks for the thorough review. A few inline comments off the cuff; = > others > we will have to address in the draft. > > On Thu, Jul 20, 2017 at 6:02 PM, Chris Newman = > > wrote: > >> Overall, I find the document hard to read and the structure = >> problematic. >> If I'm verifying STS policy, I want to know how to fetch the policy, = >> then I >> want to know what to fetch. The document structure is awkward for = >> that >> goal. And if I want to publish STS policy, I want to know where I = >> publish >> it and then what I need to publish. An editorial pass to reorganize = >> the >> document to be more useful and clear for an implementer would be = >> helpful. > > Do you have any suggestions of a restructuring? The current structure = > is > (of course) _intended_ to be natural, in that we start with how to = > discover > a policy (i.e., for senders, how to publish a policy), then how to = > validate > a policy (i.e., for senders, how to decide what should go in your = > policy), > then how to apply a policy (i.e. what the different "mode" options = > mean and > how they affect delivery). > > I'm not at all averse to changing it, but it would help us a bit to = > have > more specific suggestions, if you have any. I and the other authors > obviously intended this to be a natural flow, so we may not be in the = > best > position to see what is awkward about it. :) I can't work through more precise suggestions at the moment. >> There's also an overuse of "quotes" around terminology which is >> problematic in a document with JSON strings which need to be quoted = >> in the >> context of protocol examples. >> >> It'd be helpful to have an example workflow, possibly early in the >> document. Something like: > > I think Appendix 2 covers more or less this, but in pseudocode. Are = > you > suggesting that it would be better to have that be textual rather than > pseudocode, be in-document rather than an appendix, or both? Both. >> Example: >> recipient: user@example.com >> Determine policy domain [section reference], in this case = >> example.com >> Look up DNS TXT record in _mta-sts.example.com (_mta-sts TXT record = >> in >> policy domain). [section reference]. >> If failure or invalid record, stop. >> If valid cached policy record, skip forward to SMTP connection. >> Connect to https server at mta-sts.example.com (mta-sts host in = >> policy >> domain). [section reference] >> Verify HTTPS TLS certificate as matching domain mta-sts.example.com >> [section reference]. >> Fetch policy from /.well-known/mta-sts.json [section reference]. >> Connect to SMTP server according to SMTP standard. >> Perform STARTTLS >> Verify TLS negotiation and hostname matches STS policy [section >> reference]. >> >> transmission into authenticated, downgrade-resistent encrypted >>> tarnsmission. >>> >> >> Fix spelling: resistent->resistant, tarnsmission =3D> transmission >> >> sts-version =3D %x76 *WSP "=3D" *WSP %x53 %x54 ; "v=3DSTSv1"= >>> %x53 %x76 %x31 >>> >> >> I recommend you improve ABNF readability by referencing RFC 7405. >> >> std-version =3D %s"v=3DSTSv1" >> >> The policy itself is a JSON [RFC7159] object served via the HTTPS = >> GET >>> >> >> This reference needs to be changed to draft-ietf-jsonbis-rfc7159bis, = >> or >> you need to explicitly require use of UTF-8 charset, or reference = >> I-JSON >> (RFC 7493). With RFC 7159 there's a requirement to support and detect >> UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE charsets (and possibly other = >> Unicode >> encodings) that I find highly problematic for interoperability. >> >> 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 below), chain to a root CA that is trusted by = >>> the >>> >> >> After reading the document, I'm not sure I understand how to = >> construct the >> DNS FQDN that I need to pass to the TLS API in order to validate the >> mta-sts host. In the example workflow above, I made a guess. But the >> document presently never says how to construct the FQDN explicitly. >> >> The certificate MAY be checked for revocation via the Online >>> Certificate Status Protocol (OCSP) [RFC2560], certificate = >>> revocation >>> lists (CRLs), or some other mechanism. >>> >> >> Is there a reason this is a MAY rather than a SHOULD? >> > > Yes. The security value of OCSP is contentious (e.g. > https://www.imperialviolet.org/2014/04/19/revchecking.html) and = > support for > it in HTTPS client libs is (AFAICT) haphazard; e.g. > https://curl.haxx.se/libcurl/c/CURLOPT_SSL_VERIFYSTATUS.htmlhttps://sta= ckoverflow.com/questions/25803455/how-to-add-ocsp-support-into-python-req= uests-library. > Making OCSP a MUST seems to make implementation harder for = > questionable > gain. I never suggested MUST OCSP, I suggested SHOULD implement some mechanism = to check certificate revocation. From my perspective, it doesn't have to = be any mechanism in particular, but having no way to revoke certificates = is a problem. There have been real world cases where certificate = revocation was needed. It's possible software update mechanisms have = been more effective than other revocation mechanisms in practice, so = that may be sufficient to meet the recommendation. - Chris >> 3.4. Policy Selection for Smart Hosts and Subdomains >>> >> >> It's confusing to group two very different aspects of mail operations = >> into >> a single section. I'd suggest making this two sections. > > >> certificate MUST have a CN-ID ([RFC6125]) or SAN ([RFC5280]) with a >>> >> >> The abbreviation "SAN" doesn't appear in RFC 5280. Please expand it = >> to >> subjectAltName which does appear. >> >> DNS-ID matching the "mx" pattern. The MX's certificate MAY also be >>> checked for revocation via OCSP [RFC2560], certificate revocation >>> lists (CRLs), or some other mechanism. >>> >> >> Is there a reason this is a MAY rather than a SHOULD? >> >> New fields are added to this registry using IANA's "Expert Review" >>> policy. >>> >> >> Please add some guidance to the expert reviewer on the criteria that >> should be met when registering new fields. You can leave the reviewer = >> some >> wiggle room, but having guidance sets expectations for the person >> registering the new field, the expert reviewer and for any IESG = >> appeal that >> might result from a disagreement. >> >> 8. Security Considerations >>> >> >> One more security consideration: >> >> This mechanism causes an MTA (an automated system) to adopt the role = >> of an >> HTTPS client in a scenario where the HTTPS server may be hostile to >> operation of the MTA. A full HTTP stack is a large amount of code = >> that may >> contain coding errors that expose the MTA to new implementation >> vulnerabilities. This threat can be partially mitigated by using a = >> hardened >> HTTPS client library that has been tested against a fuzzing HTTPS = >> test >> server. This threat can also be partially mitigated by isolating the = >> HTTPS >> code into a separate process that does not have access to the normal = >> MTA >> machinery and making sure the MTA machinery gracefully handles a = >> wedged >> HTTPS client. Sites that are evaluating the cost/benefit of this >> functionality may wish to compare the new attack surface of this = >> mechanism >> with the new attack surface of alternate mechanisms such DANE = >> [RFC7672]. >> >> - Chris >> >> _______________________________________________ >> Uta mailing list >> Uta@ietf.org >> https://www.ietf.org/mailman/listinfo/uta >> From nobody Fri Jul 21 02:36: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 5BBB912EB2B for ; Fri, 21 Jul 2017 02:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 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, 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 K-ocKUzaQ8OA for ; Fri, 21 Jul 2017 02:36:36 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::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 4FCA6127869 for ; Fri, 21 Jul 2017 02:36:36 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id x6so3710737yba.2 for ; Fri, 21 Jul 2017 02:36: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=Hve0VmiEcRtfbQiN0xR2QxSMm/eq/5/lO40IXRSHk5g=; b=Gag5D6br+1DzVcR5IA6GUaemUIVTYawu0LlUCpJanNkpsSQaeUKaZPne8l6rYm9wTa psdYE8SnjVRa9mHt7RLdCpkPCrdtWfrfkVZ1j+71GkDS/aGqAF3EiL8t4VxnayafmFLX EKHRzTUjzdQ9o6XK9gNau5+s0b++jN1cbcFLSgzVcIU0bUHg1NYQxdCDvM5NcOl/44+z R/73ajbRJQg5hwI3fdjvX98Z3Lq6bid2n6P6elWDoFbCEn6dwH9Ckb4UTCAwp2q4gt+6 6Zmr9r41JelMKycUCBdqyenoOZKrx+wS/HSUtkMS8rqqo/+A8gUrDhneywc1VeS7+lci cbdw== 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=Hve0VmiEcRtfbQiN0xR2QxSMm/eq/5/lO40IXRSHk5g=; b=iO17f8O/QWXWfSKlyNwPTcinB1YXwkwK/0wN+kdyTA/ImSnbGfAJ0llzoTLKMW5oIU +NzsNIeMgCelpsuvZ4esrxeknDQwJRF1gBoHRGleo0i6pa/DsxgU36I/7zFsy2WdmLqE 4V2Iscm/sq1vvBr8377pilI4h3XLK2FtZxHzhHQBIPh7mJS+HjAkZavvd8JeDb0/cr6M JvFBVrbn6HJFhbWYsUa9utiFK5bW/TJ8+QuoNPqRg6mNhv9uEN9udU6IwbLpKsYNWvAZ pfNFHisQmeWqtYyIwJA/RPOsMktjB8yZUN2DQLqK9dXXcazHisYj4QaUqZUDv5Mi6gYe a85w== X-Gm-Message-State: AIVw112bauAUT+rrwEmhzn/UVCeRzByYsHdCLy4lGZiGF368lX2wVphN ix1KqWzkJ/qCaoeECTsAC3Ut/IbLzDzQ X-Received: by 10.37.57.208 with SMTP id g199mr1729539yba.53.1500629795362; Fri, 21 Jul 2017 02:36:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.80.144 with HTTP; Fri, 21 Jul 2017 02:36:34 -0700 (PDT) In-Reply-To: References: <9A41D7B1-4D4C-4605-8161-7985E30B1044@oracle.com> From: Daniel Margolis Date: Fri, 21 Jul 2017 11:36:34 +0200 Message-ID: To: Chris Newman Cc: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114f51c0ea89ab0554d0995d" Archived-At: Subject: Re: [Uta] review of draft-ietf-uta-mta-sts-07 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, 21 Jul 2017 09:36:39 -0000 --001a114f51c0ea89ab0554d0995d Content-Type: multipart/alternative; boundary="001a114f51c0e5031e0554d0998c" --001a114f51c0e5031e0554d0998c Content-Type: text/plain; charset="UTF-8" On Fri, Jul 21, 2017 at 10:16 AM, Chris Newman wrote: > On 20 Jul 2017, at 20:54, Daniel Margolis wrote: > >> Hey, Chris, >> >> Thanks for the thorough review. A few inline comments off the cuff; others >> we will have to address in the draft. >> >> On Thu, Jul 20, 2017 at 6:02 PM, Chris Newman >> wrote: >> >> Overall, I find the document hard to read and the structure problematic. >>> If I'm verifying STS policy, I want to know how to fetch the policy, >>> then I >>> want to know what to fetch. The document structure is awkward for that >>> goal. And if I want to publish STS policy, I want to know where I publish >>> it and then what I need to publish. An editorial pass to reorganize the >>> document to be more useful and clear for an implementer would be helpful. >>> >> >> Do you have any suggestions of a restructuring? The current structure is >> (of course) _intended_ to be natural, in that we start with how to >> discover >> a policy (i.e., for senders, how to publish a policy), then how to >> validate >> a policy (i.e., for senders, how to decide what should go in your policy), >> then how to apply a policy (i.e. what the different "mode" options mean >> and >> how they affect delivery). >> >> I'm not at all averse to changing it, but it would help us a bit to have >> more specific suggestions, if you have any. I and the other authors >> obviously intended this to be a natural flow, so we may not be in the best >> position to see what is awkward about it. :) >> > > I can't work through more precise suggestions at the moment. OK. I'll take another look at it with your suggestions in mind, but I'd also like feedback from you or others on the list. Since we're quite a few revisions in, I hesitate to make really large scale stylistic or editing changes without broader feedback on what they should be--that's a bit of trying to hit a target in the dark. > There's also an overuse of "quotes" around terminology which is >>> problematic in a document with JSON strings which need to be quoted in >>> the >>> context of protocol examples. >>> >>> It'd be helpful to have an example workflow, possibly early in the >>> document. Something like: >>> >> >> I think Appendix 2 covers more or less this, but in pseudocode. Are you >> suggesting that it would be better to have that be textual rather than >> pseudocode, be in-document rather than an appendix, or both? >> > > Both. > > Example: >>> recipient: user@example.com >>> Determine policy domain [section reference], in this case example.com >>> Look up DNS TXT record in _mta-sts.example.com (_mta-sts TXT record in >>> policy domain). [section reference]. >>> If failure or invalid record, stop. >>> If valid cached policy record, skip forward to SMTP connection. >>> Connect to https server at mta-sts.example.com (mta-sts host in policy >>> domain). [section reference] >>> Verify HTTPS TLS certificate as matching domain mta-sts.example.com >>> [section reference]. >>> Fetch policy from /.well-known/mta-sts.json [section reference]. >>> Connect to SMTP server according to SMTP standard. >>> Perform STARTTLS >>> Verify TLS negotiation and hostname matches STS policy [section >>> reference]. >>> >>> transmission into authenticated, downgrade-resistent encrypted >>> >>>> tarnsmission. >>>> >>>> >>> Fix spelling: resistent->resistant, tarnsmission => transmission >>> >>> sts-version = %x76 *WSP "=" *WSP %x53 %x54 ; "v=STSv1" >>> >>>> %x53 %x76 %x31 >>>> >>>> >>> I recommend you improve ABNF readability by referencing RFC 7405. >>> >>> std-version = %s"v=STSv1" >>> >>> The policy itself is a JSON [RFC7159] object served via the HTTPS GET >>> >>>> >>>> >>> This reference needs to be changed to draft-ietf-jsonbis-rfc7159bis, or >>> you need to explicitly require use of UTF-8 charset, or reference I-JSON >>> (RFC 7493). With RFC 7159 there's a requirement to support and detect >>> UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE charsets (and possibly other >>> Unicode >>> encodings) that I find highly problematic for interoperability. >>> >>> 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 below), chain to a root CA that is trusted by the >>>> >>>> >>> After reading the document, I'm not sure I understand how to construct >>> the >>> DNS FQDN that I need to pass to the TLS API in order to validate the >>> mta-sts host. In the example workflow above, I made a guess. But the >>> document presently never says how to construct the FQDN explicitly. >>> >>> The certificate MAY be checked for revocation via the Online >>> >>>> Certificate Status Protocol (OCSP) [RFC2560], certificate revocation >>>> lists (CRLs), or some other mechanism. >>>> >>>> >>> Is there a reason this is a MAY rather than a SHOULD? >>> >>> >> Yes. The security value of OCSP is contentious (e.g. >> https://www.imperialviolet.org/2014/04/19/revchecking.html) and support >> for >> it in HTTPS client libs is (AFAICT) haphazard; e.g. >> https://curl.haxx.se/libcurl/c/CURLOPT_SSL_VERIFYSTATUS.html >> https://stackoverflow.com/questions/25803455/how-to-add-ocsp >> -support-into-python-requests-library. >> Making OCSP a MUST seems to make implementation harder for questionable >> gain. >> > > I never suggested MUST OCSP, I suggested SHOULD implement some mechanism > to check certificate revocation. From my perspective, it doesn't have to be > any mechanism in particular, but having no way to revoke certificates is a > problem. There have been real world cases where certificate revocation was > needed. It's possible software update mechanisms have been more effective > than other revocation mechanisms in practice, so that may be sufficient to > meet the recommendation. I'm OK with a SHOULD for generic "revocation support," but this feels like it strays outside the scope of the spec (insofar as this isn't an issue specific to STS's use of HTTPS with web PKI). Maybe instead something to call out in Security Considerations? > > > - Chris > > > 3.4. Policy Selection for Smart Hosts and Subdomains >>> >>>> >>>> >>> It's confusing to group two very different aspects of mail operations >>> into >>> a single section. I'd suggest making this two sections. >>> >> >> >> certificate MUST have a CN-ID ([RFC6125]) or SAN ([RFC5280]) with a >>> >>>> >>>> >>> The abbreviation "SAN" doesn't appear in RFC 5280. Please expand it to >>> subjectAltName which does appear. >>> >>> DNS-ID matching the "mx" pattern. The MX's certificate MAY also be >>> >>>> checked for revocation via OCSP [RFC2560], certificate revocation >>>> lists (CRLs), or some other mechanism. >>>> >>>> >>> Is there a reason this is a MAY rather than a SHOULD? >>> >>> New fields are added to this registry using IANA's "Expert Review" >>> >>>> policy. >>>> >>>> >>> Please add some guidance to the expert reviewer on the criteria that >>> should be met when registering new fields. You can leave the reviewer >>> some >>> wiggle room, but having guidance sets expectations for the person >>> registering the new field, the expert reviewer and for any IESG appeal >>> that >>> might result from a disagreement. >>> >>> 8. Security Considerations >>> >>>> >>>> >>> One more security consideration: >>> >>> This mechanism causes an MTA (an automated system) to adopt the role of >>> an >>> HTTPS client in a scenario where the HTTPS server may be hostile to >>> operation of the MTA. A full HTTP stack is a large amount of code that >>> may >>> contain coding errors that expose the MTA to new implementation >>> vulnerabilities. This threat can be partially mitigated by using a >>> hardened >>> HTTPS client library that has been tested against a fuzzing HTTPS test >>> server. This threat can also be partially mitigated by isolating the >>> HTTPS >>> code into a separate process that does not have access to the normal MTA >>> machinery and making sure the MTA machinery gracefully handles a wedged >>> HTTPS client. Sites that are evaluating the cost/benefit of this >>> functionality may wish to compare the new attack surface of this >>> mechanism >>> with the new attack surface of alternate mechanisms such DANE [RFC7672]. >>> >>> - Chris >>> >>> _______________________________________________ >>> Uta mailing list >>> Uta@ietf.org >>> https://www.ietf.org/mailman/listinfo/uta >>> >>> > > --001a114f51c0e5031e0554d0998c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 21, 2017 at 10:16 AM, Chris Newman <chris.newman@ora= cle.com> wrote:
On 20 Jul 2017, at 20:54, Daniel Margolis wrote:
Hey, Chris,

Thanks for the thorough review. A few inline comments off the cuff; others<= br> we will have to address in the draft.

On Thu, Jul 20, 2017 at 6:02 PM, Chris Newman <chris.newman@oracle.com>
wrote:

Overall, I find the document hard to read and the structure problematic. If I'm verifying STS policy, I want to know how to fetch the policy, th= en I
want to know what to fetch. The document structure is awkward for that
goal. And if I want to publish STS policy, I want to know where I publish it and then what I need to publish. An editorial pass to reorganize the
document to be more useful and clear for an implementer would be helpful.

Do you have any suggestions of a restructuring? The current structure is (of course) _intended_ to be natural, in that we start with how to discover=
a policy (i.e., for senders, how to publish a policy), then how to validate=
a policy (i.e., for senders, how to decide what should go in your policy),<= br> then how to apply a policy (i.e. what the different "mode" option= s mean and
how they affect delivery).

I'm not at all averse to changing it, but it would help us a bit to hav= e
more specific suggestions, if you have any. I and the other authors
obviously intended this to be a natural flow, so we may not be in the best<= br> position to see what is awkward about it. :)

 I can't work through more precise suggestions at the moment.

OK. I'll take another look at it with your sugges= tions in mind, but I'd also like feedback from you or others on the lis= t. Since we're quite a few revisions in, I hesitate to make really larg= e scale stylistic or editing changes without broader feedback on what they = should be--that's a bit of trying to hit a target in the dark.=C2=A0
=C2=A0
There's also an overuse of "quotes" around terminology which = is
problematic in a document with JSON strings which need to be quoted in the<= br> context of protocol examples.

It'd be helpful to have an example workflow, possibly early in the
document. Something like:

I think Appendix 2 covers more or less this, but in pseudocode. Are you
suggesting that it would be better to have that be textual rather than
pseudocode, be in-document rather than an appendix, or both?

 Both.=C2=A0


Example:
=C2=A0recipient: user= @example.com
=C2=A0Determine policy domain [section reference], in this case example.com =C2=A0Look up DNS TXT record in _mta-sts.example.com (_mta-sts TXT rec= ord in
policy domain). [section reference].
=C2=A0If failure or invalid record, stop.
=C2=A0If valid cached policy record, skip forward to SMTP connection.
=C2=A0Connect to https server at mta-sts.example.com (mta-sts host in = policy
domain). [section reference]
=C2=A0Verify HTTPS TLS certificate as matching domain mta-sts.example.com<= /a>
[section reference].
=C2=A0Fetch policy from /.well-known/mta-sts.json [section reference].
=C2=A0Connect to SMTP server according to SMTP standard.
=C2=A0Perform STARTTLS
=C2=A0Verify TLS negotiation and hostname matches STS policy [section
reference].

transmission into authenticated, downgrade-resistent encrypted
tarnsmission.


Fix spelling: resistent->resistant, tarnsmission =3D> transmission
sts-version=C2=A0 =C2=A0 =C2=A0=3D %x76 *WSP "=3D" *WSP %x53 %x54= =C2=A0 =C2=A0 =C2=A0 =C2=A0; "v=3DSTSv1"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x53 %x76 %x= 31


I recommend you improve ABNF readability by referencing RFC 7405.

=C2=A0std-version=C2=A0 =C2=A0 =3D %s"v=3DSTSv1"

=C2=A0 The policy itself is a JSON [RFC7159] object served via the HTTPS GE= T


This reference needs to be changed to draft-ietf-jsonbis-rfc7159bis, or
you need to explicitly require use of UTF-8 charset, or reference I-JSON (RFC 7493). With RFC 7159 there's a requirement to support and detect UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE charsets (and possibly other Unicode=
encodings) that I find highly problematic for interoperability.

=C2=A0 When fetching a new policy or updating a policy, the HTTPS endpoint<= br>
=C2=A0 MUST present a X.509 certificate which is valid for the "mta-st= s"
=C2=A0 host (as described below), chain to a root CA that is trusted by the=


After reading the document, I'm not sure I understand how to construct = the
DNS FQDN that I need to pass to the TLS API in order to validate the
mta-sts host. In the example workflow above, I made a guess. But the
document presently never says how to construct the FQDN explicitly.

=C2=A0 The certificate MAY be checked for revocation via the Online
=C2=A0 Certificate Status Protocol (OCSP) [RFC2560], certificate revocation=
=C2=A0 lists (CRLs), or some other mechanism.


Is there a reason this is a MAY rather than a SHOULD?


Yes. The security value of OCSP is contentious (e.g.
https://www.imperialviolet.org/2014/= 04/19/revchecking.html) and support for
it in HTTPS client libs is (AFAICT) haphazard; e.g.
https://curl.haxx.= se/libcurl/c/CURLOPT_SSL_VERIFYSTATUS.htmlhttps://stackoverflow.c= om/questions/25803455/how-to-add-ocsp-support-into-python-request= s-library.
Making OCSP a MUST seems to make implementation harder for questionable
gain.

I never suggested MUST OCSP, I suggested SHOULD implement some mechanism to= check certificate revocation. From my perspective, it doesn't have to = be any mechanism in particular, but having no way to revoke certificates is= a problem. There have been real world cases where certificate revocation w= as needed. It's possible software update mechanisms have been more effe= ctive than other revocation mechanisms in practice, so that may be sufficie= nt to meet the recommendation.

I'm OK w= ith a SHOULD for generic "revocation support," but this feels lik= e it strays outside the scope of the spec (insofar as this isn't an iss= ue specific to STS's use of HTTPS with web PKI). Maybe instead somethin= g to call out in Security Considerations?
=C2=A0


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Chris


3.4.=C2=A0 Policy Selection for Smart Hosts and Subdomains


It's confusing to group two very different aspects of mail operations i= nto
a single section. I'd suggest making this two sections.


=C2=A0 certificate MUST have a CN-ID ([RFC6125]) or SAN ([RFC5280]) with a<= br>


The abbreviation "SAN" doesn't appear in RFC 5280. Please exp= and it to
subjectAltName which does appear.

=C2=A0 DNS-ID matching the "mx" pattern.=C2=A0 The MX's certi= ficate MAY also be
=C2=A0 checked for revocation via OCSP [RFC2560], certificate revocation =C2=A0 lists (CRLs), or some other mechanism.


Is there a reason this is a MAY rather than a SHOULD?

=C2=A0 New fields are added to this registry using IANA's "Expert = Review"
=C2=A0 policy.


Please add some guidance to the expert reviewer on the criteria that
should be met when registering new fields. You can leave the reviewer some<= br> wiggle room, but having guidance sets expectations for the person
registering the new field, the expert reviewer and for any IESG appeal that=
might result from a disagreement.

8.=C2=A0 Security Considerations


One more security consideration:

This mechanism causes an MTA (an automated system) to adopt the role of an<= br> HTTPS client in a scenario where the HTTPS server may be hostile to
operation of the MTA. A full HTTP stack is a large amount of code that may<= br> contain coding errors that expose the MTA to new implementation
vulnerabilities. This threat can be partially mitigated by using a hardened=
HTTPS client library that has been tested against a fuzzing HTTPS test
server. This threat can also be partially mitigated by isolating the HTTPS<= br> code into a separate process that does not have access to the normal MTA machinery and making sure the MTA machinery gracefully handles a wedged
HTTPS client. Sites that are evaluating the cost/benefit of this
functionality may wish to compare the new attack surface of this mechanism<= br> with the new attack surface of alternate mechanisms such DANE [RFC7672].
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Chris

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




--001a114f51c0e5031e0554d0998c-- --001a114f51c0ea89ab0554d0995d 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 K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBNyqggj56nddLO ksaAz6rAY5gVfV4HgdUY6NEyj3ArSDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA3MjEwOTM2MzVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAAOIbO7o3UFK7C7XbGahdTKfURrdp9M32 K8P+z0AsSQa5xM4dOsZpuXuARiPVSk1Wo4e8fy5egLgUO3KYKJUW8SZ9QCEHzSK3egd9RSW7A70g GhcNNhoy9g0GgQCb4FGqpuRb973zv5A//K/lxEdIA7pEgJjZsxL7ZM7lK4jZz4nLlHLZOcF6n6Xo H1NpLDSJz5TW4BrJXVy1qnFWHQV44EVKR0Y9cbUel1IIHMw8hVzkLNEDF5a82DRflHjbLtj8NiDy lJtrmlSnY1yIyPjFjzM9zyy3RaF2REsu/2LgiCIJzyVTBHFiUSw/uuLJyiopzmk3dAhEx/qS49Zu GLy73A== --001a114f51c0ea89ab0554d0995d-- From nobody Fri Jul 21 02:39:49 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1595129B40 for ; Fri, 21 Jul 2017 02:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mY_wz2_VD2iY for ; Fri, 21 Jul 2017 02:39:47 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A744C127869 for ; Fri, 21 Jul 2017 02:39:46 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id w126so8254946wme.0 for ; Fri, 21 Jul 2017 02:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=NgjQX2jFcw92iOwiruu7PGp05qDuLMFohMIkyVLKDvo=; b=JYOShttmRbkoKDSx31pHOStQSX7YF8ksXI6m70ooGqKt21yDoENzXHKJNw1EV2boGy M6hm0zDtYzLn3jobEqeE+cuX4cjl3BW11CPH6387WstpDzzW9egheVhV36Fep9foP6/S kzmuqqWR00czHUG9A7z0Z8OW0Ihmam21HajHxldxOA3Izg5sH5wOXxKF8bvH8LSqIkaj E/B9IwGH0GD8Tc4IqaMsCoBzdbvyqEeJCRYQCchKXkrgWvcw7lo6hMYzm2/610ysOYI/ YoKxy4j/yigm+EDqzq6OxXkq03y+PkKWq9UmjA9w6qcweoB25iQnHv9ahyTVgw2+poYS Irjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NgjQX2jFcw92iOwiruu7PGp05qDuLMFohMIkyVLKDvo=; b=I1fkfiwZLDE0oZhIlOlnUPvR/WxlGFZzAA6M5J18XYEyIQ/P54tqohzvfKTgH+Wzlk 0IoHOC/I1ZgdNLT+yYGukBgnKfFKheAE1bYuUqL0g8AqZ4iSglonCBk0MItN2DP97CFq RCwkL3yp63lLKGWsGSd1X2aY44yDy+9VDAn23e7jP97bo+5nStCy0z2bQY2ok9Zz7Ct9 gJ/BWtIHIneJcK96abaYXywEjbvS5aHXFE8xtnP+vSYZoQEi3WynwSX/cCvi0+XX7ZD4 qlLEOkaBr3M93+bqGs005gOs0lNpnevE+hkcM/FQu7rdPgKkR5vWBYzbXwaxqoWrUzgs mJew== X-Gm-Message-State: AIVw1135CdswQnN6v9h2lLSRxi+pxWfSNNXaAloGHxj4PCkaqZHdb7Xa nj4z1bUNtuZEtXOHmxRmjw== X-Received: by 10.28.157.205 with SMTP id g196mr4521489wme.84.1500629984997; Fri, 21 Jul 2017 02:39:44 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:9490:a0c5:8deb:dc85? ([2001:67c:370:128:9490:a0c5:8deb:dc85]) by smtp.gmail.com with ESMTPSA id 39sm569946wrv.23.2017.07.21.02.39.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 02:39:44 -0700 (PDT) To: uta@ietf.org References: <9A41D7B1-4D4C-4605-8161-7985E30B1044@oracle.com> From: Leif Johansson Message-ID: <4a9f81a1-a64b-7b3d-ffd3-8a347230e85c@mnt.se> Date: Fri, 21 Jul 2017 11:39:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] review of draft-ietf-uta-mta-sts-07 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, 21 Jul 2017 09:39:49 -0000 > > OK. I'll take another look at it with your suggestions in mind, but I'd > also like feedback from you or others on the list. Since we're quite a > few revisions in, I hesitate to make really large scale stylistic or > editing changes without broader feedback on what they should be--that's > a bit of trying to hit a target in the dark. > Thx Daniel. Lets see where we are after you've spun out the post-WGLC draft. At that point we really need more concrete text suggestions to be able to address reviewer issues. Cheers Leif From nobody Fri Jul 21 03:56: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 9F227127337 for ; Fri, 21 Jul 2017 03:56:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUnhCrgZ2D8g for ; Fri, 21 Jul 2017 03:56:26 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440F112EB2B for ; Fri, 21 Jul 2017 03:56:26 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id 33so24425516wrz.4 for ; Fri, 21 Jul 2017 03:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=aLU9njoZNfE8WgStn7CK0QEYKCSSK6zQJXf/I6Vbv0g=; b=PuO4aAurcnyU4fMaGS8qo7+6Rpw/8q/qebdrsoybmp93MSuAuiHvxAPl25C2xruVw3 fUR/i2pe/bUZ/2KjNsVZqTYNmc7ySzrr0nuVihctQ9YnqJ4IHTbC74bzAx6AJ3rSgPZB 0IoEPlwKZKpBWAKjegc79xJu8pnYBIJJuq7Hl/ir3kU9JTWugfMxzxXgGQoePvnw9Iun deSIKWnW9qvn7YN6Zeckfr/A+WYr9UG8YK5/a45oz9DJmGJtEaRwqLkN2Tkybm6tqL3o vFpMSH4n9wg5pBtAYna9TyFusx+iFxjC3hNvtmhLtmzZEjTRDDs+THzu6WSmvuffnpdb t2EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=aLU9njoZNfE8WgStn7CK0QEYKCSSK6zQJXf/I6Vbv0g=; b=YD1J+i08y6iZnDu6H1FtGr2lw4Tuu0BBTR8z5D29JBppFZ6LtGjKMmYOuDqAyW3ERw SWCO6uhGohcbb1NpctWbajyxzV2RJT77ZLT+NdyiHO2hVEXBbjxYyiglV2xP+iOgrryj hfuJJwZ5cFbBbGvILPdspPSK/gakvUv87TP0gADUJAmu93P5XtKfI6KeeglZd9QqHHm4 DRp44dcH8S48qcmvl6MLWammSAYRYUZTDGwl4pGj5tAyPDwNgUL2FItcTecWPYXRuUKY iz1TdovVUCVn9q1xdLgkn/7ZmvTG18dUrlyPDgGcSTRHTE/L5Mq04yaKsYXE+G66etpp gx+A== X-Gm-Message-State: AIVw111KXhvUAW4DgU9NedD6eWvx53uRA41q9XL3GSBpBBGtJAy/3GUZ LJWDVZ95wNgeywoe1FrPYw== X-Received: by 10.223.172.232 with SMTP id o95mr5450937wrc.276.1500634584630; Fri, 21 Jul 2017 03:56:24 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:9490:a0c5:8deb:dc85? ([2001:67c:1232:144:9490:a0c5:8deb:dc85]) by smtp.gmail.com with ESMTPSA id 143sm1096964wmg.9.2017.07.21.03.56.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 03:56:24 -0700 (PDT) From: Leif Johansson To: uta@ietf.org Message-ID: <06bffe72-9d6a-0225-2fcd-bb306396b682@sunet.se> Date: Fri, 21 Jul 2017 12:56:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Uta] adopt draft-fenton-smtp-require-tls-03 as WG document 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, 21 Jul 2017 10:56:28 -0000 There was clear consensus in Praha to adopt draft-fenton-smtp-require-tls-03 as a WG document (draft-ietf-uta-smtp-require-tls-00). If anyone objects to that, now is the time to speak up. Cheers Leif From nobody Fri Jul 21 04:10:43 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAC9129B7A for ; Fri, 21 Jul 2017 04:10:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Md1tWdc8upBQ for ; Fri, 21 Jul 2017 04:10:40 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 55290127337 for ; Fri, 21 Jul 2017 04:10:39 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id k71so27597250wrc.2 for ; Fri, 21 Jul 2017 04:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=5B5UYW3oAg/esgBYnAZneKwHFjAuWwcRNCg2/GH3suU=; b=LUl0C1USiR2+fKO2exm6zblJBuV+6jrbD3U1M1qKSmqPDbN6Zc3uv2s8QJx6i9Nx7h +me4Vo+TBBON3ZUDWKYU5zNKKSVYoNwqe+vlVusc0rueLey1Ic9sWchRisfNqi7uregH PnvnbNPDyhPQfdQ8H5rCRpziBa/y61jxZLv0K1eqwIyGXuL5jnv76obNEgBVE0LAtOEZ W8/yJy4jJV74lm0LwFn8IgP2LhlWHjyihkG9KQ+NMzR0v7OLbf5vZrgDyCkpowsdL3BX FzoN0ghtfSF01fIByzOHPVsUVeKQ+Sjga8CA3Liy2HMgykq9SJoqNykxJrxiNGTLQ95A QYbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=5B5UYW3oAg/esgBYnAZneKwHFjAuWwcRNCg2/GH3suU=; b=dqeuRIX2tIatckBtPZci2MAuGZDPofdaOgZH3yH8brN0XNmrcRF4emOKQ68M5kzsQS jDXL3rnQKO/g6f0nQGk30KFJXuNShcRt0h7h5OxWEx6r3Ioys4FdlRfHbx7fSuRwjRB+ SSpB7LmoZ8z3+r2ONW0F+OgYuJY6WuB7qq2uAcs/CBN+FXvYiXeaZu8rHH7aZqQwpZxC Alh7g+/xb5/hHI0H1/AkiZhUlHLsu2GgH8rQVypxiD3e1/dtmFHE0UAQcERsCGcY4+dk r52XWFtBmJkp8iQFFoCDSb+OG+SYnq/Khcq/7YacPe5Qg9N4c9DRr1DjbpdiQaKKWjag OVIQ== X-Gm-Message-State: AIVw1139WJDGdmBdIHzKleVsqU4T4+awqPKrqngv8d4TZhFY5Ijh7hEn Pc//2My7HzKkvQNavpuw4Q== X-Received: by 10.223.170.12 with SMTP id p12mr5948891wrd.238.1500635438247; Fri, 21 Jul 2017 04:10:38 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:9490:a0c5:8deb:dc85? ([2001:67c:1232:144:9490:a0c5:8deb:dc85]) by smtp.gmail.com with ESMTPSA id b80sm970664wmf.10.2017.07.21.04.10.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 04:10:37 -0700 (PDT) To: uta@ietf.org From: Leif Johansson Message-ID: Date: Fri, 21 Jul 2017 13:10:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Uta] consensus call on K/V vs JSON X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:10:42 -0000 We had a (less than spirited) discussion in Praha about the K/V vs JSON. There was no clear consensus for switching from JSON to K/V based on the proposal from the spec authors sent to the list last week. Victor expressed his views clearly and I'll not ask him to repeat himself. I will attempt to summarize the discussion - feel free to correct me! The situation is that of the active participants that are also implementors one (postfix - Victor) has said that he does not believe that postfix will ship with a standard JSON-based implementation but that this doesn't preclude third-party plugins. The other major implementor who is also an active participant (google) has stated that they have a JSON implementation but that they are also eager to close this issue. One more implementor (Chris) has stated no preference but also said that his (native) JSON parser is somewhat smaller than his K/V one. Based on this and falling back to the IETF WG process as chair I would conclude that there isn't enough consensus to make a change and that we are staying with JSON. I would prefer to have more opinions (implementors in particular) but we are also going to get past this. In particular I would like to hear from implementors who (like Victor) have a problem living with either choice. Please provide your feedback by EOB 1st of August. Cheers Leif From nobody Fri Jul 21 04:39:17 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 2C8DE13157A for ; Fri, 21 Jul 2017 04:39:15 -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, HTML_MESSAGE=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 WSNX_ng45yyV for ; Fri, 21 Jul 2017 04:39:12 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87AA212ECB7 for ; Fri, 21 Jul 2017 04:39:12 -0700 (PDT) Received: from [10.3.136.44] (unknown [90.229.20.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 28896263A2; Fri, 21 Jul 2017 07:35:37 -0400 (EDT) From: Tom Pusateri Message-Id: <74C79FFC-FA64-4226-ACA7-72A85E426B06@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_082AD025-44E4-4470-B6CB-4F83ED9F815E" Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3439\)) Date: Fri, 21 Jul 2017 13:39:08 +0200 In-Reply-To: Cc: uta@ietf.org To: Leif Johansson References: X-Mailer: Apple Mail (2.3439) Archived-At: Subject: Re: [Uta] consensus call on K/V vs JSON X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:39:15 -0000 --Apple-Mail=_082AD025-44E4-4470-B6CB-4F83ED9F815E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 21, 2017, at 1:10 PM, Leif Johansson wrote: >=20 >=20 > We had a (less than spirited) discussion in Praha about the K/V vs = JSON. >=20 > The situation is that of the active participants that are also > implementors one (postfix - Victor) has said that he does not believe > that postfix will ship with a standard JSON-based implementation but > that this doesn't preclude third-party plugins. >=20 > The other major implementor who is also an active participant (google) > has stated that they have a JSON implementation but that they are > also eager to close this issue. One more implementor (Chris) has = stated > no preference but also said that his (native) JSON parser is somewhat > smaller than his K/V one. >=20 > Based on this and falling back to the IETF WG process as chair I would > conclude that there isn't enough consensus to make a change and that > we are staying with JSON. >=20 > I would prefer to have more opinions (implementors in particular) but > we are also going to get past this. In particular I would like to hear > from implementors who (like Victor) have a problem living with either > choice. I don=E2=80=99t have an opinion on the two choices but in the past when = I=E2=80=99ve needed to do JSON work in =E2=80=9CC=E2=80=99, I=E2=80=99ve = used this library which made it very painless. https://github.com/DaveGamble/cJSON = The license is very permissive (MIT) and the author even suggests just = including two files cJSON.[ch] directly in your project if you wish. Tom --Apple-Mail=_082AD025-44E4-4470-B6CB-4F83ED9F815E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Jul 21, 2017, at 1:10 PM, Leif Johansson <leifj@sunet.se> = wrote:


We had a (less than spirited) discussion in = Praha about the K/V vs JSON.

The situation = is that of the active participants that are also
implementors one (postfix - Victor) has said that he does not = believe
that postfix will ship with a standard JSON-based = implementation but
that this doesn't preclude third-party = plugins.

The other major implementor who is = also an active participant (google)
has stated that they = have a JSON implementation but that they are
also eager to = close this issue. One more implementor (Chris) has stated
no= preference but also said that his (native) JSON parser is somewhat
smaller than his K/V one.

Based = on this and falling back to the IETF WG process as chair I would
conclude that there isn't enough consensus to make a change = and that
we are staying with JSON.

I would prefer to have more opinions (implementors in = particular) but
we are also going to get past this. In = particular I would like to hear
from implementors who = (like Victor) have a problem living with either
choice.

I don=E2=80=99= t have an opinion on the two choices but in the past when I=E2=80=99ve = needed to do JSON work in =E2=80=9CC=E2=80=99, I=E2=80=99ve used this = library which made it very painless.


The license is very permissive (MIT) and the = author even suggests just including two files cJSON.[ch] directly in = your project if you wish.

Tom

= --Apple-Mail=_082AD025-44E4-4470-B6CB-4F83ED9F815E-- From nobody Fri Jul 21 04:50:51 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C997131B69 for ; Fri, 21 Jul 2017 04:50:48 -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 qOrqwgZ9yjIt for ; Fri, 21 Jul 2017 04:50:47 -0700 (PDT) Received: from zardoc.esmtp.org (zardoc.esmtp.org [75.101.48.117]) (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 3B334131AD7 for ; Fri, 21 Jul 2017 04:50:47 -0700 (PDT) Received: from x2.esmtp.org (localhost. [127.0.0.1]) by zardoc.esmtp.org (MeTA1-1.1.Alpha8.0) with ESMTPS (TLS=TLSv1.2, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256, verify=OK) id S000000000029D0BC00; Fri, 21 Jul 2017 04:50:46 -0700 Received: (from ca@localhost) by x2.esmtp.org (8.14.6/8.12.10.Beta0/Submit) id v6LBokwQ031061 for uta@ietf.org; Fri, 21 Jul 2017 04:50:46 -0700 (PDT) Date: Fri, 21 Jul 2017 04:50:46 -0700 From: Claus Assmann To: uta@ietf.org Message-ID: <20170721115046.GA23878@x2.esmtp.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.5.24+24 (4de4b3635140) (2015-08-30) Archived-At: Subject: Re: [Uta] consensus call on K/V vs JSON X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:50:48 -0000 On Fri, Jul 21, 2017, Leif Johansson wrote: > I would prefer to have more opinions (implementors in particular) but There's no way I would add JSON support to sendmail. From nobody Fri Jul 21 04:59: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 46EB1131BB0 for ; Fri, 21 Jul 2017 04:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBgIcYZwU0dL for ; Fri, 21 Jul 2017 04:59:03 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 95398131B6A for ; Fri, 21 Jul 2017 04:59:02 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id e131so12058515wme.0 for ; Fri, 21 Jul 2017 04:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=KPnfko5G7v7D+ErzY4vD9UBC0EI9LxVNOdDFMCGgurM=; b=Wx87irxoBdjtgANv8TxgLhkT0VtnhaYMkalYjqbGckZgV8gbZTwsycDLIaZtgIXU/C sAzC7Mz6/LSp6wby4JlH0v5Ou0JxtoIWfbUGoKq+CL9LhvUwV76hoy/DXYcGFYWwep3W 1e7ob/SlKDN9z+8uSNpc3SY0xbIxcwAAD/jxqLsW5qy6dWvYBM1ouMS1LWunk8zb6P1a cKu7BvPxeeeD7YDzVkANM8cxCNfC+I6ZzbgrigRg8SZiMgX1jTJv0rsgejY2oNm09AHp 7K69lXqc3abjclFlus297JNyTYhSesPAGqhJqJ+YMvmL93eAK7y4+JH7oh+In1St26p1 0U8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KPnfko5G7v7D+ErzY4vD9UBC0EI9LxVNOdDFMCGgurM=; b=HhNRkeSW0KhKVCdWQQ+F0teCPZY9qKEly3Cd5aFjQSd0PW9Hq2ngWpoluOW9J/vdMS v3wHrfoEGQkByZGssIOZs92suWeF1p2p8b69x+6O3edJ1A/7to6NMBf35MMf/hi3+ZID ELWh7XLyTqa3Za/e1dPnzcSHNs07LIJupiiKQW3IFgPYdnZIpwUcW8Nwb3m2Fp/IokUl l7Q7OZ6WD+ylWrNGwJkXNcWv2V7eBfF4HwkBhvUz8jWoLakvcT1AurlGN9zsPZvuMauu 7+vgV7oRTfP+fVzark8x6YLYP3J3IHnZASF5f2we+DTNc7LbUnwXhlED4G+FW6ypYa1X PBig== X-Gm-Message-State: AIVw112AdB9RzYrN2+8kYgb1Yz+84gIXkcE7cG3/21bnew4L1L2YVdPl kJQHb84W+f6g63tTZCSoZg== X-Received: by 10.28.64.69 with SMTP id n66mr4407904wma.140.1500638341080; Fri, 21 Jul 2017 04:59:01 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:9490:a0c5:8deb:dc85? ([2001:67c:1232:144:9490:a0c5:8deb:dc85]) by smtp.gmail.com with ESMTPSA id d20sm6452085wrc.96.2017.07.21.04.59.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 04:59:00 -0700 (PDT) To: uta@ietf.org References: <20170721115046.GA23878@x2.esmtp.org> From: Leif Johansson Message-ID: <412136b9-2c02-a253-efad-017cd5a8b640@sunet.se> Date: Fri, 21 Jul 2017 13:58:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170721115046.GA23878@x2.esmtp.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] consensus call on K/V vs JSON X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:59:05 -0000 On 2017-07-21 13:50, Claus Assmann wrote: > On Fri, Jul 21, 2017, Leif Johansson wrote: > >> I would prefer to have more opinions (implementors in particular) but > > There's no way I would add JSON support to sendmail. Does that also mean you are ok with the current K/V proposal? From nobody Fri Jul 21 04:59:59 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 109B2131B6A for ; Fri, 21 Jul 2017 04:59:58 -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 0iqnFQ5oUH_y for ; Fri, 21 Jul 2017 04:59:56 -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 69013131A87 for ; Fri, 21 Jul 2017 04:59:56 -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.110) id 1dYWb4-0004Lh-Gz for uta@ietf.org (return-path ); Fri, 21 Jul 2017 11:59:54 +0000 To: uta@ietf.org References: From: Jeremy Harris Message-ID: Date: Fri, 21 Jul 2017 12:59:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [Uta] consensus call on K/V vs JSON X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:59:58 -0000 On 21/07/17 12:10, Leif Johansson wrote: > I would prefer to have more opinions (implementors in particular) but There's no way I would add JSON support to exim. -- Jeremy From nobody Fri Jul 21 07:49:57 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 359F9131E33 for ; Fri, 21 Jul 2017 07:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=desh-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtEa3ggqmWRW for ; Fri, 21 Jul 2017 07:49:55 -0700 (PDT) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (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 C1D26131B27 for ; Fri, 21 Jul 2017 07:49:54 -0700 (PDT) Received: by mail-lf0-x242.google.com with SMTP id b127so1322315lfb.2 for ; Fri, 21 Jul 2017 07:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=desh-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GExGexRsh0TKUVUEHsTCz9IKi5/PcEkgApe1BTeijsI=; b=fzrt3HFH7FwkMNIjwOZLkr9PGgzZ9QUmAyumWgDoGtwPnk4KfsXoC3hvUQfBxauVHj kQW5kzKFKHheZ0aD1cHXCPfz3SWyr+xwynkwY+E3NGDeGORYzYhsQW2I+DxxlLM7OP4o zc3+6WV/7Dis2repthbrcR6B/ObKrpPDUpOf+UGQP9r7IknDBYjqYQLcXvt9Mu7p8HYr b9ry9mAQ1F/GIBmi9RWk+jHPKsxZO8iApHOTP1mzaw+7OIB5PMbSxSLUApHhhdAWGjgF wAINkcFrA3ZcLdXpL5d5O1F7ijJCc5C/KXYwmzA5UfNBCWtLuqW2Mt1AQpEZz6HP2rlk qZ1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GExGexRsh0TKUVUEHsTCz9IKi5/PcEkgApe1BTeijsI=; b=NCroqPGEFC9cZfVLwPno7TP6zj6bB7nqOgzc9U3uxdw8TJjh5zxOkSov841l19MMLg vLxo6tGYL5AeAO+QyKhuhKCcJrdpopZ6E+3SnuUsbGFvZBq4rQz/CRiViaBTV3+BlMMx 3yLmC391iEpKbuL5XmgG+dPYRVq8JVqXwvmJfzgpsMvXXG9pa7VAtCtXa7iJLcTFGzsP fdumxrP4DSd2FWDu6njPFbBsxupIGeNOOuEfBBq4c1lHCrO2N/8/tqmFvjuAuKKImsmG lfnJITtSb5c0nO2CbtY1VqffaC/yRV5+zfMjoizwRToaiGa4iqCGcExVN7VrkWIRd6dq Q7lA== X-Gm-Message-State: AIVw111LeJFgYqXimQLM7R0yzqb8wTuTD1C76LcfdjfNro2/vFqmHLAX Cs7BHWxxa4UACbT8OYMi3g== X-Received: by 10.25.215.104 with SMTP id o101mr1053906lfg.24.1500648593042; Fri, 21 Jul 2017 07:49:53 -0700 (PDT) Received: from [10.2.50.33] ([212.85.68.184]) by smtp.gmail.com with ESMTPSA id w3sm943440ljd.35.2017.07.21.07.49.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 07:49:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Anders Berggren In-Reply-To: Date: Fri, 21 Jul 2017 16:49:50 +0200 Cc: uta@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <616C2C8A-D333-45A4-92A4-FAC9047CE7D1@desh.se> References: To: Leif Johansson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] consensus call on K/V vs JSON X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 14:49:56 -0000 > On 21 Jul 2017, at 13:10, Leif Johansson wrote: > ... > I would prefer to have more opinions (implementors in particular) but > we are also going to get past this. In particular I would like to hear > from implementors who (like Victor) have a problem living with either > choice. >=20 > Please provide your feedback by EOB 1st of August. Although we (an MTA with a draft STS implementation) would prefer JSON = (because it's an established web format), we don't have a problem with = switching to the proposed K/V format.=20= From nobody Fri Jul 21 08:19: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 07929131B04 for ; Fri, 21 Jul 2017 08:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xgr_9HcLjps8 for ; Fri, 21 Jul 2017 08:19:29 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B186B129B10 for ; Fri, 21 Jul 2017 08:19:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 300187A3309; Fri, 21 Jul 2017 15:19:28 +0000 (UTC) Date: Fri, 21 Jul 2017 15:19:27 +0000 From: Viktor Dukhovni To: uta@ietf.org Message-ID: <20170721151927.GZ8146@mournblade.imrryr.org> Reply-To: uta@ietf.org References: <9A41D7B1-4D4C-4605-8161-7985E30B1044@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A41D7B1-4D4C-4605-8161-7985E30B1044@oracle.com> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Uta] review of draft-ietf-uta-mta-sts-07 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, 21 Jul 2017 15:19:31 -0000 On Thu, Jul 20, 2017 at 06:02:00PM +0200, Chris Newman wrote: > It'd be helpful to have an example workflow, possibly early in the document. > Something like: > > Example: > recipient: user@example.com > Determine policy domain [section reference], in this case example.com > Look up DNS TXT record in _mta-sts.example.com (_mta-sts TXT record in > policy domain). [section reference]. > If failure or invalid record, stop. This introduces a downgrade attack on already cached data. The TXT record alone cannot suppress already cached policy. > If valid cached policy record, skip forward to SMTP connection. Any cached data is used unless a TXT record indicates a different policy id than the one cached. In which case an attempt is made (perhaps in the background) to obtain a fresh policy. > Connect to https server at mta-sts.example.com (mta-sts host in policy > domain). [section reference] > ... This sort of thing was supposed to be covered in the state machine description at the end... > This reference needs to be changed to draft-ietf-jsonbis-rfc7159bis, or you > need to explicitly require use of UTF-8 charset, or reference I-JSON (RFC > 7493). With RFC 7159 there's a requirement to support and detect UTF-16LE, > UTF-16BE, UTF-32LE, UTF-32BE charsets (and possibly other Unicode encodings) > that I find highly problematic for interoperability. No non-ascii data is presently anticipated, but for future proofing the encoding should be assumed UTF-8. > > 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 below), chain to a root CA that is trusted by the > > After reading the document, I'm not sure I understand how to construct the > DNS FQDN that I need to pass to the TLS API in order to validate the mta-sts > host. In the example workflow above, I made a guess. But the document > presently never says how to construct the FQDN explicitly. There is no single FQDN. The certificate is matched against any of the names in the "mx" attribute. The SNI should be taken from the MX hostname. > > The certificate MAY be checked for revocation via the Online > > Certificate Status Protocol (OCSP) [RFC2560], certificate revocation > > lists (CRLs), or some other mechanism. > > Is there a reason this is a MAY rather than a SHOULD? Postfix will not implement either CRL checks (reliably maintained CRLs are an exotic beast) or OCSP. We could implement support for stapled OCSP, but I am not aware of much support for that on the server side. > The abbreviation "SAN" doesn't appear in RFC 5280. Please expand it to > subjectAltName which does appear. I prefer "subject alternative name (SAN)" and then "SAN" thereafter. A "terminology" section entry may be appropriate. > > DNS-ID matching the "mx" pattern. The MX's certificate MAY also be > > checked for revocation via OCSP [RFC2560], certificate revocation > > lists (CRLs), or some other mechanism. > > Is there a reason this is a MAY rather than a SHOULD? See above. -- Viktor. From nobody Fri Jul 21 09:40:09 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 1C52E131C28 for ; Fri, 21 Jul 2017 09:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-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=btconnect.onmicrosoft.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 ShcGg1s_FdRZ for ; Fri, 21 Jul 2017 09:40:05 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0135.outbound.protection.outlook.com [104.47.1.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21878131B37 for ; Fri, 21 Jul 2017 09:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NpzJSb2so5q3U79YyPDYUPANFocBVkTVqsFVq/Aqga0=; b=ZDaIlVVlFlGwdTIl3sp6m4cBl4t6n1uzM3zWshUTSlTSGfXNHqLK3jk/haIedbcm1uaT1HssKiIj2DZG8QvcvhdRWXClgMaNx8wRB+iaBGhEPjB+kuVZNoNivcX2N4rWOqnnGawGcdtWMJAY39b1+A09mwQt9pbLGhL5foaGwfk= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; Received: from pc6 (86.149.101.4) by DB5PR07MB1557.eurprd07.prod.outlook.com (2a01:111:e400:5bc7::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Fri, 21 Jul 2017 16:40:01 +0000 Message-ID: <013201d3023f$69713b60$4001a8c0@gateway.2wire.net> From: "tom p." To: , "Leif Johansson" References: Date: Fri, 21 Jul 2017 17:34:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.149.101.4] X-ClientProxiedBy: VI1PR08CA0143.eurprd08.prod.outlook.com (2603:10a6:800:d5::21) To DB5PR07MB1557.eurprd07.prod.outlook.com (2a01:111:e400:5bc7::7) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a881e44f-d115-4311-aa33-08d4d0572258 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB5PR07MB1557; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1557; 3:IHVJarqxxZTSQXtDH5oQSfNSTUcJTDryixerLVUM0UzLOuD9X61V6gLoldkXB0TwHiwktHufCG5C02NDqFyZqe9xTcV3/vCG8Am9BaA6ewpOe0pHh0JmAyJaiaagF5PMEnnRHu5pdksNTtzLm9fUr4cSMAhAForGXrU+vbVvJWY5vRLYjAQY7TqMoK8rxHMdzt1rRfr63G8ayY+revUnD8ln1l/P/xoDcE/KvNhnlq5Y+gUDPgJqVQ6BSyaxEGwebqGVTPWmY33zSHvYKoiqjoBU4nyxNgRa1ZiKqu3jcjSQZPtvdvW8cTExEcvrEnv9/46xMSCDNONLEKSbmny+D2P5BfToYj68CuYhulQWKWMdnI37wJlnqXeSGGsAWwVD/956muQmV0BUPJZn8xdGK3cNXj97IpovV6m78JG9ZQcHDkxJgxeSDyHYFIh7d668P1oF0N65z4h3s0pCyPSNN0xoecu1JNWllKVfVZUJXDFIMI396YuewJwbIBZ/oJYKRQRirNsQWeq9bEJJsVnfgCCJWRRCpu26A5XgUD0+fwtj51Jt3EQit2MCm+uWbJJixkTvXqvxiidPTD8CumGykflna108Se87vqi2+KR+hwL8Nx883dB1cj4on3aGswFeMX4OGAt3yyX6PF3MQZ9E+gW6dYSEL5OUyQIQ25HoIO5VZuirAEVkorBMlZ3oscAPnXdRF5YpSC2UNyRak4R2D+hHBhGATZFC4l759IagV5A= X-MS-TrafficTypeDiagnostic: DB5PR07MB1557: X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1557; 25:KTGT4VYtEfQIXOOqhVFrRquEvzbqcoQiEVhsUTjCjx5ZY1f1J4bru2PAB00BmMP9miBwrLpjtQ7rLTIGN/AlrIEI4J0y2CEqy9Yxh4vWrsMSlD2YA4yXTOtQvwD5uDPvflZQQk+1FLoohXzjptfatm+yMW7XK/nnKeRv0cAW9HQE4fdPDtPz49dv3IOs1Dcq1qK8QlxLOjE/9Wip4sKb4BWOi9X6tPjq6QLxDksyoi5VPpWaCWOPP7o7zEfLBKnKW/7z7GBQJOvOjBjI+0IrkjHjSwzRYMPi1dWIQPjNhxbjszetPmQB9wKkzYe09KdMKPX/KTi6vVEmUds2IgrSUY/bcoZK6BiCAOyzq6gy/cURf5nM0ApYV0vKn+8E5yUPzwZNHlK90y1VYhxT991eC0dnkyZy+L/3zBsu9KQ9+x2oBT3APB1mi4CHY24gaHwph8JYDm+MdvtKcDcssv+dT2VDXvOZrBrP3GqoUS/WB9zhn0kq1/z1doROExQA+kIQnCHj7gCS+8ya4s4GnRyvoYV5Ljbt/FI0Ht/Cxi8Dq4xTO5mkP5g37c2+scJRmv6ZQ6d5PFk402lOw5d8WwXjKCnV9JiCoEHq1o7LsyHVKrJhCkCOaM/CS6TLSq+g+GAmdysDWrDSRYVQMsiJirv4SEEvgg/jYFpgrTAuc+/96nTjKPCI0Vu3uf8qmZJBn5l266AD01Zql7UQhoVqWEdo94IeApCYTEpkefzZDTbB+L4jSpvKfF+N3i1/0Qijf0YoYEBN0Fud2R6fdCA6rmnJPRjcFK8TzHMGpIhSrYnm2F9HjTpILY3kCsqsvW0gtisyNAT1Yj9O2GPMMmvZ3AzG0JuClWKr7FsEQ01SOBp5YJarebwXBjXV1B8DP6aD5fD1+1tFxZQNkPOvWM1UEVlkrEJp4Jw5BaL2J5kkmNCnsXM= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1557; 31:pn1QFYnGP0ANMXIGOATwo1JgOMPpz16mz34Fc/QDeQkT6PagwegMXF8HnP2Zd2qj3n2aDLIIE5sTkfNIF25rVTmCjXcFp4+M4CPrYMJCf83A27U4SZYNgwaQpC1yajgtFZqPb/+xGmYNTaeV3m3A35BP46/1LbhViLDXzHRr2X64XibNxsTc3VYyWCsDLM6dadk/59Q/vUsk3EMW4pIlJNJ6YIozM8RgHTPDeXcT0MFf/nYnEXJUTC0mi8CXjgvgwPdB+p6NyP/W8Nc1WExihJPQzEcIU6yMPr7WHa2oIXodfN4dxJiEbK4T05XuKxCDCYsD8DYMNAECZRNIDje5oWPVjPSXjeLHPwKup/ZxIOMslxSgGlImkSAMLWHiXhIKrKPoUeyPWrErSOnAva7RLq8EO9NGMWfiUGm892Xym3bjpV9Y83ipkux36QcJTxFSLc1NrDPenB+wjR7JIFVD5whcQmDt3sbr3EnR621RMn4UxdJEIZz4UeIPoQnpRgn/u44QRjtaEsCiFX23TB0RlNehxDAuthneGxMiW5R45wbVvGNrt6a2GzJqwypPAI/Zhsw9b7LS1L4p/Ov8pjTFpG88bbmGAkMgeuFb2aeIFgfq8Qa6qiE+MrR44o3vCtBMunP5m2O8XiuYZ9fagnVJMNDBu9e25IIlk1dww76HtLo0WEbnxwdBpFXjuthX5Jc8foCSPj3hjIfC/lN02h/5AA== X-Exchange-Antispam-Report-Test: UriScan:(100405760836317)(69029272430364); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB1557; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB1557; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB5PR07MB1557; 4:b3KwXPyf7CieFkGGlpE7IOBiQVsTmhw0bbv/KI9a?= =?iso-8859-1?Q?KNUYx1NBD+LXyWoRZaWLG7/iS1iwg4rzAzeM52vD1xTTm1xizeEVaDuyra?= =?iso-8859-1?Q?KMACfqkgF2mMACcBcchsp454n31g5iWOzyA+jANjd86mhbQ5Paeej4DwgD?= =?iso-8859-1?Q?PB4GMLD5MaQCc4eTxQUfBCPz5BH2RKpCMkIF90uRSu7noUwNdMjB+od/HP?= =?iso-8859-1?Q?cUe7TbeKsXEZ0I/6XaxUBWX3m2+k/9hRLGWaDzCUuFLsuWYh2lr6Mvmvpk?= =?iso-8859-1?Q?3UUYWTRPfQqpE7Tl/m0OIeEUTypDid99EtE99k9EE1WNpdS/amGu+OD9ds?= =?iso-8859-1?Q?9yPPXBvzAM+ipei2CUKazCopmpvKgWBBGWz9xd4ESzzyLbOlYTwtpHsosb?= =?iso-8859-1?Q?+l262hsC+8kEb9zUlr4T8jNOD/6UfL5PR2VN5rVSdheB+NFBZWCqK2pr7H?= =?iso-8859-1?Q?oLJ3aqNKMVUWTi+aPckUMFivDQpzivM7Vq2HbXtJ78MpZXNO3yUXKzmX/h?= =?iso-8859-1?Q?xOIUYavDXZTIffI0VuKeQDylYwn4i17BAZ8TULKBjIDqIW+5Ykld0S6Fua?= =?iso-8859-1?Q?4sJ4KuPtlBftTunLtxm/6vYMvsfLLIcAjQs+i1zmb/sB8F1FtfcRMkX/EN?= =?iso-8859-1?Q?dM7szn3Spwj0W2ET2zJ8Db4BjJTAf6t6ruoVa7jo32dv5PUN9DQvgccwPB?= =?iso-8859-1?Q?m9icjNkSqTBIUEkJMWszyYyoe6NJ46eVxBhBmdk/Brz/F+xTN3ErMLFkYa?= =?iso-8859-1?Q?OVVXm3jWjfN9K7uN1sfZ99ISU52ta7Jea6+q4I0RpY1Hi290Fsryv7zP8b?= =?iso-8859-1?Q?+1VzFlTo5LWGbyddoECgOxMWPbxg2oBukBAUObDju3PtYCvrdpoxzFJqyn?= =?iso-8859-1?Q?zAZgQeLOaS5JayB0KLi2rerpoIlGmjDCcpGVfgPk5Qd4Wl2J7sfJRePHWj?= =?iso-8859-1?Q?LcmV2YLCotDUQM7DGNwnvz5BVXvCl9HMdlmSsOHsA2O6EJqOzGxF4/fhco?= =?iso-8859-1?Q?L2cw2LaQa3IBSXqgY8snqcoQsSoW18cIde+4SMz9VlGOno/sTQCSy0w69p?= =?iso-8859-1?Q?+wk7R7zDM/Q5+vQSoEJbb6iaMPwxiiPWKVSh8QPDTYlRow4+LVHCcbAv+T?= =?iso-8859-1?Q?ZSauLpcoyGRKS7oTr4DWXFNvNMp/AvDzq86UXX8JJNpDFWAU5ZMtub45nt?= =?iso-8859-1?Q?ekjUeNWmRJNGi3oRJsKz78dQgStpH9+rW/ukWoxsJsYrWrbY2izvY7foK/?= =?iso-8859-1?Q?MEcz2zz2ll2kimlyuDFuaqrHvY0/PVIwmOW8Uw=3D=3D?= X-Forefront-PRVS: 0375972289 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6009001)(39860400002)(39850400002)(39450400003)(39840400002)(39400400002)(39410400002)(189002)(377454003)(199003)(13464003)(50226002)(33646002)(61296003)(189998001)(105586002)(106356001)(5660300001)(81816999)(76176999)(97736004)(81686999)(50986999)(6666003)(44716002)(62236002)(561944003)(305945005)(101416001)(42186005)(478600001)(230700001)(66066001)(47776003)(44736005)(7736002)(4720700003)(6486002)(81156014)(81166006)(8676002)(25786009)(229853002)(1556002)(1456003)(53936002)(7350300001)(116806002)(84392002)(86362001)(68736007)(23756003)(50466002)(6246003)(38730400002)(14496001)(9686003)(6496005)(966005)(6116002)(3846002)(2906002)(6306002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1557; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB5PR07MB1557; 23:PynTq/SwYTRHH5NWbcH+oqt92A2eKrRwL2IF0S5?= =?iso-8859-1?Q?Wf5ExWYnPOaHCq5EHDA64MgYMD2FSBZuxZ3/Qxsn4q1RnI6fGMqXme9rS6?= =?iso-8859-1?Q?BVuQDvQER/DGZNfqosOWrY9ES+b4G3ki/AkJe0W3IvaP7BjEJUjuY6Y4XP?= =?iso-8859-1?Q?TnLcRnz83XTzSJ6S9RgtcTRiB5SJK7CIeqm2Z1fsBxpLf5L/QO7lmsyyo3?= =?iso-8859-1?Q?fCcfd+QPYHqlK5wFPJYaH01p/RJnzvflDjz1VlKoLyQKA/Tyagg3zfURPe?= =?iso-8859-1?Q?Y9sw4RpzrVA8petFx37sU1PG8krEwAc7q5B2i4A4lCiPaMLdH4JUMg8k0F?= =?iso-8859-1?Q?tA9WPn+o94pGRQnFhLCSip7c2wqF4c1GSZrOeL0vnrdwCg8gB5r6BohGKL?= =?iso-8859-1?Q?f/YgiLUFuq2br5Fl0Q2T7tYzuyO5d/kGnT54N9JBk06Zn5wt6YH1pvyz/K?= =?iso-8859-1?Q?wQOkG2iQcYzVM5tn/Y52JEQfyx7x6YO5wSisEavzlEZ4UE1Ty9Dd19F9Lh?= =?iso-8859-1?Q?P1bSRmZSQpP0VohCBykwm8UdAfcwAR6iCNB08yyUJKxTaQx+2H2AGL2AT6?= =?iso-8859-1?Q?Pz+6TUM169YHO63Q0J7Zeg6GlvFkGvsz2EtA0Z4hQzZqWsrjwP5kXknHiu?= =?iso-8859-1?Q?TCyrRqZVRDmDdZrlEEhfGw2kB+muOBZwLF6eOh01lwSCe2vgcTLMOEa5US?= =?iso-8859-1?Q?UOZY2wdXzER7S222oQvNA6XmfWp0FA6LWl4FZkE1tgCcR/Qyp6XWGe/gpA?= =?iso-8859-1?Q?ZcAeVeOmaWo1s1Mclk2VF1UWsamQXBkeoJcCjzSoD4HtXtkbuVNI8wPLJ4?= =?iso-8859-1?Q?cVpj2CePb+rSs5WOSOqoQiCvYI0zknDo4rBJznSrMVgH3GKPR6GtVSJpvF?= =?iso-8859-1?Q?K9AzGx7q5LHyhc/f4ojJtykZ5R5ClzQ2XyFZvsFvnXU5MiKOQcL3CpCaMD?= =?iso-8859-1?Q?0IzXNjRrpoiaZGMM36h/GaUiojQRYlDnN0B8T+XZ82mBlhVoPDJ1pdcyum?= =?iso-8859-1?Q?+/D3X/OweysxIsim0vHNeRpvlBvmuVOi4q/RR19nQhaSoWS86kqktpWZ+/?= =?iso-8859-1?Q?7BxJB+QdDvvPx52zmWqJkVPt4m17KIRLNW/2QhwILkWlpn85BLRfIX8sfH?= =?iso-8859-1?Q?MyvJqvOF6e4o5duXaf/U933ZLJ8oXgIXBoWAujazmKX3ESCrK0lJEGgnPg?= =?iso-8859-1?Q?9/qqgWlPYbWJzLlz8mK2K2g66fNY7gu/y8MlF3Bz8OM8pVUHXJkuayFV/t?= =?iso-8859-1?Q?ZC5MY4gbq3hTChp11/8wcb8jSJoPhzcC+M6WKV6HJjA9Tr2wA5i+3+CK4w?= =?iso-8859-1?Q?SUBf6WRFA+FwC6zLGRs2+YGdjMIfhJRn3rwpQxmoOFdeHN7PghzLj5NraQ?= =?iso-8859-1?Q?O5TtATXcEGUJgRGymtQyk1sxMy2g7N5Or8ba6kN5IXrPzFtAm/YO2Mn5wy?= =?iso-8859-1?Q?DwShw52ciP2nltesP19g2SgdEznCWUKSUr8zhGv2UidQQ7RrPdDjAiTDGi?= =?iso-8859-1?Q?9NwZR0Cb4/KqtqegFFKC6i6dh1J2u2Kl8cueMFvQHB480fiPcvYCnei7sL?= =?iso-8859-1?Q?V/MeCfszfyRU01TmZ0AYRtYLWHdeXW8Y273SoHekgudG72JpivAwuaPy8O?= =?iso-8859-1?Q?TwrwFsC9lC7/knaFUK1D+eYx8V02IU7lpF6KrGW4+p5pOpUw7YsXU?= X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB5PR07MB1557; 6:s64I85IMsugYOKO17qGm4nDHj9kxN+hjFNhXC28r?= =?iso-8859-1?Q?Gz4u5cGeQjRKwr1mEGAlEJokMgkmQNXQ8fCe0sAQf1UAxYzHxPakpBZCYu?= =?iso-8859-1?Q?7B6D9u3sufnKBrq7Vho5RTdxcVH3C4XNmcMm7P45uWqcOjsDK+9k7v/2Qr?= =?iso-8859-1?Q?net33179nryMl+H03P+PLDsAueOxx0OJlpnyFiUOdhkU2yVpR9JOHIKW+q?= =?iso-8859-1?Q?bJylAnY6DLGQvCofQiyml+cIQS1K3McN0U6SXF9JrKkqOKz6H94WFc0jmC?= =?iso-8859-1?Q?a1WaSGd5AtTYbWlMbqPnVLYN6jCALf59mkRWsLJ35lr4X789tovGmEqHwZ?= =?iso-8859-1?Q?E7ogpT7KKE2rMaaGoqgOAz/eK3qNGHCHnWNu18UHoLal5sygmfPSFTG0lE?= =?iso-8859-1?Q?w5qRQTtlFQvTJj/TrkbwqQSJStzJAKrjnA2ePweS+pMwQmHSmeHXyoUSOS?= =?iso-8859-1?Q?JlNHxKLexgI1lXGhCj0y8nGS2l3xO/UUKQeAYocvlZskweH7a4Zagny5nw?= =?iso-8859-1?Q?Df5/L7vhum8Z3ketUmz6/TFskdZL80tJyQ/9PJYrtWBXAQI3yOBtH23iVR?= =?iso-8859-1?Q?8GP5di6igS8xswU/rB/aHmQDjq3n4oKZbD2ZRjGUvZC0xog1H8TMvbE10P?= =?iso-8859-1?Q?+zbre7ZsftZntjIrkEOwFDU4KyN9bhyfX+qC9P7Atzv/rnZb6/4XLogyrE?= =?iso-8859-1?Q?R8EAglu+IK+VkoxB2WJf30k3+/NYjJl1jkzWAOSABIe2mbQmypS6Z8jZCj?= =?iso-8859-1?Q?nHe6mMLIsD+QCJwFLPNtR3oFjwTVQ/g/qx239xxDEi9qGG8jreO0uTO7kk?= =?iso-8859-1?Q?Bl+DpQXKtpc4T99tGu3rVG9K+6h5ojL1E3jI5pUzPxAz/mwzWVB2TwuYx5?= =?iso-8859-1?Q?T5pxYpiyaYNPXyRe3AmdNmEFDLiT8igVx3/uYNWoAX9G+dhNLnfkSwfvw6?= =?iso-8859-1?Q?gKx5VzeTBcypDaD2rJICftc0FrJIxAlZw4NSQrSLDKsJU8EDiDltnvpGL1?= =?iso-8859-1?Q?hdauOrw+iI4el80vQZJ3SwQmScuLKJWApWU=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1557; 5:5M3rozggk7TyF00EKEkiydma27GmAyJLG7b9mm4amfStYk4eMbSHrUmDiKM0vf4QbsvUdALWBQwUSJMHcSeAEsdEpiZBDtw5OBoL/Air9gCNMH7BnNHQS37ec1qXK82+3OfWwfI4rmWo9LaNwjmn35tagnlIXHqnjsxZFh+lNZRsgj8EkpKcSKjHMTrEkVYYbw9sxw3i2Gs3btA3vhXqSJiedaRNFQPCmssUd1/6mR+KeDfmTdSi3wpkP+77PLi4X62EdwVv4iJzK8KLZqX4LJLXuuY7kaF4KoySgrCKl7/Jw3nQ4nAKExu/+0QyxA3WLZPDaKXgg1PO5wnj9MY43t8hC31B6ClT8i1BgnxZm3y7wFiVeZUbIPdwIW21+TW5HtwvAgm6Tx9zC3uRWA8VV+kMC4W0bDlopcKcKhuBdYOUIrk2IsiFh6CNVTMoB5iUK8kyZJ9OpqOBj3C+HnyxfM8JT5F1COZdm6LzsA+8MBMSdZii+Bh98NoUKOQDFDnU; 24:pqVXIPOmZGMe8k0zuPIi4/1vZGCC2cMOsyxiVVabQzs2EPLhCUdISuYpF8ytsr8XC5QH6O52mJ1ZbwfSdNM2yEuWvgP3ZKuCsBXd3FVFLUs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1557; 7:cy3MHG9QcOzRlcRazv2LBmx5RDOr6PwqKGeukYnBDgZ/M/S3Z20JUVCndNJeDXCmeC/9ODuV+ny2EK76rYOIDS3AQrR3vTedtthVU9asWPtBLkpuRF7J7RRVa3vaCc14AODDz5TG8y8M19op2g6D8wuOcVdN7HfMv3IptdgMdMnQj4xkPdHm1w8TcmQjXQBWmJMJRXVk3qHSEoOBqhtkPbM+YRwlYV2mpSQppEDTIeuXX+p+qCZDdVOL6BCsjGFiIlsQ5AB1CHcJLUHAPaD23p8RyLttCNvwh58f7CTabcRiblpSz1mATihuS/OcaSQs3Qqz8ITmKZ56wCEpEbaaeeEl1HwyJfhG0SFR9Umnn1UEpu+0M2E+PBkqAZwlhFfmWjCG2X+kSPWrLxQFnqHWHGxBkjGZ3z4xL0ph1xffxx8EqymkmKALl6+pV7sEvuXWL0qxGByOi1i7weJNgjhhzyqiCo92DRcfrDp3HeWZVPmodMX/t2fQm7S6U/1jl8oIiuw8RIi8GBPv2wu2YtzUSPS7c8+6+LFMAve56XC0OzOJJnzA36S97gwvxYZmr2OPyX3lt2M5aCVEUqgO+vz/wTP3+0eSNq0U1uULEyg03NZ71Be3aUlY6vAqLAkzCzhnWZ3W+MWye2ByaaJA3SGkwPeywoGnkNYhHCzLH9k9/b97vAxXLjCK5Vt21fCaqLu0U3YGuB7uFKUfpXeA+MDITzjveBHx2BDZEY4wbBXDNp8wbt13qIQmzDBGbQukml3WwKC0RtACSh3D44a13AL0cYTpMOQSj66eTzaQSvJhliA= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jul 2017 16:40:01.8226 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1557 Archived-At: Subject: Re: [Uta] consensus call on K/V vs JSON X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 16:40:08 -0000 Leif K/V Not something that I would expect to implement but rather my views are based on tracking the work of NETCONF and RESTCONF, the latter being JSON. I see the difficulties encounterd in the definition of RESTCONF and am very clear that JSON as a language is incomplete and somewhat loosely defined, sloppy even. I do not see the availability of libraries as affecting this - if the underlying technology is incomplete and loosely defined, then what a library that implements just that technology has to offer will perforce be incomplete and loosely defiined. K/V I find precise and unambiguous. Tom Petch ----- Original Message ----- From: "Leif Johansson" To: Sent: Friday, July 21, 2017 12:10 PM > > We had a (less than spirited) discussion in Praha about the K/V vs JSON. > > There was no clear consensus for switching from JSON to K/V based on > the proposal from the spec authors sent to the list last week. > > Victor expressed his views clearly and I'll not ask him to repeat > himself. I will attempt to summarize the discussion - feel free > to correct me! > > The situation is that of the active participants that are also > implementors one (postfix - Victor) has said that he does not believe > that postfix will ship with a standard JSON-based implementation but > that this doesn't preclude third-party plugins. > > The other major implementor who is also an active participant (google) > has stated that they have a JSON implementation but that they are > also eager to close this issue. One more implementor (Chris) has stated > no preference but also said that his (native) JSON parser is somewhat > smaller than his K/V one. > > Based on this and falling back to the IETF WG process as chair I would > conclude that there isn't enough consensus to make a change and that > we are staying with JSON. > > I would prefer to have more opinions (implementors in particular) but > we are also going to get past this. In particular I would like to hear > from implementors who (like Victor) have a problem living with either > choice. > > Please provide your feedback by EOB 1st of August. > > Cheers Leif > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta From nobody Fri Jul 21 13:15: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 508F8124E15 for ; Fri, 21 Jul 2017 13:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 (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 gYju6Ux5D7zX for ; Fri, 21 Jul 2017 13:15:31 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA2312009C for ; Fri, 21 Jul 2017 13:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500668130; d=isode.com; s=june2016; i=@isode.com; bh=V4uYYFr7nOo/fx62hHaGv+0UzMDG8Z27uYTMJ9T7Nq4=; 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=e4uhdiBc+uCP9IBrLAGxPkVVjafdP6mKE6wjxkR0/AtooE5O4HHlyU30tQvIbL1gOW3ZBH WEQNkbtQTuSPMZX1xfbqjIXdSziGskSQKxO9wuEMexz9I7Er8XP1+g4D0VUn+I7dyHxVhG LlUoHT4qwum/bWilC0nAy7zPldMDRLQ=; Received: from [172.16.18.185] (94.112.246.234.static.b2b.upcbusiness.cz [94.112.246.234]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 21 Jul 2017 21:15:30 +0100 From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: <013201d3023f$69713b60$4001a8c0@gateway.2wire.net> Date: Fri, 21 Jul 2017 22:16:05 +0200 Cc: uta@ietf.org, Leif Johansson Message-Id: References: <013201d3023f$69713b60$4001a8c0@gateway.2wire.net> To: "tom p." MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-58D63EAE-B618-41C0-8062-2FCBF2BD242D Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] consensus call on K/V vs JSON X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 20:15:33 -0000 --Apple-Mail-58D63EAE-B618-41C0-8062-2FCBF2BD242D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Tom, > On 21 Jul 2017, at 18:34, tom p. wrote: >=20 > Leif >=20 > K/V >=20 > Not something that I would expect to implement but rather my views are > based on tracking the work of NETCONF and RESTCONF, the latter being > JSON. I see the difficulties encounterd in the definition of RESTCONF > and am very clear that JSON as a language is incomplete and somewhat > loosely defined, sloppy even. Without taking a position on K/V versa JSON: I thought draft-ietf-jsonbis-rf= c7159bis-04 was fairly complete and can be implemented without relying on an= y other documents. Yes, there are some interesting corner cases, but I doubt= they will affect MTA STS use. > I do not see the availability of > libraries as affecting this - if the underlying technology is incomplete > and loosely defined, then what a library that implements just that > technology has to offer will perforce be incomplete and loosely > defiined. >=20 > K/V I find precise and unambiguous. >=20 > Tom Petch >=20 >=20 > ----- Original Message ----- > From: "Leif Johansson" > To: > Sent: Friday, July 21, 2017 12:10 PM >>=20 >> We had a (less than spirited) discussion in Praha about the K/V vs > JSON. >>=20 >> There was no clear consensus for switching from JSON to K/V based on >> the proposal from the spec authors sent to the list last week. >>=20 >> Victor expressed his views clearly and I'll not ask him to repeat >> himself. I will attempt to summarize the discussion - feel free >> to correct me! >>=20 >> The situation is that of the active participants that are also >> implementors one (postfix - Victor) has said that he does not believe >> that postfix will ship with a standard JSON-based implementation but >> that this doesn't preclude third-party plugins. >>=20 >> The other major implementor who is also an active participant (google) >> has stated that they have a JSON implementation but that they are >> also eager to close this issue. One more implementor (Chris) has > stated >> no preference but also said that his (native) JSON parser is somewhat >> smaller than his K/V one. >>=20 >> Based on this and falling back to the IETF WG process as chair I would >> conclude that there isn't enough consensus to make a change and that >> we are staying with JSON. >>=20 >> I would prefer to have more opinions (implementors in particular) but >> we are also going to get past this. In particular I would like to hear >> from implementors who (like Victor) have a problem living with either >> choice. >>=20 >> Please provide your feedback by EOB 1st of August. >>=20 >> Cheers Leif >>=20 >> _______________________________________________ >> Uta mailing list >> Uta@ietf.org >> https://www.ietf.org/mailman/listinfo/uta >=20 > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta --Apple-Mail-58D63EAE-B618-41C0-8062-2FCBF2BD242D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Tom,

On 21= Jul 2017, at 18:34, tom p. <da= edulus@btconnect.com> wrote:

<= div>Leif

K/V
<= br>Not something that I would expect to implement but rather my views a= re
based on tracking the work of NETCONF and RESTCONF, the l= atter being
JSON.  I see the difficulties encounterd in= the definition of RESTCONF
and am very clear that JSON as a= language is incomplete and somewhat
loosely defined, sloppy= even.

Without taking a positio= n on K/V versa JSON: I thought draft-ietf-jsonbis-rfc7159bis-04 was fa= irly complete and can be implemented without relying on any other documents.= Yes, there are some interesting corner cases, but I doubt they will affect M= TA STS use.

 I do not see the availability of
libraries as affecting this - if the underlying technology is incomplete<= /span>
and loosely defined, then what a library that implements jus= t that
technology has to offer will perforce be incomplete a= nd loosely
defiined.

K/V I f= ind precise and unambiguous.

Tom Petch


----- Original Message -----
From: "Leif Johansson" <= leifj@sunet.se>
To: <uta@ietf.org>
Sent: Friday, July 21, 2017 12:10 PM=

We had a (less than spirited) discussion in Praha abo= ut the K/V vs
JSON.

There w= as no clear consensus for switching from JSON to K/V based on
the proposal from the spec authors s= ent to the list last week.
=
Victor express= ed his views clearly and I'll not ask him to repeat
<= blockquote type=3D"cite">himself. I will attempt to summarize the disc= ussion - feel free
to= correct me!
<= br>
The situation is that of the= active participants that are also
implementors one (postfix - Victor) has said that he does not b= elieve
that postfix w= ill ship with a standard JSON-based implementation but
that this doesn't preclude third-party plu= gins.

The other major implementor who is a= lso an active participant (google)
has stated that they have a JSON implementation but that they a= re
also eager to clos= e this issue. One more implementor (Chris) has
= stated
no preference but also said= that his (native) JSON parser is somewhat
smaller than his K/V one.

Based on this and falling back to the IETF WG process as chair I woul= d
conclude that there= isn't enough consensus to make a change and that
we are staying with JSON.

I would prefer to have more opinions (implementors in particula= r) but
we are also go= ing to get past this. In particular I would like to hear
from implementors who (like Victor) have= a problem living with either
choice.

Please provide your feed= back by EOB 1st of August.
=
Cheers Leif

___________________________________________= ____
Uta mailing list=
Uta@ietf.org
https://www.ie= tf.org/mailman/listinfo/uta

_______________________________________________
Uta mailin= g list
Uta@ietf.org
https://ww= w.ietf.org/mailman/listinfo/uta
= --Apple-Mail-58D63EAE-B618-41C0-8062-2FCBF2BD242D-- From nobody Fri Jul 21 18:52:10 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 63E2D1242F7; Fri, 21 Jul 2017 18:52:09 -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.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150068832934.20538.2136100809167813174@ietfa.amsl.com> Date: Fri, 21 Jul 2017 18:52:09 -0700 Archived-At: Subject: [Uta] I-D Action: draft-ietf-uta-email-deep-08.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 01:52:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications WG of the IETF. Title : Cleartext Considered Obsolete: Use of TLS for Email Submission and Access Authors : Keith Moore Chris Newman Filename : draft-ietf-uta-email-deep-08.txt Pages : 28 Date : 2017-07-21 Abstract: This specification outlines current recommendations for use of Transport Layer Security (TLS) to provide confidentiality of email traffic between a mail user agent (MUA) and a mail submission or mail access server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-email-deep/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-uta-email-deep-08 https://datatracker.ietf.org/doc/html/draft-ietf-uta-email-deep-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-email-deep-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 22 00:53: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 893DD131C4F for ; Sat, 22 Jul 2017 00:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486] 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 x61N3oJL-Gku for ; Sat, 22 Jul 2017 00:53:14 -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 58E6E131C11 for ; Sat, 22 Jul 2017 00:53:14 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EEE147A330D; Sat, 22 Jul 2017 07:53:12 +0000 (UTC) Date: Sat, 22 Jul 2017 07:53:12 +0000 From: Viktor Dukhovni To: uta@ietf.org Message-ID: <20170722075312.GA8146@mournblade.imrryr.org> Reply-To: uta@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170721115046.GA23878@x2.esmtp.org> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Uta] consensus call on K/V vs JSON X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 07:53:15 -0000 On Fri, Jul 21, 2017 at 12:59:51PM +0100, Jeremy Harris wrote: > > I would prefer to have more opinions (implementors in particular) but > > There's no way I would add JSON support to exim. On Fri, Jul 21, 2017 at 04:50:46AM -0700, Claus Assmann wrote: > There's no way I would add JSON support to sendmail. I'll chime in with no plans to add a JSON dependency to Postfix. The current KV proposal is fine. I would have avoided the superfluous ":" characters after the keys: mx foo.example.com rather than: mx: foo.example.com but I don't care enough to make this an issue. The authors are free to drop the unnecessary ":" if they agree. The K/V would then be a sequence of lines, with one K/V per line, with each line of the form: is whatever goes for EOL in HTTP text/plain content types, which IIRC is . Client implementations MAY be liberal and also allow , but server implementations SHOULD only use . -- Viktor. From nobody Sat Jul 22 00:56:19 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 055E3131C58 for ; Sat, 22 Jul 2017 00:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeXat1duEMO1 for ; Sat, 22 Jul 2017 00:56:17 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 EFDF6131C4F for ; Sat, 22 Jul 2017 00:56:16 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id w191so29712648wmw.1 for ; Sat, 22 Jul 2017 00:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=ACuYXAIvJwq5eSpfUEFvJcq5BRlaeJsWdNV/PEVDxvg=; b=GvtyXumF47BlYuFr6IvAWxs5qscambmI6Hr9tbrXIWb0vtVJeWfEpqgMoGXqTY67Wi GZJvEaL7wO1ou+63kmcrq8698XN8CfJSURcl8r29GLQj/x0JZYd8UIV95EnKM1koWVh0 ep7oNT592Q3iEUe61u3yNMj1K3tjboGoXwGGVNnDj+aGdhlXZ3Jrgpz7ckvRecyqfrn6 UP0r7+f+NhYltFPb5lQEq/BVHJMZozlSjvUTB1SCxunK0Q5cOV7uAPK5qyK9XcAgmrO5 dmUHdoNGO1ltqIEU8Ipwj/DYVo0w/Se8rRkaxHIMABWc2RhH7XGpzIeNtBYlDTkYENfa MgUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; bh=ACuYXAIvJwq5eSpfUEFvJcq5BRlaeJsWdNV/PEVDxvg=; b=qT+09b4OAuX36Rz06GlvlMVrGf+SaRGAYB/SKfeIo5jTJ/8dkpe34Yz8IUhjX6Nc4x J0GgS9oD/PpqudJdEhfli2QtGrQIFS0tJpLv6y/A/QphlOuc7iERdIwBuYmeySeGttyS MVe6MJ0ytbAoTpaRum0dvd31rt4zjkOZY/nEM2SDgbTZapOmZlchwCwBhXXpR8SRXqon Hr6KZeHoAMf6YMzEgUAWK1gdmB0baw3GXB0sd4xcXer3Kkgd8iAm6OJuwgAxVKb+TPxT EJt0UT571lEEKFSCMJ5VPPrxOqPByyJ1nR1Bhry0/+eupB98xha0yeLkttJRMwkXvVil jrBQ== X-Gm-Message-State: AIVw111r67mbOQ+w+TUVWWXi804iEY9lImTrb4CGV7ZJORewFGfvbc8/ RYtDTTsDLCuOHvrosHH99A== X-Received: by 10.28.16.193 with SMTP id 184mr905230wmq.42.1500710175286; Sat, 22 Jul 2017 00:56:15 -0700 (PDT) Received: from [10.0.1.160] ([62.168.35.69]) by smtp.gmail.com with ESMTPSA id x19sm8559510wrd.66.2017.07.22.00.56.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Jul 2017 00:56:14 -0700 (PDT) From: Leif Johansson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Sat, 22 Jul 2017 09:56:14 +0200 Message-Id: <40B55F6C-657D-4A02-A356-1C08CB7B13A5@mnt.se> References: <20170722075312.GA8146@mournblade.imrryr.org> In-Reply-To: <20170722075312.GA8146@mournblade.imrryr.org> To: uta@ietf.org X-Mailer: iPhone Mail (14F89) Archived-At: Subject: Re: [Uta] consensus call on K/V vs JSON X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 07:56:19 -0000 Thx for your feedback, Keep the reviews coming - until next Monday when we'll close this issue. Skickat fr=C3=A5n min iPhone > 22 juli 2017 kl. 09:53 skrev Viktor Dukhovni : >=20 > On Fri, Jul 21, 2017 at 12:59:51PM +0100, Jeremy Harris wrote: >=20 >>> I would prefer to have more opinions (implementors in particular) but >>=20 >> There's no way I would add JSON support to exim. >=20 >> On Fri, Jul 21, 2017 at 04:50:46AM -0700, Claus Assmann wrote: >>=20 >> There's no way I would add JSON support to sendmail. >=20 > I'll chime in with no plans to add a JSON dependency to Postfix. > The current KV proposal is fine. I would have avoided the > superfluous ":" characters after the keys: >=20 > mx foo.example.com >=20 > rather than: >=20 > mx: foo.example.com >=20 > but I don't care enough to make this an issue. The authors are > free to drop the unnecessary ":" if they agree. >=20 > The K/V would then be a sequence of lines, with one K/V per line, > with each line of the form: >=20 > >=20 > is whatever goes for EOL in HTTP text/plain content types, > which IIRC is . Client implementations MAY be liberal and > also allow , but server implementations SHOULD only use . >=20 > --=20 > Viktor. >=20 > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta From nobody Sat Jul 22 01:29:17 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 6ABFF131C58 for ; Sat, 22 Jul 2017 01:29:15 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTdI5NfM5K-U for ; Sat, 22 Jul 2017 01:29:13 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 96E35127201 for ; Sat, 22 Jul 2017 01:29:13 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id y43so89495728wrd.3 for ; Sat, 22 Jul 2017 01:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=b5K4XMi+phXl3Z/J/BPi8V+2sr1Og6ubI2WWpAMRPDA=; b=x+A2KxMorgJuAESMlE8D+FQ9K7VPQlsR5THH5IiGxAcxB6lRhe6bF5crsCvwt0awZz WWgGq9AOF9SgfAacML+5LGMZDGPgo498dpXyVxbqaBC1ho6RgImZWSIwHOxacxlw+OcD SqY/IdrQ9rmO9sczJU7jAsUBLfG3gUa6np3Ds1KBIlZN55+nFqtlaTfsCGEa++hPnaoG 44sbWHJp544eohj+ycl2T41k2x3J807oJ4CW6FuY6E5yYqPxPTFD+qz4YC3t9sTHbd8v tCNLra7m8OPGYRzlHFvUY7XYagmYkzvsyrPHsiRnlvwSU5LQxtmTsd2wClv721TXXrss cESw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=b5K4XMi+phXl3Z/J/BPi8V+2sr1Og6ubI2WWpAMRPDA=; b=Vk4GhtKFOu6YVWkI6hPCAqmmyEUYLqkVVhxxMe7a526SJ6ILjBuw+a7hZ6/O7sj9fY s1sWqy1AfJGVP3Y8MK+TMnJmIdZddbwS5+y24z266Pt1Ck6UHwXCmRJCJY7p6/ppUN8+ AgP2JGP/AGyX0CjR0Dpa9bQRlXUa5rUzi9ztAVQTPouW0E3wOxAuj/4wznPseBYM5GkG 71tuTgnqNOrRzNG2DM9cV9DPhCW7BIJTo0rf8SrNzNHe+Tjlgt8kyAPKiVNQwl0fQMzo 3RtLoQYHAcvN7C8YSQNtuInjFo2v5SrT4NhDrC6555QEMnBD0MZtUiNLlV9FLzgrn1zi DUJw== X-Gm-Message-State: AIVw1103XDLdTutc3QzkVMEnOaTShcySn0A4eBp1xHLaXqO6Sy87/pgw 24+PI7cQUy3thnFQVBzkHg== X-Received: by 10.223.160.240 with SMTP id n45mr368097wrn.74.1500712151482; Sat, 22 Jul 2017 01:29:11 -0700 (PDT) Received: from [10.0.1.221] ([62.168.35.68]) by smtp.gmail.com with ESMTPSA id 46sm12123632wrz.8.2017.07.22.01.29.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Jul 2017 01:29:10 -0700 (PDT) To: uta@ietf.org From: Leif Johansson Message-ID: Date: Sat, 22 Jul 2017 10:29:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Uta] WGLC on draft-ietf-uta-email-deep-08.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 08:29:15 -0000 In Prague there was consensus that deep was ready to go. This starts a 3 week WGLC on draft-ietf-uta-email-deep-08. Please provide your feedback on this document by August 14th. Cheers Leif From nobody Sat Jul 22 01:44: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 5029712778D for ; Sat, 22 Jul 2017 01:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] 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 5iRGmjpxMgQP for ; Sat, 22 Jul 2017 01:44:52 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id D75E6127201 for ; Sat, 22 Jul 2017 01:44:51 -0700 (PDT) Received: from Maxs-MacBook-Pro.local (unknown [62.168.35.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 49C823743B66 for ; Sat, 22 Jul 2017 04:44:50 -0400 (EDT) To: uta@ietf.org References: <20170722075312.GA8146@mournblade.imrryr.org> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <8627ca20-d9cf-5dc0-a85c-a828f679a2fc@openca.org> Date: Sat, 22 Jul 2017 10:44:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170722075312.GA8146@mournblade.imrryr.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030308070800060707000203" Archived-At: Subject: Re: [Uta] consensus call on K/V vs JSON X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 08:44:53 -0000 This is a cryptographically signed message in MIME format. --------------ms030308070800060707000203 Content-Type: multipart/alternative; boundary="------------EC3F34F258512240F86533CB" Content-Language: en-US This is a multi-part message in MIME format. --------------EC3F34F258512240F86533CB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, +1 for the K/V solution. Adding JSON dependencies does not seem a good=20 idea to me too :-) Cheers, Max On 7/22/17 9:53 AM, Viktor Dukhovni wrote: > On Fri, Jul 21, 2017 at 12:59:51PM +0100, Jeremy Harris wrote: > >>> I would prefer to have more opinions (implementors in particular) but= >> There's no way I would add JSON support to exim. > On Fri, Jul 21, 2017 at 04:50:46AM -0700, Claus Assmann wrote: > >> There's no way I would add JSON support to sendmail. > I'll chime in with no plans to add a JSON dependency to Postfix. > The current KV proposal is fine. I would have avoided the > superfluous ":" characters after the keys: > > mx foo.example.com > > rather than: > > mx: foo.example.com > > but I don't care enough to make this an issue. The authors are > free to drop the unnecessary ":" if they agree. > > The K/V would then be a sequence of lines, with one K/V per line, > with each line of the form: > > > > is whatever goes for EOL in HTTP text/plain content types, > which IIRC is . Client implementations MAY be liberal and > also allow , but server implementations SHOULD only use . > --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------EC3F34F258512240F86533CB Content-Type: multipart/related; boundary="------------F8B1DABB849EFEDCC700F667" --------------F8B1DABB849EFEDCC700F667 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi all,

+1 for the K/V solution. Adding JSON dependencies does not seem a good idea to me too :-)

Cheers,
Max


On 7/22/17 9:53 AM, Viktor Dukhovni wrote:
On Fri, Jul 21, 2017 at 12:59:51PM +0100, Jeremy Har=
ris wrote:


I would prefer to have more opinions (implemento=
rs in particular) but

There's no way I would add JSON support to exim.

On Fri, Jul 21, 2017 at 04:50:46AM -0700, Claus Assmann wrote:


There's no way I would add JSON support to sendmai=
l.

I'll chime in with no plans to add a JSON dependency to Postfix.
The current KV proposal is fine.  I would have avoided the
superfluous ":" characters after the keys:

	mx foo.example.com

rather than:

	mx: foo.example.com

but I don't care enough to make this an issue.  The authors are
free to drop the unnecessary ":" if they agree.

The K/V would then be a sequence of lines, with one K/V per line,
with each line of the form:

    <KEY><whitespace><VALUE><optional trailing white=
space><EOL>

<EOL> is whatever goes for EOL in HTTP text/plain content types,
which IIRC is <CRLF>.  Client implementations MAY be liberal and
also allow <LF>, but server implementations SHOULD only use <CRL=
F>.

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------F8B1DABB849EFEDCC700F667 Content-Type: image/png; name="fgocojgoibblkdcf.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="fgocojgoibblkdcf.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------F8B1DABB849EFEDCC700F667-- --------------EC3F34F258512240F86533CB-- --------------ms030308070800060707000203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfUwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU+MIIEJqADAgECAhEA/bu0LJsAKXVhEpPllE0lYzANBgkq hkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE2MTEzMDAwMDAwMFoXDTE3MTEzMDIzNTk1OVowJDEiMCAGCSqGSIb3DQEJ ARYTZGlyZWN0b3JAb3BlbmNhLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKnGg/GUuTjn0dKCEpRhVd+uiYbCjLQht+dbkvyRLm4aqlL7yHCe+21HQLIcU68ZCHT2ImpF CFFrxQMQh4KijAwkbLc8+xZZSwXeZt58qnPn5c4vcpYU5LFq1q9oDT8MXH33DhVUT/7/IDSi wRWM6FcgM6VrIjBmmvl9dW3gQaEd1bOAhO2X489fChRQYTaB6AEhqb8RSvWW7ZYzfNw8sPxV afMCzWBPpO5RmLqOciZBhAinAM9dXmP5ckg/HjJQYSjvTc7HDcg75mpr5wH8Tk/ChyIYk4CT zqONQV8HKCzZPTVmd2ZuMrliJwMFs3uEg0aBSzHjJTyAmZ89q5Mz3XsCAwEAAaOCAfEwggHt MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTGgh9JWBvcrak1 PhAWBLGrECNAjzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3Bl bmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAdIqtPcvA+g6VTYUpEo0I9Vtnrf9PiZ3OpkRL O7U78EaeUfvOotThqj74XyrIl6eYlg+EdGIIUVB1CI05wPMRlZN3/R/Tj28vWkwckLRIbpL4 A5ZQyKgA9vK15/EEBVFIpCtAI6xJX0zx6TySlIgjcca05L0JgO7nzLGD2MY/dVWEE+QBuNI+ NBci+c+9q6YDPoXOpo0Wwbe0Bq95jNNWmZwhGzc+N5rhOGZmQT4P7TnpzvMik8ugbkqWyyHa DQbLKYzM1RKS/mwcvFqjJCQgORnaCilSbfClwdWGI7vwcTR8eAzduvwG61u46Cgb57K5sMck RicpWRvEYxCCVTwnozGCBEQwggRAAgEBMIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCWCGSAFlAwQC AQUAoIICYzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA3 MjIwODQ0NDhaMC8GCSqGSIb3DQEJBDEiBCBV7+X3Lmt8c0VIj+0bZt7v1ybiskHHc2pisUib H43fATBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHCBgkrBgEEAYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAP27tCybACl1YRKT5ZRNJWMwgcQGCyqGSIb3DQEJ EAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCSqGSIb3DQEBAQUABIIBADsFR0h6289b4Nz0 GLkUTZxbvgdirkWaHNnllQaC6PRgl8v9lB8EmGXoopBOXY802ugYN46Iu4HlPmPINw42JngB xvNJkG3ztiTSJ8M7wNrl0FhL+THMIaIzRpZkgGZn0G96MkVPvF7x0olnySYaKSKjD0Imp/2u lS1eub+x9rTzKE/0T57ocf5NIQOLohqmbXWpBOG2bgY/mTwzE61N+6O5RgzCbK0+DAGkL/xm mv61EBvkrZHWITHuYqLDItZtvfONt/c9TyWWMjfZ+bIZ3jC1+Aqmoi0aebI4MYAQwq7lVSuD KwDAZHOZNMDjtHA+kq/A22hCcAmn1k6HklTp1FIAAAAAAAA= --------------ms030308070800060707000203-- From nobody Sat Jul 22 02:20: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 D8C5F131D11 for ; Sat, 22 Jul 2017 02:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqsmIxK4pSea for ; Sat, 22 Jul 2017 02:20:12 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 11A9A131D10 for ; Sat, 22 Jul 2017 02:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500715211; d=isode.com; s=june2016; i=@isode.com; bh=5FTd3GPFeLIKN4fA3o8s8xiW83NnQXUKlcFwDdeDYPY=; 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=Elqh36KKQGcFEz5MdW7QfS5Jybu4IFuRWeMQlCim+44bG34XbL/bnDKrs1pK7SbCwmUTTD yMVbLTn9CLGVDA0DpEH0SA9FmtmNndFgiFYJCCOzj68RXRMParcXxZLF6eJ0mlWKZG9EZI Ux+pceGEExQBYOXmQgA35qUDSJs8ZoM=; Received: from [10.220.1.0] ((unknown) [85.255.232.28]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 22 Jul 2017 10:20:09 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov Date: Sat, 22 Jul 2017 11:14:56 +0200 References: <20170722075312.GA8146@mournblade.imrryr.org> In-Reply-To: <20170722075312.GA8146@mournblade.imrryr.org> To: uta@ietf.org Message-Id: X-Mailer: iPhone Mail (13G35) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] consensus call on K/V vs JSON X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 09:20:13 -0000 Hi, If we end up going the K/V route: > On 22 Jul 2017, at 09:53, Viktor Dukhovni wrote: > > On Fri, Jul 21, 2017 at 12:59:51PM +0100, Jeremy Harris wrote: > >>> I would prefer to have more opinions (implementors in particular) but >> >> There's no way I would add JSON support to exim. > >> On Fri, Jul 21, 2017 at 04:50:46AM -0700, Claus Assmann wrote: >> >> There's no way I would add JSON support to sendmail. > > I'll chime in with no plans to add a JSON dependency to Postfix. > The current KV proposal is fine. I would have avoided the > superfluous ":" characters after the keys: > > mx foo.example.com > > rather than: > > mx: foo.example.com > > but I don't care enough to make this an issue. The authors are > free to drop the unnecessary ":" if they agree. This has a nice property that I can reuse a generic header field parser. > The K/V would then be a sequence of lines, with one K/V per line, > with each line of the form: > > > > is whatever goes for EOL in HTTP text/plain content types, > which IIRC is . Yes. > Client implementations MAY be liberal and > also allow , but server implementations SHOULD only use . No bare LF please, CRLF only. Best Regards, Alexey From nobody Sat Jul 22 14:57: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 93BD61241FC for ; Sat, 22 Jul 2017 14:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonnection.nl 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 rqoXJg0p36la for ; Sat, 22 Jul 2017 14:57:54 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id CCF8B127977 for ; Sat, 22 Jul 2017 14:57:53 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3xFM284ppsz1L8nH; Sat, 22 Jul 2017 23:57:52 +0200 (CEST) Received: from tiger.sonnection.nl (D57E1706.static.ziggozakelijk.nl [213.126.23.6]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3xFM283Nwqz5MgwC; Sat, 22 Jul 2017 23:57:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by tiger.sonnection.nl (Postfix) with ESMTP id 43666422288; Sat, 22 Jul 2017 23:57:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at tiger.sonnection.nl Received: from tiger.sonnection.nl ([127.0.0.1]) by localhost (tiger.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TxbMIjEwEcZf; Sat, 22 Jul 2017 23:57:52 +0200 (CEST) Received: from [192.168.40.49] (unknown [192.168.40.49]) by tiger.sonnection.nl (Postfix) with ESMTPSA id 2189E422287; Sat, 22 Jul 2017 23:57:52 +0200 (CEST) To: Leif Johansson , uta@ietf.org, Jim Fenton References: <06bffe72-9d6a-0225-2fcd-bb306396b682@sunet.se> From: "Rolf E. Sonneveld" Organization: Sonnection B.V. Message-ID: Date: Sat, 22 Jul 2017 23:57:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <06bffe72-9d6a-0225-2fcd-bb306396b682@sunet.se> Content-Type: multipart/alternative; boundary="------------59F32578F07B8CEB7C9B6B9E" Content-Language: en-US DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1500760672; bh=uQa3moKc5G41Vri6bbssYRbWynUOb9jsjJ+g6D0Bmww=; h=Subject:To:From:Message-ID:Date:From; b=a45GpVL4JFuHDd3/drr75OSSS7eEawlostjcj5ALAyTIAAoU8tSUN25a7RyFbJv2J ZdTaDxESMRtXTOmdoPRpdN5yGpFHc9XQdJaWci5BNXvtXK6SuOR9g6IwgEcLZEoqF2 uOYkFhbBKrA/P0L66trzLiTVAUcp8mYqUl/IuE+U= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3xFM284ppsz1L8nH Archived-At: Subject: Re: [Uta] adopt draft-fenton-smtp-require-tls-03 as WG document 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 Jul 2017 21:57:56 -0000 This is a multi-part message in MIME format. --------------59F32578F07B8CEB7C9B6B9E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, Jim, On 21-07-17 12:56, Leif Johansson wrote: > There was clear consensus in Praha to adopt > draft-fenton-smtp-require-tls-03 as a WG document > (draft-ietf-uta-smtp-require-tls-00). > > If anyone objects to that, now is the time to speak up. no objection! Just wanted to send my review of -03 here: Page 3: Attacks are more described in more detail in the Security Considerations section of this document. s/are more described/are described/ Page 3: it also requires that the SMTP server advertise that it also supports REQUIRETLS For some reason, I think that the second 'also' is not correct: the advertisement is done before the SMTP server 'knows' that the client is using REQUIRETLS. Page 3 (sorry for the nitpicking): in effect promising that it will honor the requirement to require TLS transmission and REQUIRETLS support for onward transmission of messages specifying that requirement. Suggestion: s/requirement to require/requirement to enforce/ And, referring to the first part of this sentence, you may want to: s/transmission of messages specifying that requirement/transmission of those messages Page 4: this option MUST only be specified in the context of an SMTP session meeting the security requirements that have been specified: Just for reasons of clarity, you might add a third bullet, which describes what already was mentioned earlier: - the SMTP server advertises that it supports REQUIRETLS. Page 5: 3. Establish a TLS-protected SMTP session with its peer SMTP server and authenticate the server's certificate with the specified authentication method. you may want to add a reference to RFC6125 here. Page 5: 1. Look up the SMTP server to which the message is to be sent. A reference here to RFC5321 par. 5.1 would be nice, as in the remainder of this section it may not be clear for a developer that the absence of an MX record in the presence of an A record should be treated as an MX record with pref. 0 pointing to that host. You have this reference on page 6 in the REQUIRETLS=NO section so it would be consistent to add it here. Page 6: Following such a failure, the SMTP client MUST send a non-delivery notification to the reverse-path of the failed messag Reading this paragraph it seems there is no room for a client to postpone the decision to send a NDN, for example in case of a DNS tempfail. Page 6: o If the server does not advertise the REQUIRETLS capability, send the message in the usual manner (without the REQUIRETLS option, because the server will not understand the option). There are circumstances where a middlebox may remove the REQUIRETLS advertisement and for these cases (in combination with REQUIRETLS=NO) it might still be useful to send the MAIL FROM with the REQUIRETLS option in order to convey the wish of the sender to send using a TLS encrypted channel. Comments? Page 7: Mail delivery agents supporting REQUIRETLS SHOULD require that retrieval of messages requiring transport encryption take place over authenticated, encrypted channels. AFAIK there is no mechanism where an MDA could require this from the Mail Access Server. Unless you mean the MDA should set some sort of flag, which then can be honored by the mail access server? Page 8: REQUIRETLS users SHOULD use caution when sending to mailing lists and MUST NOT assume that REQUIRETLS applies to messages from the list operator to list members. Usually, users clicking on a 'Require encryption' button will not read this RFC and often do not even know whether a To: or Cc: mail address they use is a mailing list with specific characteristics. So I wonder if this line in the draft should better address the owner of the domain, recommending to educate their users not too expect (end2end) encryption in all cases. Par. 7: I wonder if a fourth attack vector should be mentioned: a DOS type of attack where an attacker uses REQUIRETLS, using the RFC5321.MailFrom address of a victim (using an MTA supporting REQUIRETLS) and sending messages to as many MTA's-not-supporting-REQUIRETLS it can find, resulting in a bombardment of the victim with NDN's. However, this type of DOS attack can be achieved already in other ways, so I think it need not be mentioned. /rolf --------------59F32578F07B8CEB7C9B6B9E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Jim,

On 21-07-17 12:56, Leif Johansson wrote:
There was clear consensus in Praha to adopt
draft-fenton-smtp-require-tls-03 as a WG document
(draft-ietf-uta-smtp-require-tls-00).

If anyone objects to that, now is the time to speak up.

no objection! Just wanted to send my review of -03 here:


Page 3:

Attacks are more described in more detail in the Security 
   Considerations section of this document.
s/are more described/are described/

Page 3:

it also requires that the SMTP server advertise that it
   also supports REQUIRETLS

For some reason, I think that the second 'also' is not correct: the advertisement is done before the SMTP server 'knows' that the client is using REQUIRETLS.

Page 3 (sorry for the nitpicking):

in effect promising that it will honor the
   requirement to require TLS transmission and REQUIRETLS support for
   onward transmission of messages specifying that requirement.

Suggestion:
s/requirement to require/requirement to enforce/

And, referring to the first part of this sentence, you may want to:

s/transmission of messages specifying that requirement/transmission of those messages

Page 4:

this option MUST only be specified in the context
   of an SMTP session meeting the security requirements that have been
   specified:

Just for reasons of clarity, you might add a third bullet, which describes what already was mentioned earlier:

- the SMTP server advertises that it supports REQUIRETLS.

Page 5:

   3.  Establish a TLS-protected SMTP session with its peer SMTP server
       and authenticate the server's certificate with the specified
       authentication method.

you may want to add a reference to RFC6125 here.

Page 5:

   1.  Look up the SMTP server to which the message is to be sent.

A reference here to RFC5321 par. 5.1 would be nice, as in the remainder of this section it may not be clear for a developer that the absence of an MX record in the presence of an A record should be treated as an MX record with pref. 0 pointing to that host. You have this reference on page 6 in the REQUIRETLS=NO section so it would be consistent to add it here.

Page 6:

   Following such a failure, the SMTP client MUST send a non-delivery
   notification to the reverse-path of the failed messag

Reading this paragraph it seems there is no room for a client to postpone the decision to send a NDN, for example in case of a DNS tempfail.

Page 6:

   o  If the server does not advertise the REQUIRETLS capability, send
      the message in the usual manner (without the REQUIRETLS option,
      because the server will not understand the option).

There are circumstances where a middlebox may remove the REQUIRETLS advertisement and for these cases (in combination with REQUIRETLS=NO) it might still be useful to send the MAIL FROM with the REQUIRETLS option in order to convey the wish of the sender to send using a TLS encrypted channel. Comments?

Page 7:

   Mail delivery agents supporting REQUIRETLS SHOULD require that
   retrieval of messages requiring transport encryption take place over
   authenticated, encrypted channels.

AFAIK there is no mechanism where an MDA could require this from the Mail Access Server. Unless you mean the MDA should set some sort of flag, which then can be honored by the mail access server?

Page 8:

REQUIRETLS users SHOULD use caution
   when sending to mailing lists and MUST NOT assume that REQUIRETLS
   applies to messages from the list operator to list members.

Usually, users clicking on a 'Require encryption' button will not read this RFC and often do not even know whether a To: or Cc: mail address they use is a mailing list with specific characteristics. So I wonder if this line in the draft should better address the owner of the domain, recommending to educate their users not too expect (end2end) encryption in all cases.

Par. 7:

I wonder if a fourth attack vector should be mentioned: a DOS type of attack where an attacker uses REQUIRETLS, using the RFC5321.MailFrom address of a victim (using an MTA supporting REQUIRETLS) and sending messages to as many MTA's-not-supporting-REQUIRETLS it can find, resulting in a bombardment of the victim with NDN's. However, this type of DOS attack can be achieved already in other ways, so I think it need not be mentioned.

/rolf

--------------59F32578F07B8CEB7C9B6B9E-- From nobody Mon Jul 24 09:04:36 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 A4854131E8F for ; Mon, 24 Jul 2017 09:04:34 -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 UR2eLN9aToHh for ; Mon, 24 Jul 2017 09:04:33 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD3B131E8E for ; Mon, 24 Jul 2017 09:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500912272; d=isode.com; s=june2016; i=@isode.com; bh=4oJhMLXwmAs8JOrfJ7LefSlswLEfJRDEafJsjeU4Lrc=; 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=Mvq6Y1FkkhhJ1jpKlo4EAztxUSIPm/WjbzsZY79E03APaCmIDDdw/NB/s811hoxU5wXH0q 70aHjyg3qpZKA0DWClMX2war1jgHdH7d2yWCY1UtZGEeXY1fIC3nSMNnABa6MOpruZcSIA Xdf62LlPdVGKGoikSt6cfVFTK2NjXEI=; 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 ; Mon, 24 Jul 2017 17:04:32 +0100 To: "uta@ietf.org" From: Alexey Melnikov Message-ID: Date: Mon, 24 Jul 2017 17:04:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Uta] Review of draft-ietf-uta-email-deep-08 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 Jul 2017 16:04:35 -0000 I am generally very pleased with -07 and -08. A few minor comments: 1. Introduction This memo does not address use of TLS with SMTP for message relay (where Message Submission [RFC6409] does not apply). Improved use of TLS with SMTP for message relay requires a different approach. One approach to address that topic is described in [RFC7672]. I think you should also reference MTA STS draft informatively here. 4.1. Deprecation of Services Using Cleartext and TLS Versions < 1.1 The specific means employed for deprecation of cleartext Mail Access Services and Mail Submission Services this MAY vary from one MSP to Extraneous "this" above. the next in light of their user communities' needs and constraints. Later in the same section: Also, users authenticating with passwords SHOULD be required to change those passwords when migrating from cleartext to TLS, since the old passwords were likely to have been compromised. Not necessarily true with something like SCRAM or GSSAPI (if PLAIN is also disabled), but I don't know how to word this better. I.e. authentication might still not expose the password without TLS. Transition of users from SSL or TLS 1.0 to later versions of TLS MAY be accomplished by a means similar to that described above. There are multiple ways to accomplish this. One way is for the server to refuse a ClientHello message from any client sending a protocol version number corresponding to any version of SSL or TLS 1.0. I don't think this is quite right: my understanding is that client can send such versions (for backward compatibility), but end up negotiating TLS 1.2. So the advice here should be that neither the server nor the client can negotiate SSL 2.0/TLS 1.0. Another way is for the server to accept ClientHello messages from some client versions that it does not wish to support, but later refuse to allow the user to authenticate. The latter method may provide a better indication to the user of the reason for the failure but (depending on the protocol and method of authentication used) may also risk exposure of the user's password over an channel which is known to not provide adequate confidentiality. 5.2. Minimum Confidentiality Level MUAs SHOULD NOT allow users to "click through" to access or send mail It is not clear to me whether you are recommending better UI or a UI that doesn't allow the user to bypass this? via an connection, or to authenticate to any service using a password, if that account is configured to impose minimum confidentiality requirements and that connection does not meet all of those requirements. Experience indicates that users presented with such an option often "click through" without understanding the risks that they're accepting by doing so. 5.4. Certificate Pinning A pinned certificate is subject to a man-in-the-middle attack at account setup time, and lacks a mechanism to revoke or securely refresh the certificate. Isn't this a MUA UI issue? I.e., a MUA may allow users to manage pinned certificates. 5.5. Client Certificate Authentication MUAs MAY implement client certificate authentication on the Implicit TLS port. An MUA MUST NOT provide a client certificate during the "MUST NOT" sounds too strong. Why? TLS handshake unless the server requests one and the client has determined the certificate can be safely used with that specific server, OR the client has been explicitly configured by the user to use that particular certificate with that server. How to make this determination is presently implementation specific. 8. Security Considerations It could be argued that sharing the name and version of the client software with the server has privacy implications. You should probably mention IMAP ID extension (RFC 2971) here, as well as other known mechanisms. Best Regards, Alexey From nobody Mon Jul 24 21:18:25 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 AFDBD126BFD for ; Mon, 24 Jul 2017 21:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 oTX0xHVLMt-X for ; Mon, 24 Jul 2017 21:18:21 -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 BC7B61200F3 for ; Mon, 24 Jul 2017 21:18:21 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2F0CE2086F; Tue, 25 Jul 2017 00:18:21 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 25 Jul 2017 00:18:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=yMGfRnPKhwI/ako2Fm WC68m6oHcyctVEyW87pUTS1ok=; b=KXrSLkUQtQJZ8L+6D+Ozgq+9YNM6rKT5uJ 5So4RmeOpx6ZBXLw8Yyk0AIT24i3NG76RfTXty7pohQsBHXjvMq5j0Ew7pRxw8EX S9riF2bcdyPQC1q9mPd4IxQKrsDzen8yswxgn1MNKz2CkilreSFTvlCZUnaj40ii 25I0QxXq66DyYB+YEHPrpgZrI/Q7I5Ph8dKjuRYVyr0giC5gQPJxL18daJnqTkxx MziQ7M1YJvsJI71glB2i8gqYWcCokY6XLGQHtrjWj74nmqBRw5YGOe95v5XiI6K7 XMUZ3p8DO+oMgmRSErGzmaQckOYssRN1/g3pambr3CUOgO584i9w== X-ME-Sender: X-Sasl-enc: xeyHuHrYbn70H0YKH2+fnWQbU5Yw1NYex8iZU1pwaxdO 1500956300 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 B982A7E16E; Tue, 25 Jul 2017 00:18:20 -0400 (EDT) To: uta@ietf.org References: From: Keith Moore Message-ID: Date: Tue, 25 Jul 2017 00:18:20 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------14CB9051195B4CA9A14CE11A" Content-Language: en-US Archived-At: Subject: Re: [Uta] Review of draft-ietf-uta-email-deep-08 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 Jul 2017 04:18:24 -0000 This is a multi-part message in MIME format. --------------14CB9051195B4CA9A14CE11A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Alexey, Thanks for the review! Some responses: On 07/24/2017 12:04 PM, Alexey Melnikov wrote: > I am generally very pleased with -07 and -08. > > A few minor comments: > > 1. Introduction > > This memo does not address use of TLS with SMTP for message relay > (where Message Submission [RFC6409] does not apply). Improved use of > TLS with SMTP for message relay requires a different approach. One > approach to address that topic is described in [RFC7672]. > > I think you should also reference MTA STS draft informatively here. I'm personally okay with doing that. > > 4.1. Deprecation of Services Using Cleartext and TLS Versions < 1.1 > > The specific means employed for deprecation of cleartext Mail Access > Services and Mail Submission Services this MAY vary from one MSP to > > Extraneous "this" above. > > the next in light of their user communities' needs and constraints. > > > Later in the same section: > > Also, users authenticating with passwords SHOULD be required to > change those passwords when migrating from cleartext to TLS, since > the old passwords were likely to have been compromised. > > Not necessarily true with something like SCRAM or GSSAPI (if PLAIN is > also disabled), but I don't know how to word this better. I.e. > authentication might still not expose the password without TLS. How about: Also, users previously authenticating with passwords sent as cleartext SHOULD be required to change those passwords when migrating to TLS, since the old passwords were likely to have been compromised. > > Transition of users from SSL or TLS 1.0 to later versions of TLS MAY > be accomplished by a means similar to that described above. There > are multiple ways to accomplish this. One way is for the server to > refuse a ClientHello message from any client sending a protocol > version number corresponding to any version of SSL or TLS 1.0. > > I don't think this is quite right: my understanding is that client can > send such versions (for backward compatibility), but end up > negotiating TLS 1.2. The version number that the client sends in ClientHello is the /maximum/ version number that the client will support. The server is free to offer a lower version number in its ServerHello response, which the client can accept (by continuing the session) or reject (by closing it). > So the advice here should be that neither the server nor the client > can negotiate SSL 2.0/TLS 1.0. Even SSL 2.0 is better than cleartext. It just doesn't meet minimum confidentiality requirements. If the MUA's configuration for that account doesn't impose minimum confidentiality requirements, the MUA is free to accept a ServerHello message offering an obsolete and insecure protocol version, because it would have presumably accepted cleartext anyway. The MUA just shouldn't represent to the user that that connection is secure. > Another way is for the server to accept ClientHello messages from > some client versions that it does not wish to support, but later > refuse to allow the user to authenticate. The latter method may > provide a better indication to the user of the reason for the failure > but (depending on the protocol and method of authentication used) may > also risk exposure of the user's password over an channel which is > known to not provide adequate confidentiality. > > > 5.2. Minimum Confidentiality Level > > MUAs SHOULD NOT allow users to "click through" to access or send mail > > It is not clear to me whether you are recommending better UI or a UI > that doesn't allow the user to bypass this? The intent is that the MUA shouldn't offer a popup or similar dialog to allow a user to /easily/ bypass the account's minimum confidentiality requirements. It's too easy to do this by accident, or without the user reading or understanding the MUA's description of the situation. And often, it's not just a few email messages that are compromised by doing so - it's the user's credentials and by extension all of the user's saved and future email, and potentially also any other resources that use that same password. So it's a big deal. If the user wants to reconfigure a mail account to not impose the minimum confidentiality requirement, that's up to the user, but "click through" is just a Bad Idea. > > via an connection, or to authenticate to any service using a > password, if that account is configured to impose minimum > confidentiality requirements and that connection does not meet all of > those requirements. Experience indicates that users presented with > such an option often "click through" without understanding the risks > that they're accepting by doing so. > > 5.4. Certificate Pinning > > A pinned certificate is subject to a man-in-the-middle attack at > account setup time, and lacks a mechanism to revoke or securely > refresh the certificate. > > Isn't this a MUA UI issue? I.e., a MUA may allow users to manage > pinned certificates. Use of pinned certs isn't forbidden by the draft, but pinned certs don't meet minimum confidentiality requirements. I think it might be possible to adequately address the security concerns associated with the usual implementation of pinned certificates, but working though the details seems beyond the scope of this document. > > 5.5. Client Certificate Authentication > > MUAs MAY implement client certificate authentication on the Implicit > TLS port. An MUA MUST NOT provide a client certificate during the > > "MUST NOT" sounds too strong. Why? > > TLS handshake unless the server requests one and the client has > determined the certificate can be safely used with that specific > server, OR the client has been explicitly configured by the user to > use that particular certificate with that server. How to make this > determination is presently implementation specific. I think this is Chris' text, so I'll let him answer. I do seem to recall from long ago that TLS 1.0 at least had a flaw that if a client has multiple certs it could potentially use, the protocol gives the client no idea as to which of those certs to use - and presumably only one will work. If the client presents the wrong one, the AUTH EXTERNAL could fail, and the client wouldn't know why. So the client requires specific configuration to know which certificate to use with which server. Forgive me for not knowing this off the top of my head, but was this flaw ever fixed? > > 8. Security Considerations > > It could be argued that sharing the name and version of the client > software with the server has privacy implications. > > You should probably mention IMAP ID extension (RFC 2971) here, as well > as other known mechanisms. I think this text may be left over from the STS stuff, so maybe we don't need it anymore. Keith --------------14CB9051195B4CA9A14CE11A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Alexey,

Thanks for the review!  Some responses:


On 07/24/2017 12:04 PM, Alexey Melnikov wrote:
I am generally very pleased with -07 and -08.

A few minor comments:

1.  Introduction

   This memo does not address use of TLS with SMTP for message relay
   (where Message Submission [RFC6409] does not apply).  Improved use of
   TLS with SMTP for message relay requires a different approach. One
   approach to address that topic is described in [RFC7672].

I think you should also reference MTA STS draft informatively here.

I'm personally okay with doing that.

4.1.  Deprecation of Services Using Cleartext and TLS Versions < 1.1

   The specific means employed for deprecation of cleartext Mail Access
   Services and Mail Submission Services this MAY vary from one MSP to

Extraneous "this" above.

   the next in light of their user communities' needs and constraints.


Later in the same section:

   Also, users authenticating with passwords SHOULD be required to
   change those passwords when migrating from cleartext to TLS, since
   the old passwords were likely to have been compromised.

Not necessarily true with something like SCRAM or GSSAPI (if PLAIN is also disabled), but I don't know how to word this better. I.e. authentication might still not expose the password without TLS.

How about:

Also, users previously authenticating with passwords sent as cleartext SHOULD be required to change those passwords when migrating to TLS, since the old passwords were likely to have been compromised.


   Transition of users from SSL or TLS 1.0 to later versions of TLS MAY
   be accomplished by a means similar to that described above. There
   are multiple ways to accomplish this.  One way is for the server to
   refuse a ClientHello message from any client sending a protocol
   version number corresponding to any version of SSL or TLS 1.0.

I don't think this is quite right: my understanding is that client can send such versions (for backward compatibility), but end up negotiating TLS 1.2.

The version number that the client sends in ClientHello is the maximum version number that the client will support.   The server is free to offer a lower version number in its ServerHello response, which the client can accept (by continuing the session) or reject (by closing it).

So the advice here should be that neither the server nor the client can negotiate SSL 2.0/TLS 1.0.

Even SSL 2.0 is better than cleartext.   It just doesn't meet minimum confidentiality requirements.  If the MUA's configuration for that account doesn't impose minimum confidentiality requirements, the MUA is free to accept a ServerHello message offering an obsolete and insecure protocol version, because it would have presumably accepted cleartext anyway.    The MUA just shouldn't represent to the user that that connection is secure.
   Another way is for the server to accept ClientHello messages from
   some client versions that it does not wish to support, but later
   refuse to allow the user to authenticate.  The latter method may
   provide a better indication to the user of the reason for the failure
   but (depending on the protocol and method of authentication used) may
   also risk exposure of the user's password over an channel which is
   known to not provide adequate confidentiality.


5.2.  Minimum Confidentiality Level

   MUAs SHOULD NOT allow users to "click through" to access or send mail

It is not clear to me whether you are recommending better UI or a UI that doesn't allow the user to bypass this?

The intent is that the MUA shouldn't offer a popup or similar dialog to allow a user to easily bypass the account's minimum confidentiality requirements.   It's too easy to do this by accident, or without the user reading or understanding the MUA's description of the situation.  And often, it's not just a few email messages that are compromised by doing so - it's the user's credentials and by extension all of the user's saved and future email, and potentially also any other resources that use that same password.   So it's a big deal.

If the user wants to reconfigure a mail account to not impose the minimum confidentiality requirement, that's up to the user, but "click through" is just a Bad Idea.


   via an connection, or to authenticate to any service using a
   password, if that account is configured to impose minimum
   confidentiality requirements and that connection does not meet all of
   those requirements.  Experience indicates that users presented with
   such an option often "click through" without understanding the risks
   that they're accepting by doing so.

5.4.  Certificate Pinning

   A pinned certificate is subject to a man-in-the-middle attack at
   account setup time, and lacks a mechanism to revoke or securely
   refresh the certificate.

Isn't this a MUA UI issue? I.e., a MUA may allow users to manage pinned certificates.

Use of pinned certs isn't forbidden by the draft, but pinned certs don't meet minimum confidentiality requirements.

I think it might be possible to adequately address the security concerns associated with the usual implementation of pinned certificates, but working though the details seems beyond the scope of this document.


5.5.  Client Certificate Authentication

   MUAs MAY implement client certificate authentication on the Implicit
   TLS port.  An MUA MUST NOT provide a client certificate during the

"MUST NOT" sounds too strong. Why?

   TLS handshake unless the server requests one and the client has
   determined the certificate can be safely used with that specific
   server, OR the client has been explicitly configured by the user to
   use that particular certificate with that server.  How to make this
   determination is presently implementation specific.

I think this is Chris' text, so I'll let him answer.  

I do seem to recall from long ago that TLS 1.0 at least had a flaw that if a client has multiple certs it could potentially use, the protocol gives the client no idea as to which of those certs to use - and presumably only one will work.   If the client presents the wrong one, the AUTH EXTERNAL could fail, and the client wouldn't know why.   So the client requires specific configuration to know which certificate to use with which server.  

Forgive me for not knowing this off the top of my head, but was this flaw ever fixed?


8.  Security Considerations

   It could be argued that sharing the name and version of the client
   software with the server has privacy implications.

You should probably mention IMAP ID extension (RFC 2971) here, as well as other known mechanisms.

I think this text may be left over from the STS stuff, so maybe we don't need it anymore.

Keith
--------------14CB9051195B4CA9A14CE11A-- From nobody Mon Jul 24 23:56: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 3F4F8126DC2 for ; Mon, 24 Jul 2017 23:56:13 -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 S6C9BYE3TMmm for ; Mon, 24 Jul 2017 23:56:11 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 725DA1200F3 for ; Mon, 24 Jul 2017 23:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500965770; d=isode.com; s=june2016; i=@isode.com; bh=Nv4PkQC8pJbuIGg6uXOlOS8pzA4vEVQte1lR04nM0aI=; 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=YUBcEU/Q7BvpM5dwI1/9PtPxfIb8v0DpnjFzDH9ttP53236ViPx1JxDnMESE7B7ZA8+gTG rj3tseyjYB6CHIacMZqo8d+s81J950b8/4+4gFWeQH9RrsCnCWPpqRrhBOa3zcv7MVx9Jm uBIH3tHwdUpUpJjILdWcPWu7ZOj5F3M=; Received: from [192.168.0.3] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 25 Jul 2017 07:56:10 +0100 To: Keith Moore , uta@ietf.org References: From: Alexey Melnikov Message-ID: <5976EB8A.9090802@isode.com> Date: Tue, 25 Jul 2017 07:56:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Uta] Review of draft-ietf-uta-email-deep-08 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 Jul 2017 06:56:13 -0000 Hi Keith, Quickly answering to a few easy ones: On 25/07/2017 05:18, Keith Moore wrote: > Hi Alexey, >=20 > Thanks for the review! Some responses: >=20 >=20 > On 07/24/2017 12:04 PM, Alexey Melnikov wrote: >> I am generally very pleased with -07 and -08. >> >> A few minor comments: >> >> 1. Introduction >> >> This memo does not address use of TLS with SMTP for message relay >> (where Message Submission [RFC6409] does not apply). Improved use of >> TLS with SMTP for message relay requires a different approach. One >> approach to address that topic is described in [RFC7672]. >> >> I think you should also reference MTA STS draft informatively here. >=20 > I'm personally okay with doing that. That would be great. >> 4.1. Deprecation of Services Using Cleartext and TLS Versions < 1.1 >> >> The specific means employed for deprecation of cleartext Mail Access >> Services and Mail Submission Services this MAY vary from one MSP to >> >> Extraneous "this" above. >> >> the next in light of their user communities' needs and constraints. >> >> >> Later in the same section: >> >> Also, users authenticating with passwords SHOULD be required to >> change those passwords when migrating from cleartext to TLS, since >> the old passwords were likely to have been compromised. >> >> Not necessarily true with something like SCRAM or GSSAPI (if PLAIN is >> also disabled), but I don't know how to word this better. I.e. >> authentication might still not expose the password without TLS. >=20 > How about: >=20 > Also, users previously authenticating with passwords sent as cleartext > SHOULD be required to change those passwords when migrating to TLS, > since the old passwords were likely to have been compromised. This looks good to me. (snip) >> 5.2. Minimum Confidentiality Level >> >> MUAs SHOULD NOT allow users to "click through" to access or send mail >> >> It is not clear to me whether you are recommending better UI or a UI >> that doesn't allow the user to bypass this? >=20 > The intent is that the MUA shouldn't offer a popup or similar dialog to > allow a user to /easily/ bypass the account's minimum confidentiality > requirements. It's too easy to do this by accident, or without the > user reading or understanding the MUA's description of the situation.=20 > And often, it's not just a few email messages that are compromised by > doing so - it's the user's credentials and by extension all of the > user's saved and future email, and potentially also any other resources > that use that same password. So it's a big deal. I agree with you. I just think that the text might need a bit clarification. > If the user wants to reconfigure a mail account to not impose the > minimum confidentiality requirement, that's up to the user, but "click > through" is just a Bad Idea. >=20 >> >> via an connection, or to authenticate to any service using a >> password, if that account is configured to impose minimum >> confidentiality requirements and that connection does not meet all of >> those requirements. Experience indicates that users presented with >> such an option often "click through" without understanding the risks >> that they're accepting by doing so. >> >> 5.4. Certificate Pinning >> >> A pinned certificate is subject to a man-in-the-middle attack at >> account setup time, and lacks a mechanism to revoke or securely >> refresh the certificate. >> >> Isn't this a MUA UI issue? I.e., a MUA may allow users to manage >> pinned certificates. >=20 > Use of pinned certs isn't forbidden by the draft, but pinned certs don't > meet minimum confidentiality requirements. >=20 > I think it might be possible to adequately address the security concerns > associated with the usual implementation of pinned certificates, but > working though the details seems beyond the scope of this document. Ok, how about inserting "typically" before "lacks a mechanism to revoke ...". This way you are making an observation about state of UIs without sounding like it is a fact of nature. Best Regards, Alexey From nobody Tue Jul 25 04:07: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 44C05131BBF for ; Tue, 25 Jul 2017 04:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 EAgQp-5Lw5wi for ; Tue, 25 Jul 2017 04:07:52 -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 B355F126E3A for ; Tue, 25 Jul 2017 04:07:52 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1C22020B50; Tue, 25 Jul 2017 07:07:52 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 25 Jul 2017 07:07:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=jmb9UTB9x4W56DxfQD 1/sQTRR+It9hlrz09RM13dl1o=; b=UZnNxz9hnHjouj0YK74W7/lXuQLjbFFJoY OEzww97tTH9PQZaXVeE8N2pODD8z9F1boU3BBJkFYRGmxfakUckbzi5h4uF8yOPx R/kNs5J5o6OIdnbjlUh9Y1FFsk3ESL0SWEAN2zISlJZQdQ0G/jEhKxVdwHJ7ZFjZ mApxZ4fzQEp79W+xrbytKXy43VTsthxqY48hYtIGlY4C3Nrt4LbBvrRKysXmUGm3 jvcVXPatpXHy06sGWVniDpr1oHXO1aiExMihyk2U90mFnL8Gk//6d6jJ5qHMDrzJ XkcwOftw9GUQlGb99KNMr7no5EcBxB8Bo/wVBwi8dJCvNExOTR9Q== X-ME-Sender: X-Sasl-enc: Y2tn/GEoDmAs71R5xc5RsHOLUHZS9ZHA+qSUGtU/sIpz 1500980871 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 A71777E1D0; Tue, 25 Jul 2017 07:07:51 -0400 (EDT) To: uta@ietf.org, Alexey Melnikov References: <5976EB8A.9090802@isode.com> From: Keith Moore Message-ID: <808a8977-a309-c187-6070-ed8a9ed81365@network-heretics.com> Date: Tue, 25 Jul 2017 07:07:51 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5976EB8A.9090802@isode.com> Content-Type: multipart/alternative; boundary="------------BE0EEBC6D4F56E2DDA4D01CA" Content-Language: en-US Archived-At: Subject: Re: [Uta] Review of draft-ietf-uta-email-deep-08 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 Jul 2017 11:07:54 -0000 This is a multi-part message in MIME format. --------------BE0EEBC6D4F56E2DDA4D01CA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 07/25/2017 02:56 AM, Alexey Melnikov wrote: >> Use of pinned certs isn't forbidden by the draft, but pinned certs don't >> meet minimum confidentiality requirements. >> >> I think it might be possible to adequately address the security concerns >> associated with the usual implementation of pinned certificates, but >> working though the details seems beyond the scope of this document. > Ok, how about inserting "typically" before "lacks a mechanism to revoke > ...". This way you are making an observation about state of UIs without > sounding like it is a fact of nature. I'm thinking more along the lines of "there is currently no protocol defined for revocation of a pinned certificate". TOFU isn't entirely good or evil, though it does provide a vulnerability that will certainly be exploited. (We're creating a similar vulnerability by encouraging use of unsigned SRV records to dictate account configuration parameters, which seems hard to fix at the moment given how hard it is to deploy DNSSEC. Maybe DNS-over-TLS will emerge as a way to double-check the validity of those SRV records.) Keith --------------BE0EEBC6D4F56E2DDA4D01CA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 07/25/2017 02:56 AM, Alexey Melnikov wrote:
Use of pinned certs isn't forbidden by the draft, but pinned certs don't
meet minimum confidentiality requirements.

I think it might be possible to adequately address the security concerns
associated with the usual implementation of pinned certificates, but
working though the details seems beyond the scope of this document.

Ok, how about inserting "typically" before "lacks a mechanism to revoke
...". This way you are making an observation about state of UIs without
sounding like it is a fact of nature.
I'm thinking more along the lines of "there is currently no protocol defined for revocation of a pinned certificate".

TOFU isn't entirely good or evil, though it does provide a vulnerability that will certainly be exploited.  (We're creating a similar vulnerability by encouraging use of unsigned SRV records to dictate account configuration parameters, which seems hard to fix at the moment given how hard it is to deploy DNSSEC.   Maybe DNS-over-TLS will emerge as a way to double-check the validity of those SRV records.)

Keith

--------------BE0EEBC6D4F56E2DDA4D01CA-- From nobody Tue Jul 25 12:14: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 BFC0712EB8C for ; Tue, 25 Jul 2017 12:14:28 -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=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfFk7kXXqP1c for ; Tue, 25 Jul 2017 12:14:26 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93094127136 for ; Tue, 25 Jul 2017 12:14:26 -0700 (PDT) Received: from [IPv6:2601:647:5500:1330:c14:37dd:e60:5ff1] ([IPv6:2601:647:5500:1330:c14:37dd:e60:5ff1]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v6PJEMT3014062 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 25 Jul 2017 12:14:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1501010065; bh=7kQa4hhLecnQODvSjwB5psH7jGnUTnwJCFu7tJkWKcs=; h=Subject:To:References:From:Date:In-Reply-To; b=LygdAWA24ch1nsBzopYKQ0/n4lAO09oF4yZV0oXoLaApoOvmVBY/gZXSztW3EJHU/ D+bJQkpekFIzF4X+MfocItl/YW/4ukxpZUt4kyx6nQmljy5K7Cqfj5NqzpVrFfv99Z 0JdQLEpj8ouOsXErglLYIdTJukjjsSY8L44bhknc= To: "Rolf E. Sonneveld" , Leif Johansson , uta@ietf.org References: <06bffe72-9d6a-0225-2fcd-bb306396b682@sunet.se> From: Jim Fenton Message-ID: <77acaa67-761f-a4c7-3aac-af77c90f70ec@bluepopcorn.net> Date: Tue, 25 Jul 2017 12:14:17 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F8F26DD77EA2CDC1C0207FC3" Content-Language: en-US Archived-At: Subject: Re: [Uta] adopt draft-fenton-smtp-require-tls-03 as WG document 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 Jul 2017 19:14:29 -0000 This is a multi-part message in MIME format. --------------F8F26DD77EA2CDC1C0207FC3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Rolf, thanks very much for your review, including the nitpicking. Responses to a few items below. On 07/22/2017 02:57 PM, Rolf E. Sonneveld wrote: > > Page 4: > > this option MUST only be specified in the context > of an SMTP session meeting the security requirements that have been > specified: > > Just for reasons of clarity, you might add a third bullet, which > describes what already was mentioned earlier: > > - the SMTP server advertises that it supports REQUIRETLS. No harm in including that, but I think it's already required by RFC 5321 (see below). > > Page 5: > > 3. Establish a TLS-protected SMTP session with its peer SMTP server= > and authenticate the server's certificate with the specified > authentication method. > > you may want to add a reference to RFC6125 here. Good idea, but I notice that RFC6125 doesn't seem to cover DANE verification. Should it also reference a DANE counterpart? Is RFC6698 the right one to use? > > Page 6: > > Following such a failure, the SMTP client MUST send a non-delivery > notification to the reverse-path of the failed messag > > Reading this paragraph it seems there is no room for a client to > postpone the decision to send a NDN, for example in case of a DNS > tempfail. This is outside the loop (steps 1-4 earlier in Section3.2.1) of trying all of the individual MX hosts and trying to negotiate an acceptable connection with each. I expect any handling of tempfails would happen inside that loop. Is there another tempfail possibility at this level? > > Page 6: > > o If the server does not advertise the REQUIRETLS capability, send > the message in the usual manner (without the REQUIRETLS option, > because the server will not understand the option). > > There are circumstances where a middlebox may remove the REQUIRETLS > advertisement and for these cases (in combination with REQUIRETLS=3DNO)= > it might still be useful to send the MAIL FROM with the REQUIRETLS > option in order to convey the wish of the sender to send using a TLS > encrypted channel. Comments? RFC5321 Section 4.1.1.2 (MAIL command) says: "If service extensions were negotiated, the MAIL command may also carry parameters associated with a particular service extension." which I read to say that one shouldn't (mustn't?) include parameters for service extensions that weren't negotiated. It isn't as strong as 4.1.1.3 (RCPT command) which additionally says: "The client MUST NOT transmit parameters other than those associated with a service extension offered by the server in its EHLO response." but I would still be concerned about adding a parameter to the MAIL command that might interfere with interoperability. > > Page 7: > > Mail delivery agents supporting REQUIRETLS SHOULD require that > retrieval of messages requiring transport encryption take place over= > authenticated, encrypted channels. > > AFAIK there is no mechanism where an MDA could require this from the > Mail Access Server. Unless you mean the MDA should set some sort of > flag, which then can be honored by the mail access server? An easy way to satisfy this requirement is just to use authenticated, encrypted channels all the time (ala DEEP). There's no reason I can think of not to do this. > > Page 8: > > REQUIRETLS users SHOULD use caution > when sending to mailing lists and MUST NOT assume that REQUIRETLS > applies to messages from the list operator to list members. > > Usually, users clicking on a 'Require encryption' button will not read > this RFC and often do not even know whether a To: or Cc: mail address > they use is a mailing list with specific characteristics. So I wonder > if this line in the draft should better address the owner of the > domain, recommending to educate their users not too expect (end2end) > encryption in all cases. It's not end2end anyway, and users need to be aware of that too. But which domain do you mean the owner of? The domain of the mailing list, or that of the sending user? One could also argue that the vendor of an MUA with a "require encryption" button should provide information on its limitations. I'll reword that the user should be made aware so it doesn't seem like the user has the only responsibility here. > > Par. 7: > > I wonder if a fourth attack vector should be mentioned: a DOS type of > attack where an attacker uses REQUIRETLS, using the RFC5321.MailFrom > address of a victim (using an MTA supporting REQUIRETLS) and sending > messages to as many MTA's-not-supporting-REQUIRETLS it can find, > resulting in a bombardment of the victim with NDN's. However, this > type of DOS attack can be achieved already in other ways, so I think > it need not be mentioned. Yes, there are so many easier ways to do this I don't think this adds a significant additional threat. Again, thanks for your review. -Jim --------------F8F26DD77EA2CDC1C0207FC3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Rolf, thanks very much for your review, including the nitpicking. Responses to a few items below.

On 07/22/2017 02:57 PM, Rolf E. Sonneveld wrote:

Page 4:

this option MUST only be specified in the context
   of an SMTP session meeting the security requirements that have been
   specified:

Just for reasons of clarity, you might add a third bullet, which describes what already was mentioned earlier:

- the SMTP server advertises that it supports REQUIRETLS.

No harm in including that, but I think it's already required by RFC 5321 (see below).

Page 5:

   3.  Establish a TLS-protected SMTP session with its peer SMTP server
       and authenticate the server's certificate with the specified
       authentication method.

you may want to add a reference to RFC6125 here.

Good idea, but I notice that RFC6125 doesn't seem to cover DANE verification. Should it also reference a DANE counterpart? Is RFC6698 the right one to use?


Page 6:

   Following such a failure, the SMTP client MUST send a non-delivery
   notification to the reverse-path of the failed messag

Reading this paragraph it seems there is no room for a client to postpone the decision to send a NDN, for example in case of a DNS tempfail.

This is outside the loop (steps 1-4 earlier in Section3.2.1) of trying all of the individual MX hosts and trying to negotiate an acceptable connection with each. I expect any handling of tempfails would happen inside that loop. Is there another tempfail possibility at this level?


Page 6:

   o  If the server does not advertise the REQUIRETLS capability, send
      the message in the usual manner (without the REQUIRETLS option,
      because the server will not understand the option).

There are circumstances where a middlebox may remove the REQUIRETLS advertisement and for these cases (in combination with REQUIRETLS=NO) it might still be useful to send the MAIL FROM with the REQUIRETLS option in order to convey the wish of the sender to send using a TLS encrypted channel. Comments?

RFC5321 Section 4.1.1.2 (MAIL command) says:
"If service extensions were negotiated, the MAIL command may also carry parameters associated with a particular service extension."

which I read to say that one shouldn't (mustn't?) include parameters for service extensions that weren't negotiated. It isn't as strong as 4.1.1.3 (RCPT command) which additionally says:
"The client MUST NOT transmit parameters other than those associated with a service extension offered by the server in its EHLO response."

but I would still be concerned about adding a parameter to the MAIL command that might interfere with interoperability.


Page 7:

   Mail delivery agents supporting REQUIRETLS SHOULD require that
   retrieval of messages requiring transport encryption take place over
   authenticated, encrypted channels.

AFAIK there is no mechanism where an MDA could require this from the Mail Access Server. Unless you mean the MDA should set some sort of flag, which then can be honored by the mail access server?

An easy way to satisfy this requirement is just to use authenticated, encrypted channels all the time (ala DEEP). There's no reason I can think of not to do this.


Page 8:

REQUIRETLS users SHOULD use caution
   when sending to mailing lists and MUST NOT assume that REQUIRETLS
   applies to messages from the list operator to list members.

Usually, users clicking on a 'Require encryption' button will not read this RFC and often do not even know whether a To: or Cc: mail address they use is a mailing list with specific characteristics. So I wonder if this line in the draft should better address the owner of the domain, recommending to educate their users not too expect (end2end) encryption in all cases.

It's not end2end anyway, and users need to be aware of that too.

But which domain do you mean the owner of? The domain of the mailing list, or that of the sending user? One could also argue that the vendor of an MUA with a "require encryption" button should provide information on its limitations. I'll reword that the user should be made aware so it doesn't seem like the user has the only responsibility here.


Par. 7:

I wonder if a fourth attack vector should be mentioned: a DOS type of attack where an attacker uses REQUIRETLS, using the RFC5321.MailFrom address of a victim (using an MTA supporting REQUIRETLS) and sending messages to as many MTA's-not-supporting-REQUIRETLS it can find, resulting in a bombardment of the victim with NDN's. However, this type of DOS attack can be achieved already in other ways, so I think it need not be mentioned.

Yes, there are so many easier ways to do this I don't think this adds a significant additional threat.

Again, thanks for your review.

-Jim

--------------F8F26DD77EA2CDC1C0207FC3-- From nobody Mon Jul 31 09:04:24 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C7E131723 for ; Mon, 31 Jul 2017 09:04:16 -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 3mSVtjtXxT99 for ; Mon, 31 Jul 2017 09:04:14 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 6A00B13256B for ; Mon, 31 Jul 2017 09:04:14 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id v127so128781705itd.0 for ; Mon, 31 Jul 2017 09:04: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; bh=0op67mF9iY9GYdpHGDTUU5sB3EmGKV8g7JoBqxM4HsE=; b=siUAfNNNeW1OGRmqr9S+u3Op2FNvBig4oAlk7+QAij+ZMhNqpRXrIZlyB/89sd1UGJ /OkEjowxoZKNeOJkG+TGgOp/Mmp4pZjmyGfNFMpiobPTDTV/7Ga19dc8ATynSlwqto7J nVNdhP6omJQeKIwc8pcN3HAdTQ+LwhS18cG/9T0qWmht6Hz/U04N3kiXQ8EM5wBEvfFe +y1hjKFkNmIfWY3/HbCpcpO4WSEy+2c6yVrpNlHHWwSCMkoD/IFk/ao3X7Nm7FTbA7dj 3nLNj5bHxulbVYi4t0wvV3bkE+XNR7ui35HP3oe9xItG8zPWSQLAsRrV9D74V+nenWpm q/hQ== 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=0op67mF9iY9GYdpHGDTUU5sB3EmGKV8g7JoBqxM4HsE=; b=Bq1Fj8i4kAoqsDyat0Wwi6gIHf6ue9l+yaImqQfqbjmr+bDDShbQSWJyoh0jVXF9L7 tP3esZIjBQmz/pBtGOHCf+mw0NxcaSzInIaoPgSAgN4oTRJgkXTlTdvKjfABfD7+Rih7 DYxjpxkYtOZ+RIDFd6q7XZK8zR6EA2DE88LNfCBOnWjpsKZedjvLdQgi1jmBfr8wit1P a5YgRz/bzSlbY3vizWsOAAH8THrpzbOk1YLHiGxZUCbJpd4R3q5dRAmsRET8MFPnNjFP dPfh2Tkx15VeZFCyXlkayJRIxk2VJlvgvfrswhm71vNOUqJS1s6vHMtPmQlDWvwIr7Zs oyHQ== X-Gm-Message-State: AIVw112LdrHmPRcGZaKPBRgXxwkR80eS5jij8fyBFtDHZXH/Bg5hBm6Y Z0J18QbTZhFWE9MBdX/p2cZHQLH4ighnbqo= X-Received: by 10.36.170.7 with SMTP id b7mr16723105itf.10.1501517053131; Mon, 31 Jul 2017 09:04:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.159 with HTTP; Mon, 31 Jul 2017 09:04:12 -0700 (PDT) In-Reply-To: <20170721151927.GZ8146@mournblade.imrryr.org> References: <9A41D7B1-4D4C-4605-8161-7985E30B1044@oracle.com> <20170721151927.GZ8146@mournblade.imrryr.org> From: Daniel Margolis Date: Mon, 31 Jul 2017 12:04:12 -0400 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045fba249b0eeb05559f2ef1" Archived-At: Subject: Re: [Uta] review of draft-ietf-uta-mta-sts-07 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, 31 Jul 2017 16:04:16 -0000 --f403045fba249b0eeb05559f2ef1 Content-Type: multipart/alternative; boundary="f403045fba24941d0c05559f2e07" --f403045fba24941d0c05559f2e07 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 21, 2017 at 11:19 AM, Viktor Dukhovni wrote: > On Thu, Jul 20, 2017 at 06:02:00PM +0200, Chris Newman wrote: > > > Connect to https server at mta-sts.example.com (mta-sts host in policy > > domain). [section reference] > > ... > > This sort of thing was supposed to be covered in the state machine > description at the end... > I thought it was covered by that. Like I said above, I'm happy to introduce bigger changes, but I'd want more specific feedback and broader feedback from the rest of the WG due to the fairly late stage of the draft. > > > 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 below), chain to a root CA that is trusted by the > > > > After reading the document, I'm not sure I understand how to construct > the > > DNS FQDN that I need to pass to the TLS API in order to validate the > mta-sts > > host. In the example workflow above, I made a guess. But the document > > presently never says how to construct the FQDN explicitly. > > There is no single FQDN. The certificate is matched against any > of the names in the "mx" attribute. The SNI should be taken from > the MX hostname. > I think you are talking about two different things. Chris is referencing the validation requirement when fetching the policy, not for the MX host validation itself. In the former case, the validation should be against the "mta-sts" host at the target domain (so the FQDN is "mta-sts.example.com" or whatever); the latter case as Viktor described. I think Chris's confusion was over whether "'mta-sts' host" refers to the hostname (it does) or is a term of art referring to some specific host, and, if so, what is the identity to validate. Rephrasing this to something like, "which is valid for the 'mta-sts' host at the policy domain, e.g. ' mta-sts.example.com'" would probably clear that up. :) > > > > The certificate MAY be checked for revocation via the Online > > > Certificate Status Protocol (OCSP) [RFC2560], certificate revocation > > > lists (CRLs), or some other mechanism. > > > > Is there a reason this is a MAY rather than a SHOULD? > > Postfix will not implement either CRL checks (reliably maintained > CRLs are an exotic beast) or OCSP. We could implement support for > stapled OCSP, but I am not aware of much support for that on the > server side. > Right. I expect widespread non-adoption of such a SHOULD, but maybe it's worth instead calling it out in Security Considerations. --f403045fba24941d0c05559f2e07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 21, 2017 at 11:19 AM, Viktor Dukhovni <= ;ietf-dane@dukh= ovni.org> wrote:
On Thu, Jul 20, 2017 at 06:02:00PM +0200, Chris Newman wrote:

> Connect to https server at mta-sts.example.com (mta-sts host in = policy
> domain). [section reference]
> ...

This sort of thing was supposed to be covered in the state machine
description at the end...

I thought it = was covered by that. Like I said above, I'm happy to introduce bigger c= hanges, but I'd want more specific feedback and broader feedback from t= he rest of the WG due to the fairly late stage of the draft.=C2=A0
=C2=A0
> >=C2=A0 =C2=A0When fetching a new policy or updating a policy, the = HTTPS endpoint
> >=C2=A0 =C2=A0MUST present a X.509 certificate which is valid for t= he "mta-sts"
> >=C2=A0 =C2=A0host (as described below), chain to a root CA that is= trusted by the
>
> After reading the document, I'm not sure I understand how to const= ruct the
> DNS FQDN that I need to pass to the TLS API in order to validate the m= ta-sts
> host. In the example workflow above, I made a guess. But the document<= br> > presently never says how to construct the FQDN explicitly.

There is no single FQDN.=C2=A0 The certificate is matched against an= y
of the names in the "mx" attribute.=C2=A0 The SNI should be taken= from
the MX hostname.

I think you are talkin= g about two different things. Chris is referencing the validation requireme= nt when fetching the policy, not for the MX host validation itself. In the = former case, the validation should be against the "mta-sts" host = at the target domain (so the FQDN is "mta-sts.example.com" or whatever); the latter case as Vikto= r described.=C2=A0

I think Chris's confusion w= as over whether "'mta-sts' host" refers to the hostname (= it does) or is a term of art referring to some specific host, and, if so, w= hat is the identity to validate. Rephrasing this to something like,

"which is valid for the 'mta-sts' host at th= e policy domain, e.g. 'mta-sts.e= xample.com'"

would probably clear tha= t up. :)
=C2=A0

> >=C2=A0 =C2=A0The certificate MAY be checked for revocation via the= Online
> >=C2=A0 =C2=A0Certificate Status Protocol (OCSP) [RFC2560], certifi= cate revocation
> >=C2=A0 =C2=A0lists (CRLs), or some other mechanism.
>
> Is there a reason this is a MAY rather than a SHOULD?

Postfix will not implement either CRL checks (reliably maintained CRLs are an exotic beast) or OCSP.=C2=A0 We could implement support for
stapled OCSP, but I am not aware of much support for that on the
server side.

Right. I expect widespread= non-adoption of such a SHOULD, but maybe it's worth instead calling it= out in Security Considerations.=C2=A0
=C2=A0
--f403045fba24941d0c05559f2e07-- --f403045fba249b0eeb05559f2ef1 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 K8x525biWylzaTdKMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBRWEpWYMO2NCjk yKtXF3wP04eVeP0PKhOtzstpVjQYjTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA3MzExNjA0MTNaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAK8lRDMW1WGtDtiiCfth1DTLnXJKzYMc1 eEW3yRbSK85vGujYBqu0o4d832qLsoKGS725Mzc3VJ8wu8pejnbm7Yz9ToQeG2ECol+2aPjo6CAE oLzfSVwjObZTXdEsH33V4K7G+BxAD5pb+5djA6oGgMMsrenwoDnAAw5f3NGZu71zf/6hrxOI2r9l UiUMGOmCa3bz6pZj7V5Z0fcxLvaddKU4vJZ2Ld0Z9h1FNKkEhDdChp7EE042v9JMyUNuH9q4BWE4 7Qc4gs0tDFBP8NJwHy3h0stvLbOcmVifJzDEDy6NBugdEmc5sKRW3LNHCIrK7svbB8YMw1z73D4F YyGnZg== --f403045fba249b0eeb05559f2ef1-- From nobody Mon Jul 31 10:33: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 1FFA213262A; Mon, 31 Jul 2017 10:33: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.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150152238107.6482.4251123985517531851@ietfa.amsl.com> Date: Mon, 31 Jul 2017 10:33:01 -0700 Archived-At: Subject: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-07.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: Mon, 31 Jul 2017 17:33: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 WG of the IETF. Title : SMTP TLS Reporting Authors : Daniel Margolis Alexander Brotman Binu Ramakrishnan Janet Jones Mark Risher Filename : draft-ietf-uta-smtp-tlsrpt-07.txt Pages : 23 Date : 2017-07-31 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-07 https://datatracker.ietf.org/doc/html/draft-ietf-uta-smtp-tlsrpt-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-tlsrpt-07 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 Mon Jul 31 10:35:23 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4933813262A for ; Mon, 31 Jul 2017 10:35:21 -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 clNdwj8qgZXu for ; Mon, 31 Jul 2017 10:35:20 -0700 (PDT) Received: from pacdcmhout02.cable.comcast.com (pacdcmhout02.cable.comcast.com [68.87.96.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890B0132725 for ; Mon, 31 Jul 2017 10:35:13 -0700 (PDT) X-AuditID: 4457600f-c5bfb7000000ac47-f5-597f6a4f3fda Received: from PACDCEX21.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by pacdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id D6.B1.44103.F4A6F795; Mon, 31 Jul 2017 13:35:12 -0400 (EDT) Received: from PACDCEX19.cable.comcast.com (24.40.1.142) by PACDCEX21.cable.comcast.com (24.40.1.144) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 31 Jul 2017 13:35:10 -0400 Received: from PACDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8304]) by PACDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8304%19]) with mapi id 15.00.1293.002; Mon, 31 Jul 2017 13:35:10 -0400 From: "Brotman, Alexander" To: "uta@ietf.org" Thread-Topic: Updated TLSRPT Draft (v07) Thread-Index: AdMKIxZs5cTgcopERLKSkTBgrKbKsg== Date: Mon, 31 Jul 2017 17:35:09 +0000 Message-ID: <24ecb63305ed43bc8ee0564d5cd18b69@PACDCEX19.cable.comcast.com> 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.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMKcWRmVeSWpSXmKPExsXiEq4koxuQVR9p8GKnjMWpo82MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK2DZhJmPBGuaKtVskGxjPMXUxcnJICJhIzJl3irWLkYtDSGAX k8SxNz9gHEaJNR8mM0E4JxklVl65zQLSwiZgJfH2fzsziC0ioCjx4s97dhBbWEBZov37HhaI uIbEkSt3WCFsPYnvE+aA1bAIqEp8+XGVDcTmFfCS6LvcBjaHUUBM4vupNWAnMQuIS9x6Mh/q PAGJJXvOM0PYohIvH/9jhbANJLYu3ccCYctLHJnwjwWiV0diwe5PbBC2tsSyha+ZIXYJSpyc +QSqXlzi8JEdrBMYRWchWTcLSfssJO2zkLQvYGRZxShXkJickpybkV9aYmCkl5yYlJOql5yf m5xYXAKiNzGC4ySBfwfj0ekehxgFOBiVeHh7AuojhVgTy4orcw8xZnMwKYnynpECCvEl5adU ZiQWZ8QXleakFiuJ8HLYAIV54cJJpTnZSlK8qzKBosJw0bzU8uKc1BJgIlCS4929vy5SSBwu V1xaXJCZnJlfWhxfWpRziFGCgxlorEU8yNiUxMqq1KJ8iGWHGKU5WJTEeYMSyiKFBNITS1Kz U1MLUotgsuUcHEoSvNIgmwWLUtNTK9Iyc0pg0kB97dJAGQFkGbBjZXnvugAlxJAlkNyryJu2 qDpSSApZGt3JTBychxjTOXiA7m5MA7m7uCAxtzgzHWq1MK9jOFCUByYKtlaS93IGUFAIJohk pSzvW1AQicGkUK07xTiRkaPpw5YvTBxbZm0FkmvW7/nCJMSSl5+XKiXO+xZkqgBIa0ZpHtz7 UmK8CoIVkUL8SBIgZ0jJ8PKBxEWRxBEukVLg/SAAlJVEkkV1DCxDv2JMBqYbYV5tUOjzALM7 wvdCvI9ATuKGCoI9L8H7DyQmCBVD8rsML9sBoN9FoTKotr0CBjITMJAlS2tBgVySWIIcyGUg UR6YKDSQ80GCQjBBlEAuB0mJwaRQbZJqYJxv4tf0xn7T73UZ+jEHz8rapb/k/3jNLbGi2Tgl gOM18/fet7t7HMwFDv7S88n1un7jbMzvRGvxzY92FTur1dxvO1jSNn+ZytebV5KDL/GtbRI0 8jxsn6tqY+X/yPzUa+fJbr2r7986cyssismj/VbwqwkLbj20WVQpkPRMc7OnY1rcgZmvFZVY ijMSDbWYi4oTAdlSMDBGBQAA Archived-At: Subject: [Uta] Updated TLSRPT Draft (v07) X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 17:35:21 -0000 Hello Folks, We attempted to incorporate the feedback from Alexey and Chris as best we c= ould, and we believe we have addressed each of their concerns either via th= e updated draft or via the mailing list. The period for the WGLC is nearly= over, and we wanted to try to provide an interim/updated draft for any fin= al review. Thank you for any comments. -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast From nobody Mon Jul 31 13:53:47 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF701327B9 for ; Mon, 31 Jul 2017 13:53:43 -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 (2048-bit key) header.d=jhcloos.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGEcJTY0RpIl for ; Mon, 31 Jul 2017 13:53:42 -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 6AD1E1326BB for ; Mon, 31 Jul 2017 13:53:42 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id ECAB31DF7C; Mon, 31 Jul 2017 20:53:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1501534421; bh=ylJmSenjoMYGPvf5mt/Z5/2CX0GqtZGXZP+16dzNXM8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VY3eoSGfnaoM4Vmh24eAtkfO74U5XMsRA1ylueKB52RRI+P632Meq3w6IxShMdrzN 8z+CBz970yQDhU5tpMXT22oUbXko8sylcp3kewKDG2Zzd1ltHO1KWqM5P9or2c1fXi yDq6nh6mg8pN8Gyas1NsJQI0fbZAIXgZVLh7uHugLofmxTyhxqwKcDZ2xOFldP/uqa zIurSD2o8+puJRZArVSVDFf5rjbGEdFT/MJe44vNp0ysFQuKfqZGRq95JWCv+EZVlK D5vDwNv3T7IQ+Fmgmhk1+vnhOIJBY7TyieDjdO5lX7bmkT+ezabTHvhsk8FwzRnpIx ykAuALQZ5BEtw== Received: by carbon.jhcloos.org (Postfix, from userid 500) id C3643107AC442; Mon, 31 Jul 2017 20:53:14 +0000 (UTC) From: James Cloos To: "Brotman\, Alexander" Cc: "uta\@ietf.org" In-Reply-To: <24ecb63305ed43bc8ee0564d5cd18b69@PACDCEX19.cable.comcast.com> (Alexander Brotman's message of "Mon, 31 Jul 2017 17:35:09 +0000") References: <24ecb63305ed43bc8ee0564d5cd18b69@PACDCEX19.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 2017 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 31 Jul 2017 16:53:14 -0400 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:170731:alexander_brotman@comcast.com::JaztpekY2svall/D:00000000000000000000000000000003egti X-Hashcash: 1:28:170731:"uta\@ietf.org"::Btlpcj5RvLIEL1rG:00pxL9 X-Hashcash: 1:28:170731:uta@ietf.org::0y48T5G9FER9as+p:00002MHMx Archived-At: Subject: Re: [Uta] Updated TLSRPT Draft (v07) X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 20:53:43 -0000 >>>>> "BA" == Brotman, Alexander writes: > we wanted to try to provide an interim/updated draft for any final review. Nit: it looks like the 'IPv4 Address is defined as' section is missing some newlines. Kudos on the switch to i-json. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Jul 31 16:02:19 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 7A7B21327F1 for ; Mon, 31 Jul 2017 16:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1cpk4aCn3l1 for ; Mon, 31 Jul 2017 16:02:17 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F5F129B55 for ; Mon, 31 Jul 2017 16:02:17 -0700 (PDT) Received: from splunge.local ([IPv6:2601:647:5500:1330:288e:a0fa:ad78:dce3]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v6VN2DBp013369 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 31 Jul 2017 16:02:16 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1501542136; bh=DICn/mz8jlsr4bD9Wqo/TnprtXIVeUv3F0u2wwG39TE=; h=Subject:To:References:From:Date:In-Reply-To; b=PQGhXo3CQv3Saq96eU3io0VA1Vw+d308wptxGOaGkWpn6FfkJkiSW4I1dsosNBvxx Y134BvYvyGG5x9YmVIWAgVbJuax6VKJkBZ4HRdZ87PWjlOhdMLmafpg1D7OhfMBsVh EVk1mo42fJPu/bNtbwFACqC0e8zOD1pS1YJmlWnk= To: uta@ietf.org References: From: Jim Fenton Message-ID: <2064af3c-c34b-c241-99b2-2af36342f603@bluepopcorn.net> Date: Mon, 31 Jul 2017 16:02:08 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 23:02:18 -0000 On 7/12/17 3:11 AM, Leif Johansson wrote: > This starts a 3 week working group last call (WGLC) on > draft-ietf-uta-smtp-tlsrpt-06. Please provide your comments to the list= > by Wednesday > August 2nd. General comments: All of the references are listed as normative, which I strongly suspect isn't really the case. Informative references need to be separated. As the document notes, the reference for MTA-STS needs to be added. If it is a normative reference, this document will be held up until that is published. Section 3, what happens in the case of HTTPS delivery of reports if there is some problem with the certificate presented by the server? For mailto:, it explicitly states that the message should be sent in the clear if necessary, but that doesn't seem to be the case with https:. Section 4.3.2.1, dnssec-invalid: In this case, would the TLSRPT policy be found? Section 5.1, I don't like the idea of associating semantics with the filename of MIME parts. As it's written, use of the specified filename format is optional, so the recipient can't depend on it anyway. DMARC does this, and I didn't like it there either, but it's an informational document so this may not have gotten all the scrutiny this should as a standards-track document. Section 5.3, I don't think it's a good idea to define and require new message header fields for this. This means that some of the general-purpose libraries for sending email messages can't be used. A better approach IMO would be to suggest the use of separate email addresses (e.g., reports@example.org or reports+client1@example.org for a service provider) in order to distinguish reports from other traffic. IANA considerations: Consider adding a request to register _smtp-tlsrpt in the registry being created by draft-ietf-dnsop-attrleaf if that registry is created before this is published. Section 7, Reports as DDoS: The discussion revolves around the fact that, unlike DMARC, there isn't a third party involved in a DMARC report so it isn't necessary to validate delegation. I'm not sure this completely alleviates the DDoS risk, though: it's equally possible for malicious second parties to overload the receiver with reports, or for malicious parties to look around for TLSRPT policies with mailto: addresses and just spam them. It might be good to acknowledge that possibility here. Also, the suggestion of sending the messages daily for 0000-2400 UTC (section 4.1) does not scale well, and may be a DDoS in itself. Section 7, additional consideration: The "untrusted content" consideration talks about malicious code, but attackers could also send counterfeit reports that look real in an effort to confuse the report recipient. Should valid DKIM signatures from the reporting domain be required on TLSRPT messages? Detailed comments and nits: 1.1 last bullet: initiating the delivery -> initiating the transmission 3. in tlsrpt-uri: [@!RFC3986] -> [RFC3986] What is the "numeric portion" that is referred to here? 4. bullet 2a "neither a TLSA nor MTA-STS policy" -> "neither a DANE nor MTA-STS policy" 5.1 "The filename is typically constructed": Is that a MAY? SHOULD? DMARC uses this wording, but it's informational. Following the ABNF, "json.gz": The IANA considerations section lists this is .gz. And the MUST here is confusing, is this only if the filename is 'typically constructed' or always? 5.3 The [RFC5322].Subject field for individual report submissions: There isn't an "individual" report defined here. Looks like this is left over from DMARC. 5.4 should use the media type -> SHOULD use the media type 5.5 should be on a logarithmic scale -> SHOULD be on a logarithmic scale (do MTAs typically do this, or is it calling for something special?) Sections 8 and 9 should be renumbered as appendices, and marked as informative examples. -Jim