From nobody Thu Feb 2 16:38:20 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 AA03F129A55 for ; Thu, 2 Feb 2017 16:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.2 X-Spam-Level: X-Spam-Status: No, score=-5.2 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=-3.199, 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 QUnwwiqhAFbk for ; Thu, 2 Feb 2017 16:38:13 -0800 (PST) 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 513D41299F1 for ; Thu, 2 Feb 2017 16:38:12 -0800 (PST) Received: from splunge.local (c-24-4-98-3.hsd1.ca.comcast.net [24.4.98.3]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v130cAV2018568 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 2 Feb 2017 16:38:12 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1486082292; bh=JJrvGL6oP+U5k/m4p8jdoGG3bTUluyNT+wQ4+RlrPVQ=; h=To:From:Subject:Date; b=AVOpTxoWXpSZMZB98YUmHesuZqg2sCMnZdbXyWlAYUtlH7+3wGjTvEL1pHgMzh4qa BcZy75JAkptjEjFQphpOmw2HCR+gtnzSIOamuLjzAJT3iTeEy6ImIHMCJcPoXBrg7F izKOwsy21s70QgCuVVofPcDr1xlvS0Va8zofPRxw= To: "uta@ietf.org" From: Jim Fenton Message-ID: <9f1d68ed-8826-dd4a-48c2-27b315c887fe@bluepopcorn.net> Date: Thu, 2 Feb 2017 16:38:05 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Uta] UTA meeting in Chicago? X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 00:38:15 -0000 Are there plans for a UTA WG meeting in Chicago? If so, I'd like an opportunity to present an update on REQUIRETLS, including recent updates to the spec (which I will have revised by then) and info on our initial interoperability testing. -Jim From nobody Sun Feb 5 05:13: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 4AA4112956D for ; Sun, 5 Feb 2017 05:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l71Wt2zJ1hnq for ; Sun, 5 Feb 2017 05:13:54 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0131.outbound.protection.outlook.com [104.47.42.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619F4129577 for ; Sun, 5 Feb 2017 05:13:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rt5xeqtjOPX+oQ4rM1Y0pt47mBK+cXnLlaxCBI1M+v4=; b=FMphYsNg2OFapN4Gry/AIHnMtX6DvsiDTZcfqArRvxINg4QMZ45TYyfTrN5V7jQUSx+4BaotV16ayWoTRLsT6ca3vBexblcx4fwTmRTCWlrrjE9radaFkINXdWvBsJHMXQYBVCYa9PQQS9tundgaD5pNgJE9X2uIsB8V3i21b7A= Received: from BY2PR0301MB2120.namprd03.prod.outlook.com (10.163.197.149) by BY2PR0301MB2120.namprd03.prod.outlook.com (10.163.197.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Sun, 5 Feb 2017 13:13:51 +0000 Received: from BY2PR0301MB2120.namprd03.prod.outlook.com ([10.163.197.149]) by BY2PR0301MB2120.namprd03.prod.outlook.com ([10.163.197.149]) with mapi id 15.01.0888.022; Sun, 5 Feb 2017 13:13:51 +0000 From: Orit Levin To: Jim Fenton , "uta@ietf.org" Thread-Topic: [Uta] UTA meeting in Chicago? Thread-Index: AQHSfbXed5oZLedbOECxUXTITU0rq6FaZkMw Date: Sun, 5 Feb 2017 13:13:50 +0000 Message-ID: References: <9f1d68ed-8826-dd4a-48c2-27b315c887fe@bluepopcorn.net> In-Reply-To: <9f1d68ed-8826-dd4a-48c2-27b315c887fe@bluepopcorn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=oritl@microsoft.com; x-originating-ip: [77.126.6.196] x-ms-office365-filtering-correlation-id: 0d764948-3cf9-497b-c479-08d44dc8d40b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BY2PR0301MB2120; x-microsoft-exchange-diagnostics: 1; BY2PR0301MB2120; 7:uBMGmqRVs84QI4Dcf0+ZY1Ghpclu+qzFqM4r9j/MS1YtF6u0U6qaFNU33es5TtLFtscyVXE9gG8VqYZYUoN4gO/XLhl7e3ryE362ZgKupfiOTu7y4LLLHwVS7sXyb2S8w4RaWRrPXP9mmRhun4PmrWQ1W8MFxtT0S4Slr1PXiKF22nVOWIyH/DSIOz3N5VEWouizEfX5b+RxPQX96iMhtYDrik0eGStXOBaIX54tgnyKWYC+WGfFOOiQDhSxZTaGAF5OI/Dy5i8SrvmdHikwzg3CkG+v4B6lbJSjRxfv5QRXI9M/ade1GSNDEcS+XlBPKcxrAlVYFnqOXv1o6C+JfY0roSqn8JAm/7BrfGe9LMJ7tcGP33Sj5GLmZehsn7s32mL20cCM807MkKkJJ1W8h6kPHCdolWI/HA0aNfryYUWkB2tUcDp296NyDHKYRqY3rztY2+fzPewmqmmLyLRF0i9QEa++VVRP1vAx/fIQytrY2ZIqGoS6Iz48tYnd1DgXHj1TGh8OWV6kmh2ROC37bkOgjx8cMjRhwkMk6cCubwY= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(20170203043)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123558025)(20161123560025)(20161123555025)(20161123564025)(6042181)(6072148); SRVR:BY2PR0301MB2120; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB2120; x-forefront-prvs: 0209425D0A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(377454003)(13464003)(97736004)(7736002)(8990500004)(86612001)(122556002)(107886002)(106356001)(229853002)(74316002)(7696004)(92566002)(9686003)(5001770100001)(5660300001)(305945005)(6246003)(6306002)(99286003)(53936002)(2900100001)(189998001)(2501003)(86362001)(3660700001)(77096006)(38730400001)(76176999)(10090500001)(8676002)(25786008)(6436002)(6506006)(54356999)(81166006)(8936002)(2950100002)(50986999)(101416001)(5005710100001)(81156014)(6116002)(102836003)(3846002)(68736007)(106116001)(105586002)(3280700002)(2906002)(33656002)(66066001)(10290500002)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB2120; H:BY2PR0301MB2120.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2017 13:13:50.9328 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB2120 Archived-At: Subject: Re: [Uta] UTA meeting in Chicago? X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 13:13:56 -0000 Jim et al, Yes, the intent is to meet in Chicago and progress the work. Please, share your plans (drafts, etc.) for the upcoming meeting and reques= t a slot ASAP by Feb 9th. Thank you, The chairs. -----Original Message----- From: Uta [mailto:uta-bounces@ietf.org] On Behalf Of Jim Fenton Sent: Thursday, February 2, 2017 4:38 PM To: uta@ietf.org Subject: [Uta] UTA meeting in Chicago? Are there plans for a UTA WG meeting in Chicago? If so, I'd like an opportunity to present an update on REQUIRETLS, includin= g recent updates to the spec (which I will have revised by then) and info o= n our initial interoperability testing. -Jim _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta From nobody Tue Feb 7 13:52:31 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1E71294A4 for ; Tue, 7 Feb 2017 13:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSH4VdsXJ_tz for ; Tue, 7 Feb 2017 13:52:28 -0800 (PST) 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 95F6A1288B8 for ; Tue, 7 Feb 2017 13:52:28 -0800 (PST) Received: from [IPv6:2601:647:4001:a0c0:a547:7e55:282c:9a12] ([IPv6:2601:647:4001:a0c0:a547:7e55:282c:9a12]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v17LqQlX001453 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 7 Feb 2017 13:52:27 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1486504347; bh=ZtWnSkD1UycMd094DdCgmI64Fx/8HQj0Tn8hE4V46hs=; h=Subject:To:References:From:Date:In-Reply-To; b=ose6LAciHjOo9nXa8647Ht4p8UCgwaM/QVTyTdYfoMC715/WRDfoM7ot2U7NUh9+P V67ZyW4yKiNH5okTWlTI1R2W0XKUjUqjP0NwwO/dcUjgjPQw8+81iHf1VrPgLRmmZE cTzZ0B55fj/n184wcmLCIkN4Sh2QmWwEyKnSqr18= To: Orit Levin , "uta@ietf.org" References: <9f1d68ed-8826-dd4a-48c2-27b315c887fe@bluepopcorn.net> From: Jim Fenton Message-ID: Date: Tue, 7 Feb 2017 13:52:20 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Uta] UTA meeting in Chicago? X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 21:52:30 -0000 I'm currently working on an update to the draft to include the MAYTLS functionality Viktor suggested, to talk some more about possible non-delivery of bounce messages, and other miscellaneous fixes. I expect that to be done before the draft expires on February 17, which is well before the I-D cutoff (March 13). I plan on presenting an update including the changes and some results from our initial interoperability tests. AFAIK, UTA hasn't requested a meeting slot and that closes on Friday, correct? -Jim On 02/05/2017 05:13 AM, Orit Levin wrote: > Jim et al, > Yes, the intent is to meet in Chicago and progress the work. > Please, share your plans (drafts, etc.) for the upcoming meeting and re= quest a slot ASAP by Feb 9th. > > Thank you, > The chairs. > > -----Original Message----- > From: Uta [mailto:uta-bounces@ietf.org] On Behalf Of Jim Fenton > Sent: Thursday, February 2, 2017 4:38 PM > To: uta@ietf.org > Subject: [Uta] UTA meeting in Chicago? > > Are there plans for a UTA WG meeting in Chicago? > > If so, I'd like an opportunity to present an update on REQUIRETLS, incl= uding recent updates to the spec (which I will have revised by then) and = info on our initial interoperability testing. > > -Jim > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta From nobody Tue Feb 7 15:24:31 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 3024312963F; Tue, 7 Feb 2017 15:24:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148650987015.26765.3124914865088761432.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2017 15:24:30 -0800 Archived-At: Cc: uta@ietf.org, uta-chairs@ietf.org, leifj@sunet.se, aamelnikov@fastmail.fm Subject: [Uta] uta - New Meeting Session Request for IETF 98 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 23:24:30 -0000 A new meeting session request has just been submitted by Leif Johansson, a Chair of the uta working group. --------------------------------------------------------- Working Group Name: Using TLS in Applications Area Name: Applications and Real-Time Area Session Requester: Leif Johansson Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: tokbind tls Second Priority: oauth secevent People who must be present: Keith Moore Chris Newman Orit Levin Alexey Melnikov Leif Johansson Jim Fenton Resources Requested: Meetecho support in room Special Requests: please avoid mail or security related BoFs if possible --------------------------------------------------------- From nobody Tue Feb 7 23:19: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 8ADE41295EE for ; Tue, 7 Feb 2017 23:19:07 -0800 (PST) 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 AIq37CzdEq61 for ; Tue, 7 Feb 2017 23:19:05 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 8DFC5129572 for ; Tue, 7 Feb 2017 23:19:05 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id n124so76529646lfd.2 for ; Tue, 07 Feb 2017 23:19:05 -0800 (PST) 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-transfer-encoding; bh=a0ZJ/WQJfjq3SAklBM9kjARLTVS0PVI+Rgk0uFcDuiM=; b=i6bEh1erxKENfRfF7M4U3+6QehKyrCnsS/kjIBIoGM9CJZHSjRndjGdi9dLz/OP+R6 zGb8b8G0pVL8NgmEhvKTVoOSqZtpDlksbfhx4zA28ATzaZBlgWJJlIHIx09Jb80bPkLq LNqqeRfsIXG0HB6nMc7uBPgm9GOm0qjHUzh1EMQSQGyw4lK2xgtoEdr10MKtVqvkz2cx g3wa3sLGpaCaXeykB/s4qnV3WtTB5dKnrXjAm5d58DTSSoQNXnhP1R9YNeddU0DteCSF w2k7/qEWHfqEgHk0gfw6q0LPd7lj+yAW3JWKxTpxrj2+PDF+NFQStc2qJAgMNL/+6RB1 cSRw== 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-transfer-encoding; bh=a0ZJ/WQJfjq3SAklBM9kjARLTVS0PVI+Rgk0uFcDuiM=; b=q+kYM55TS2UQtgIW4RzFe4O18UkaRvpjMj2vGl2K4eoibt4uo7tN0WVWvGV4TJfj7L icvdQmVTiv8+onSOxgQc4M0IyKzGXsdExVNelK6yLSOaXlRcWv80sV6Xz/Ay+Lbd50NE //3m54JkyZk14V5tRv6b3aBII+CqHx6OsKNsEBYEpqFWRRHuihJFuWl7b6G+cCuJOGel Q9xbNohRUP+a3bcggvEtijdjBrhWiONnngPWGOt6KLsJyMG5qw8oA4aOd6QDjiuhNsEF Np0m6l642lRuoPD7cqa/e2jwBTaFOSfDSmtac5jomc5Ud2MCmFb0ezmVOr3/YzXcICLO TEbw== X-Gm-Message-State: AIkVDXKU2veqyiuZ1Gm6UN0EGVCz+Oo98/llRB2pNZwZEL9gtLtUp4qVHyo4zOVAOynaCA== X-Received: by 10.46.71.207 with SMTP id u198mr7194495lja.42.1486538343233; Tue, 07 Feb 2017 23:19:03 -0800 (PST) Received: from [109.105.104.207] (dhcp73.se-tug.nordu.net. [109.105.104.207]) by smtp.gmail.com with ESMTPSA id t19sm2119299ljd.30.2017.02.07.23.19.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 23:19:02 -0800 (PST) To: uta@ietf.org References: <9f1d68ed-8826-dd4a-48c2-27b315c887fe@bluepopcorn.net> From: Leif Johansson Message-ID: Date: Wed, 8 Feb 2017 08:19:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <9f1d68ed-8826-dd4a-48c2-27b315c887fe@bluepopcorn.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] UTA meeting in Chicago? X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 07:19:07 -0000 On 2017-02-03 01:38, Jim Fenton wrote: > Are there plans for a UTA WG meeting in Chicago? > > If so, I'd like an opportunity to present an update on REQUIRETLS, > including recent updates to the spec (which I will have revised by then) > and info on our initial interoperability testing. > > -Jim Me and Orit talked it over and although there hasn't been a lot of progress on our remaining WG drafts, we're nevertheless requesting a 1 hr slot to try to finish up outstanding items. In addition, we'll try to get you a short slot to present REQUIRETLS Cheers Leif From nobody Wed Feb 8 12:12:01 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E99D1295BC for ; Wed, 8 Feb 2017 12:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.122 X-Spam-Level: X-Spam-Status: No, score=-3.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfKHQtcdwEy5 for ; Wed, 8 Feb 2017 12:11:58 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F07B129E36 for ; Wed, 8 Feb 2017 12:11:57 -0800 (PST) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d27 with ME id iLBu1u00L17Lgi403LBvZR; Wed, 08 Feb 2017 21:11:56 +0100 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Wed, 08 Feb 2017 21:11:56 +0100 X-ME-IP: 92.170.5.52 To: uta@ietf.org References: <9f1d68ed-8826-dd4a-48c2-27b315c887fe@bluepopcorn.net> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <306e2203-1af1-e1e3-1e10-ea3abcdc8321@trigofacile.com> Date: Wed, 8 Feb 2017 21:11:54 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Uta] UTA meeting in Chicago? X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 20:12:00 -0000 Hi all, > Me and Orit talked it over and although there hasn't been a lot of > progress on our remaining WG drafts, we're nevertheless requesting > a 1 hr slot to try to finish up outstanding items. Could it be discussed whether updating IMAP specification (RFC 3501) in favour of following RFC 7525 (BCP for TLS) should be included in draft-ietf-uta-email-deep or be a separate document? RFC 3501 mentions in Section 11.1 that "IMAP client and server implementations MUST implement the TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite", which is a statement that should no longer be followed. Maybe Sections 2.1 and 2.2 of RFC 2595 (Using TLS with IMAP, POP3 and ACAP) could also be marked obsolete, in favour of RFC 7525. Have a nice day, -- Julien ÉLIE « Se coucher tard… nuit. » (Raymond Devos) From nobody Mon Feb 13 21:51: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 4181B12940B for ; Mon, 13 Feb 2017 21:51:31 -0800 (PST) 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 3SImYxypdo7b for ; Mon, 13 Feb 2017 21:51:30 -0800 (PST) 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 EC1981294EF for ; Mon, 13 Feb 2017 21:51:29 -0800 (PST) Received: from splunge.local (c-24-4-98-3.hsd1.ca.comcast.net [24.4.98.3]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v1E5pRDr005821 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 13 Feb 2017 21:51:29 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1487051489; bh=fTfxNU8vKIdeN7+b31P9rU6n5WXx9Rx5SKG3arPV/pA=; h=Subject:References:To:From:Date:In-Reply-To; b=RDSRnMr/kvmcqHQ4OGE5bmqBiBb1lnwsBNkYyAGZ75ePDkI8OYfiKZfGRbQ3BMJns XypJsmbcl2mKjfeeZq/yz7H9oL8Pz6Fexk1dIEEai9rduZEqJSOQusuIxvySN15AZp clp8BQFjpn+0REqzOJKn0tVQlMvoJ10QCOqq5PwY= References: <148705066595.22281.9383659754042012758.idtracker@ietfa.amsl.com> To: "uta@ietf.org" From: Jim Fenton X-Forwarded-Message-Id: <148705066595.22281.9383659754042012758.idtracker@ietfa.amsl.com> Message-ID: <3f9308ab-d01d-71e9-be14-b9894601a416@bluepopcorn.net> Date: Mon, 13 Feb 2017 21:51:21 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148705066595.22281.9383659754042012758.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Uta] Fwd: New Version Notification for draft-fenton-smtp-require-tls-03.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 05:51:31 -0000 A new version of I-D, draft-fenton-smtp-require-tls-03.txt has been successfully submitted by Jim Fenton and posted to the IETF repository. Name: draft-fenton-smtp-require-tls Revision: 03 Title: SMTP Require TLS Option Document date: 2017-02-13 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-fenton-smtp-require-tls-03.txt Status: https://datatracker.ietf.org/doc/draft-fenton-smtp-require-tls/ Htmlized: https://tools.ietf.org/html/draft-fenton-smtp-require-tls-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-fenton-smtp-require-tls-03 Abstract: The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is prioritized over security. This document describes a complementary SMTP service extension, REQUIRETLS. If the REQUIRETLS option is used when sending a message, it asserts a request on the part of the message sender to override the default negotiation of TLS, either by requiring that TLS be negotiated when the message is relayed, or by requesting that policy mechanisms such as SMTP STS and DANE be ignored when relaying a high priority message. 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. The IETF Secretariat From nobody Wed Feb 15 07:09:15 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 D249F1294E8; Wed, 15 Feb 2017 07:09:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148717135485.17389.12291099699972422174.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 07:09:14 -0800 Archived-At: Cc: uta@ietf.org Subject: [Uta] I-D Action: draft-ietf-uta-mta-sts-03.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 15:09:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications of the IETF. Title : SMTP MTA Strict Transport Security (MTA-STS) Authors : Daniel Margolis Mark Risher Binu Ramakrishnan Alexander Brotman Janet Jones Filename : draft-ietf-uta-mta-sts-03.txt Pages : 15 Date : 2017-02-15 Abstract: SMTP Mail Transfer Agent Strict Transport Security (SMTP STS) is a mechanism enabling mail service providers to declare their ability to receive TLS-secured connections and an expected validity of certificates presented by their MX hosts, and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-uta-mta-sts-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-mta-sts-03 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 Feb 15 07:09:48 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 581AF129A66; Wed, 15 Feb 2017 07:09:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148717138635.17256.15423507851889512917.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 07:09:46 -0800 Archived-At: Cc: uta@ietf.org Subject: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-03.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 15:09:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications of the IETF. Title : SMTP TLS Reporting Authors : Daniel Margolis Alexander Brotman Binu Ramakrishnan Janet Jones Mark Risher Filename : draft-ietf-uta-smtp-tlsrpt-03.txt Pages : 17 Date : 2017-02-15 Abstract: A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE [RFC6698], and SMTP 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-uta-smtp-tlsrpt-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-tlsrpt-03 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 Feb 15 11:57:54 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00969129A8F for ; Wed, 15 Feb 2017 11:57:53 -0800 (PST) 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 naBAZuYYIp-p for ; Wed, 15 Feb 2017 11:57:52 -0800 (PST) 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 235D1129A89 for ; Wed, 15 Feb 2017 11:57:52 -0800 (PST) X-AuditID: a2962c47-58fff70000001b7f-5e-58a4b2befa72 Received: from COPDCEX23.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 (SMTP Gateway) with SMTP id D2.D0.07039.EB2B4A85; Wed, 15 Feb 2017 12:57:51 -0700 (MST) Received: from COPDCEX19.cable.comcast.com (147.191.124.150) by COPDCEX23.cable.comcast.com (147.191.124.154) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 15 Feb 2017 12:57:49 -0700 Received: from COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380]) by COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380%19]) with mapi id 15.00.1263.000; Wed, 15 Feb 2017 12:57:49 -0700 From: "Brotman, Alexander" To: "uta@ietf.org" Thread-Topic: Updated drafts for MTA-STS & TLSRPT Thread-Index: AdKHv9WnSXqblSg/SP+B63qTKdbf9w== Date: Wed, 15 Feb 2017 19:57:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsWSUDRnsu7+TUsiDK7OU7Q4dbSZ0YHRY8mS n0wBjFFcNimpOZllqUX6dglcGRdfHGUqeMtcsezzfPYGxn9MXYycHBICJhIffrxnA7GFBLqY JE6uZYawDzFKXPvi2sXIBWSfZJRYP38nWBGbgJXE2//tYEUiAooSL/68ZwexhQV0JBre3mOB iBtKnLx3AKiGA8jWk1i8CKyERUBV4tDzd2B7eQW8JF7e3AA2hlFATOL7qTVgcWYBcYlbT+ZD 3SYgsWTPeWYIW1Ti5eN/rBC2gcTWpftYIGw5iWU/7zBD9OpILNj9iQ3C1pZYtvA1M8QuQYmT M59A1YtLHD6yg3UCo+gsJOtmIWmfhaR9FpL2BYwsqxjlkvMLUpJzM/JLSwwM9ZITk3JS9ZLz c5MTi0tA9CZGYIwsmqbjvoPxQq/zIUYBDkYlHt4fc5dECLEmlhVX5gJDlYNZSYRXYBJQiDcl sbIqtSg/vqg0J7X4EKM0B4uSOO9Z/kURQgLpiSWp2ampBalFMFkmDk6pBsb4/vVHi+cpGhy/ z9KywGLytL+PJ0vz80dqG694Ly/48WNK660DDyWuPgo/VVX7oH6q7MITV+9Lem9MXMCxdrXQ 1CWZ5rbbs94GMLB6vTbPydsiukhsrv5Ocd5XpgndsWICj1UqzjtyXv2rWfVvsvPl7VP7VO9a lEre+9mgt5ntQ13kJy8zp1dKLMUZiYZazEXFiQCiC3UbjQIAAA== Archived-At: Subject: [Uta] Updated drafts for MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 19:57:53 -0000 Folks, We uploaded new revisions for MTA-STS and TLSRPT. There are minor changes = to each: 1) Remove the "_" from DNS records to be consistent with A/AAAA records use= d with the HTTPS retrieval, and make this a bit less confusing for deployme= nts. We did this for both MTA-STS and TLSRPT. 2) Clarify language around punycode=20 Please give these a review and get back to us with any comments. Thank you= . -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast x5364 From nobody Mon Feb 20 11:16: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 515521296DA for ; Mon, 20 Feb 2017 11:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fp4arD_nYcGs for ; Mon, 20 Feb 2017 11:16:21 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E5A129559 for ; Mon, 20 Feb 2017 11:16:21 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id y140so27197607oie.1 for ; Mon, 20 Feb 2017 11:16:21 -0800 (PST) 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=bGov1A4OkSEHx16IfjysHVseZ2Ql/FNFbuQ7ZSE1u6g=; b=o3kzrm+SFzDOJuuZAKWVhtWwV9TPQt2khLM9pQ4/fYhNeZ2KUAAXTNQlqI1mUYcVaF RY0tqo6eCT6rdrVp8b7xMpk5mrCqAIhgxoILGu1kW82GU+Ya793Snyj/H6/llbYRdfM8 2ceOUKyVnzqbp38kcPgo7qAaKa1cqUGbSq8d9n9yNde4n1wwOHXGZTOvcIb5K1Luaddp q81j3KAq9ur4HkyJ9xTT/tHO1hEqHrn9JsGLDkfkHM+Zt/5z57uMYzTs6IRlNFYGzGxJ 0sFsIbShzKrw3RMZrxB1YCwuy8adArYTE1dG8YgNSuSkUXso3P1ELB6knl7mXHj7xkAa 3eOQ== 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=bGov1A4OkSEHx16IfjysHVseZ2Ql/FNFbuQ7ZSE1u6g=; b=sJXCW9I2r4iFvvxS4iI1L6B3pPYmqj8UHNtRNVveE2Em7E7NJRFxb/K13vPz9mni5k vVfzo6WzGKyhCEw8v6eXQ4Tt5AriOJy9a3ME1ucjuHI0ymmSlpEcK7YzyXyNJ//GkF9t EYMNTM1A1459zC9vT9/58ANfTvvkOFNDaaESiUnOV/b82lzAlyFl12RgPEbnCLWGVOS4 4sPMUges50Mo7NRQDaZrJ6C4/AYKzx5A3YWwhj9pdjlwNGlW7swVgKXk3Zj5ncePX/bb Ne+/OtzgTrJOT9gQn3psxH9W2YigqBGiN9mHs1gnaEwZwGEShsDRukChY3ucOFQFNQyU GoWg== X-Gm-Message-State: AMke39koVN6hW2ReffMg1E1YFe9E/EOeEwZ8wmEu4SwPZrMEpMojAgd2mjdiD3fY0NRZOYe1TCwOy116Bi+lKg== X-Received: by 10.202.3.197 with SMTP id 188mr12431763oid.31.1487618180842; Mon, 20 Feb 2017 11:16:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.24.110 with HTTP; Mon, 20 Feb 2017 11:16:20 -0800 (PST) In-Reply-To: References: From: David Illsley Date: Mon, 20 Feb 2017 19:16:20 +0000 Message-ID: To: "Brotman, Alexander" Content-Type: multipart/alternative; boundary=001a113b72063b115d0548fb1914 Archived-At: Cc: "uta@ietf.org" Subject: Re: [Uta] Updated drafts for MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 19:16:23 -0000 --001a113b72063b115d0548fb1914 Content-Type: text/plain; charset=UTF-8 It's been a while since I looked at the drafts, and they're looking good. The area I'm getting stuck on is max_age. It's a point of user-configurability, with little guidance on what's good, and the strong possibility that people will make weak or otherwise bad choices. As someone who expects MTA-STS to have a similar effect to HSTS - effectively ratchet security, it seems like it's desirable for it to be as long as possible. In general, the fact the a complete failure causes a policy update makes this simple and safe. There are a couple of reasons why I think it's not quite that easy: 1. It's not desirable for a 'report' configuration to be used beyond the point that a domain has switched to 'enforce', and a long-cached 'report' policy could do this. 2. It prevents new MX records (eg new servers for increased capacity or backups) not covered by the cached policy from being used until the max_age, or until a failure to send with all the covered servers. There is also a downside that if policies are cached for a long time, misconfiguration of the policy server is less likely to be noticed quickly as fewer domains will be sending reports indicating a failure. Having pondered it a bit, my suggestion is: 1. A SHOULD that max_age is set to at least 6 months, other than during roll-out 2. A SHOULD that well-behaved clients with a cached policy should re-check DNS TXT policy weekly, and retrieve via HTTPS if the policy id has changed. An alternative to (2) would be to add an optional refresh_after field with similar semantics which would have a default value of 7 days which could be overridden if, for some reason there are concerns that weekly is too often (but I'm generally of the opinion that fewer options are better). I hope that makes sense, and do let me know if I've missed something. Cheers, David On Wed, Feb 15, 2017 at 7:57 PM, Brotman, Alexander < Alexander_Brotman@comcast.com> wrote: > Folks, > > We uploaded new revisions for MTA-STS and TLSRPT. There are minor changes > to each: > > 1) Remove the "_" from DNS records to be consistent with A/AAAA records > used with the HTTPS retrieval, and make this a bit less confusing for > deployments. We did this for both MTA-STS and TLSRPT. > 2) Clarify language around punycode > > Please give these a review and get back to us with any comments. Thank > you. > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse > Comcast > x5364 > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a113b72063b115d0548fb1914 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's been a while since I looked at the drafts, and they're looki= ng good.

The area I'm getting stuck on is max_age. It'= s a point of user-configurability, with little guidance on what's good,= and the strong possibility that people will make weak or otherwise bad cho= ices.

As someone who expects MTA-STS to have a similar effect = to HSTS - effectively ratchet security, it seems like it's desirable fo= r it to be as long as possible.

In general, the fact the a com= plete failure causes a policy update makes this simple and safe. There are = a couple of reasons why I think it's not quite that easy:
1. I= t's not desirable for a 'report' configuration to be used beyon= d the point that a domain has switched to 'enforce', and a long-cac= hed 'report' policy could do this.
2. It prevents new MX r= ecords (eg new servers for increased capacity or backups) not covered by th= e cached policy from being used until the max_age, or until a failure to se= nd with all the covered servers.

There is als= o a downside that if policies are cached for a long time, misconfiguration = of the policy server is less likely to be noticed quickly as fewer domains = will be sending reports indicating a failure.

Having pondered = it a bit, my suggestion is:
1. A SHOULD that max_age is set to at = least 6 months, other than during roll-out
2. A SHOULD that well-b= ehaved clients with a cached policy should re-check DNS TXT policy weekly, = and retrieve via HTTPS if the policy id has changed.

An altern= ative to (2) would be to add an optional refresh_after field with similar s= emantics which would have a default value of 7 days which could be overridd= en if, for some reason there are concerns that weekly is too often (but I&#= 39;m generally of the opinion that fewer options are better).

= I hope that makes sense, and do let me know if I've missed something.
Cheers,
David
<= div>


<= /div>

On Wed, Feb 15, 2017 at 7:57 PM, Brotman, Alexander= <Alexander_Brotman@comcast.com> wrote:
Folks,

We uploaded new revisions for MTA-STS and TLSRPT.=C2=A0 There are minor cha= nges to each:

1) Remove the "_" from DNS records to be consistent with A/AAAA r= ecords used with the HTTPS retrieval, and make this a bit less confusing fo= r deployments.=C2=A0 We did this for both MTA-STS and TLSRPT.
2) Clarify language around punycode

Please give these a review and get back to us with any comments.=C2=A0 Than= k you.

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


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

--001a113b72063b115d0548fb1914-- From nobody Tue Feb 21 15:56:01 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731DA12944C for ; Tue, 21 Feb 2017 15:55:59 -0800 (PST) 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 v5mWPC8aJosD for ; Tue, 21 Feb 2017 15:55:58 -0800 (PST) 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 72833129448 for ; Tue, 21 Feb 2017 15:55:58 -0800 (PST) Received: from splunge.local ([216.127.117.40]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v1LNtuVf026478 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 21 Feb 2017 15:55:57 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1487721357; bh=rAWGXr6+wfHyLG9W0Es4jayBYmhx1lZbDxzjTbakuA4=; h=From:To:Subject:Date; b=VhXxoPzHcCSIp1BmkGUV08nCoBKk3+haJSFVMxcTOBwinLCvfzlxvEr7gpxfsnMZv Kf7bEyo7448ui9+bFb+T+eNn2esvH8rLLbGy06Rjam/vN5SAp6mSoKUjvuB8FhODc2 1ftSi3Xd4HPRnq3EuWyHcU0O171XPuqsWmkRQarA= From: Jim Fenton To: "uta@ietf.org" Message-ID: <813df83a-841e-4e6a-e3a1-f2852b20ddbc@bluepopcorn.net> Date: Tue, 21 Feb 2017 15:55:54 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 23:55:59 -0000 Below are comments from my recent reading of draft-ietf-uta-mta-sts-03. The biggest concern I have is the relationship between the DNS TXT record and the HTTPS policy record. The policy is hosted in HTTPS rather directly in DNS in order to attempt to provide security without DNSSEC. But if attacks on DNS are in the threat model, one has to consider that an attacker might make it appear that there is not a DNS TXT record at all, which causes the HTTPS record not to be retrieved at all (MTA STS is presumed not to be deployed). This makes MTA STS too easy to defeat. =3D=3D=3D=3D=3D Abstract Introduces the acronym for the specification as SMTP STS. Should probably be MTA STS. Is MTA STS hyphenated? Document is inconsistent. 1.0 Introduction "...delete parts of the SMTP session..." -> "...delete or corrupt parts of the SMTP session..." (in view of common firewall behavior to change STARTTLS to XXXXXXXX). "...downgrade or interception attacks..." -> "...downgrade or MITM attacks..." (interception is the motive or result, not the attack). 2.0. Related Technologies "In addition, SMTP STS provides..." -> "In addition, MTA STS provides..." (and elsewhere in the document) 3.0. Policy Discovery If an attacker is able to spoof an NXDOMAIN response to the TXT record request, MTA STS is ignored. This seems like a pretty serious problem in the absence of DNSSEC, the use of which is of course not being assumed. 3.1. MTA-STS TXT records There is no IANA registry for reserved hostnames, which is why protocols like SPF store their policies at the domain itself. Is there some reason this is not being done here? The version field can be used to distinguish from SPF records and other TXT records at the domain level. "...are discarded" -> "...MUST be discarded" 3.2. MTA-STS Policies "mx": Why is there an emphasis on providing confirmation of the response to the MX lookup, when it is just as easy to spoof the A/AAAA record lookup that follows the MX and yet there is no publication of an A/AAAA policy? "A lenient parser SHOULD accept...": For the protocol to be extensible, this has to be "Parsers MUST accept..." "...SHALL be ignored" -> "...MUST be ignored" 3.3. HTTPS Policy Fetching Why MUST 3xx redirects not be followed? "A suggested timeout is one minute..." This could quickly tie up SMTP client resources. Is there any mitigation for that? It also seems like a long timeout. 4.2. MX Certificate Validation Is there a way to allow either CA-based validation or DANE for a certificate that is presented? This seems to conflict with the use of DANE-based certificate validation, or at least there is no order of precedence for certificate validation. 5.0. Policy Application "When a message fails to deliver...": How does the check for the updated policy occur, by looking for an updated TXT record or by re-retrieving the HTTPS policy? 5.2. Policy Application Control Flow In step 1, it is not clear whether the attempt to fetch a new policy involves the TXT record or directly the HTTPS policy. In step 2, should some sort of warning be generated if the retrieved MXes differ from the current policy, or is this considered normal? It might be a sign of spoofing or misconfiguration. 6.1. Policy Updates "...HTTPS endpoint has been updated but the TXT record has not yet been...": Throughout this specification, no mention is made of DNS caching of the TXT records. Should the records be published with relatively short TTL, or relatively long TTL? It definitely has an effect on how dynamic the domain's policy can be. 8. Security Considerations Item 2, falsification of A/AAAA responses can also be used to redirect client connections to a rogue server. "Sender policy cache": It's not clear how this resists the blockage of the TXT record. If the record is consistently blocked, the policy will never be discovered to be cached. Also, caches are of finite size and can not be expected to be kept consistently. If a client discovers a policy with serial number "xxx", and then subsequently doesn't discover a policy through the TXT record, what does it do? Malicious MTA-STS TXT record: This seems to assume that the motive of the attacker is to create a rogue MX server, but suppose the motive of the attacker is instead to foil reception of email by the domain. Could they accomplish this by publishing a bogus STS policy that makes all the MX records look bad? This relates to the problem of not having an IANA host name registry. From nobody Thu Feb 23 12:35:46 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 711B3129A67 for ; Thu, 23 Feb 2017 12:35:44 -0800 (PST) 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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWi74VfSZlNa for ; Thu, 23 Feb 2017 12:35:42 -0800 (PST) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::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 954971294DF for ; Thu, 23 Feb 2017 12:35:42 -0800 (PST) Received: by mail-yb0-x22a.google.com with SMTP id i66so693033yba.1 for ; Thu, 23 Feb 2017 12:35:42 -0800 (PST) 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=LOOMQ4bx2IdhdbG0Bool1WA6832zKQkrm2wID1Otr+I=; b=bmQUYiPCM8BiImup8up5+iGUWZ936Z0A2w3lU+AFww39wF82qd60bV+cvJi23ooBqD GA5YwSfLhUqYUODJFaExv8WfMloEHjQ3FqgFwfk3lcCYCQ8xs09WAeVGZ+/khc3gXeX8 D7DZY+B7bRJHuGQC+52KSfGFh7J1PR1pr9Kqdg6lGMP9RTamJzlyO4wh7jTsk/wPUkix wqevmO3UjmCTkG9QuKsFIFuoRBHpxSwETe9neBsngp5Fe8GtzFZdVsmIK4SxLCG2GeUu gvzeacccxxpLFC07taw8DKntH1vGkW7C7g4iB/gOHdAg9NbtEIOoy8gSaX8odZ+6n74h xJzg== 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=LOOMQ4bx2IdhdbG0Bool1WA6832zKQkrm2wID1Otr+I=; b=TUeN07NUXj0w66m1WpOsCoWjHR4v2NEe3AkO+/fFUrZyz6Ss46bzd/fUCXbpcANm0b a7Vk5SV7je/F6CGTCZ1QKQCO4MSvZBh5THt4EGumweGqnl/N9oQeCmXRREkh207lgr9f Ly+WuxCwA6EilEWpQCnybUBwbKdLsA3lAUaTxUsv0dv3XJUpN24mehwKBn5PYk6nGXe9 rS+LwHkuSB8qiLJjHUMebawv//YPkcU4hsswGqFzRRUeC2thpfKZO8dwHJw6rfRfX25w pEXF4K0cLtS5xTMFVlHKXUj/t3zr/DgCdTI68RViumEO7RDpMqwXT9JqTzwSpOtm7JPz xPIQ== X-Gm-Message-State: AMke39kpcsaL3UgmSxvJ42PYGsL++PBkrypEcnce0fH8nQjHWBl8lHmGeonl+XE+t2CXN1PdyP551v7GNG80tjfe X-Received: by 10.37.119.5 with SMTP id s5mr24152347ybc.124.1487882141034; Thu, 23 Feb 2017 12:35:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.24.6 with HTTP; Thu, 23 Feb 2017 12:35:40 -0800 (PST) In-Reply-To: References: From: Daniel Margolis Date: Thu, 23 Feb 2017 22:35:40 +0200 Message-ID: To: David Illsley Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114be7e28989df0549388e1b" Archived-At: Cc: "uta@ietf.org" , "Brotman, Alexander" Subject: Re: [Uta] Updated drafts for MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 20:35:44 -0000 --001a114be7e28989df0549388e1b Content-Type: multipart/alternative; boundary=001a114be7e27c4dcf0549388e9f --001a114be7e27c4dcf0549388e9f Content-Type: text/plain; charset=UTF-8 Thanks for the comments! Comments inline. On Mon, Feb 20, 2017 at 9:16 PM, David Illsley wrote: > In general, the fact the a complete failure causes a policy update makes > this simple and safe. There are a couple of reasons why I think it's not > quite that easy: > 1. It's not desirable for a 'report' configuration to be used beyond the > point that a domain has switched to 'enforce', and a long-cached 'report' > policy could do this. > 2. It prevents new MX records (eg new servers for increased capacity or > backups) not covered by the cached policy from being used until the > max_age, or until a failure to send with all the covered servers. > Right. And in fact, per section 5.2, if a policy covers only some of the current MX records, a sender with that policy may continue to use that policy unless/until none of the allowed MX records are reachable or unless/until none of the MX records are valid under the policy. There is no *requirement* that a sender refresh the cached policy as long as it continues to work. So you've pointed out a somewhat subtle pitfall. If I deploy a policy with "mx: ['*.google.com']" and I later deploy additional MXs with higher priority on mail.google.*net *(and, because I'm smart, I remember to update my deployed policy), senders may nonetheless only send mail to the old *.com* MXs, resulting in an unexpected traffic imbalance. A few observations about this case: 1. I don't know that this is a serious issue; it depends heavily on how specific the "mx" pattern is versus turnover in MX hosts. As far as I recall we haven't changed our MX hosts as long as I've worked here... 2. This could be fixed if we said that senders MUST seek a new policy whenever some MXs are filtered out by policy application (5.2 step 2). 3. This is optionally fixed by senders refreshing cached policies at an arbitrary time, which they may (but need not) do. Since they can cheaply discover the presence of new policies (and may in fact lookup the magical TXT record prior to doing a cache-policy-check anyway, depending on implementation), this isn't really far-fetched--but we don't require them to do so. There is also a downside that if policies are cached for a long time, > misconfiguration of the policy server is less likely to be noticed quickly > as fewer domains will be sending reports indicating a failure. > That's also a good point, and it is unaddressed by my hypothetical MUST above (#2). > > Having pondered it a bit, my suggestion is: > 1. A SHOULD that max_age is set to at least 6 months, other than during > roll-out > 2. A SHOULD that well-behaved clients with a cached policy should re-check > DNS TXT policy weekly, and retrieve via HTTPS if the policy id has changed. > I think the phrasing you give here suggests that if I send mail to your domain less than once a week, I should run a cron job to refresh the cache--and I hate cron jobs. So to be slightly pedantic, would it work just as well to say senders SHOULD check for an updated policy *if* *using* a policy which is older than one week? (My phrasing may be unclear, but I mean, of course, that they need only check for an updated policy if they are otherwise sending mail to that domain anyway.) Of course, we could still simply suggest/require senders *always* check for a new policy--it's one more DNS lookup to the recursive resolver per-send--but I bet in some implementations there are good reasons not to do this. > An alternative to (2) would be to add an optional refresh_after field with > similar semantics which would have a default value of 7 days which could be > overridden if, for some reason there are concerns that weekly is too often > (but I'm generally of the opinion that fewer options are better). > Agreed, I think extra options here are just extra complexity. > > I hope that makes sense, and do let me know if I've missed something. > Cheers, > David > > > > On Wed, Feb 15, 2017 at 7:57 PM, Brotman, Alexander < > Alexander_Brotman@comcast.com> wrote: > >> Folks, >> >> We uploaded new revisions for MTA-STS and TLSRPT. There are minor >> changes to each: >> >> 1) Remove the "_" from DNS records to be consistent with A/AAAA records >> used with the HTTPS retrieval, and make this a bit less confusing for >> deployments. We did this for both MTA-STS and TLSRPT. >> 2) Clarify language around punycode >> >> Please give these a review and get back to us with any comments. Thank >> you. >> >> -- >> Alex Brotman >> Sr. Engineer, Anti-Abuse >> Comcast >> x5364 >> >> >> _______________________________________________ >> Uta mailing list >> Uta@ietf.org >> https://www.ietf.org/mailman/listinfo/uta >> > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > > --001a114be7e27c4dcf0549388e9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the comments! Comments inline.

On Mon, Feb 20, 2017 at 9:16 P= M, David Illsley <davidillsley@gmail.com> wrote:
<= div>
In general, the fact the a= complete failure causes a policy update makes this simple and safe. There = are a couple of reasons why I think it's not quite that easy:
=
1. It's not desirable for a 'report' configur= ation to be used beyond the point that a domain has switched to 'enforc= e', and a long-cached 'report' policy could do this.
2= . It prevents new MX records (eg new servers for increased capacity or back= ups) not covered by the cached policy from being used until the max_age, or= until a failure to send with all the covered servers.

Right. And= in fact, per section=C2=A05.2, if a policy covers only some of the current= MX records, a sender with that policy may continue to use that policy unle= ss/until none of the allowed MX records are reachable or unless/until none = of the MX records are valid under the policy. There is no *requirement* tha= t a sender refresh the cached policy as long as it continues to work.=C2=A0=

So you've pointed out a somewhat subtle pitfa= ll. If I deploy a policy with "mx: ['*.google.com']" and I later deploy additional MXs with higher= priority on mail.google.net (and, because I'm smart, I remember= to update my deployed policy), senders may nonetheless only send mail to t= he old .com=C2=A0MXs, resulting in an unexpected traffic imbalance.<= /div>

A few observations about this case:

=
1. I don't know that this is a serious issue; it depends hea= vily on how specific the "mx" pattern is versus turnover in MX ho= sts. As far as I recall we haven't changed our MX hosts as long as I= 9;ve worked here...

2. This could be fixed if we s= aid that senders MUST seek a new policy whenever some MXs are filtered out = by policy application (5.2 step 2).

3. This is opt= ionally fixed by senders refreshing cached policies at an arbitrary time, w= hich they may (but need not) do. Since they can cheaply discover the presen= ce of new policies (and may in fact lookup the magical TXT record prior to = doing a cache-policy-check anyway, depending on implementation), this isn&#= 39;t really far-fetched--but we don't require them to do so.
=
There is also a downside that if polic= ies are cached for a long time, misconfiguration of the policy server is le= ss likely to be noticed quickly as fewer domains will be sending reports in= dicating a failure.

That's also a good point, and it is unaddr= essed by my hypothetical MUST above (#2).
=C2=A0

Having pondered it a bit, my suggestion is:
1. A SHOULD that max_age is set to at least 6 months, other than during= roll-out
2. A SHOULD that well-behaved clients with a cached poli= cy should re-check DNS TXT policy weekly, and retrieve via HTTPS if the pol= icy id has changed.

=
I think the phrasing you give here suggests that if I send mail = to your domain less than once a week, I should run a cron job to refresh th= e cache--and I hate cron jobs.=C2=A0

So to be slig= htly pedantic, would it work just as well to say senders SHOULD check for a= n updated policy if using=C2=A0a policy which is older than o= ne week? (My phrasing may be unclear, but I mean, of course, that they need= only check for an updated policy if they are otherwise sending mail to tha= t domain anyway.)=C2=A0

Of course, we could still = simply suggest/require senders *always* check for a new policy--it's on= e more DNS lookup to the recursive resolver per-send--but I bet in some imp= lementations there are good reasons not to do this.=C2=A0
=C2=A0<= /div>
An alternative to (2) would be to add an optional refresh_after= field with similar semantics which would have a default value of 7 days wh= ich could be overridden if, for some reason there are concerns that weekly = is too often (but I'm generally of the opinion that fewer options are b= etter).

Agreed,= I think extra options here are just extra complexity.=C2=A0
=C2= =A0

I hope that makes sense, and do let me know if I&= #39;ve missed something.
Cheers,
David
=



=
On Wed, Feb 15, 2017 at 7:57 PM, Brotman, Alexan= der <Alexander_Brotman@comcast.com> wrote:<= br>
Folks,

We uploaded new revisions for MTA-STS and TLSRPT.=C2=A0 There are minor cha= nges to each:

1) Remove the "_" from DNS records to be consistent with A/AAAA r= ecords used with the HTTPS retrieval, and make this a bit less confusing fo= r deployments.=C2=A0 We did this for both MTA-STS and TLSRPT.
2) Clarify language around punycode

Please give these a review and get back to us with any comments.=C2=A0 Than= k you.

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


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


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


--001a114be7e27c4dcf0549388e9f-- --001a114be7e28989df0549388e1b Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAuhZmtv08Q+so/ jIoTLNfz8OHsfuzehid25exYwGM0KDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAyMjMyMDM1NDFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAejSXGLJ5OcUKdVVmE8sllJ5zji1RcTLP NDk+ojp5EmmFN903sfwuQBTG9wT5iD6VagBfYnOQevqSbzMKNJMlCtvHby4QG7Sn4Lx5NB6gv/GI PRkE80B8jJYELsKmM1NdGNlH9wVgR/YiXRliO2/w65POWY/mAappBs4DLnouJrmhCzPEMupnWCMo AQxyiNbFR8HpRVVhgB/DpFY1BaVumsdOxS7rVFW4arWjpAJPqbnMzYlClfx4/LERKwWtAKk6OFfH k1PSBen4VBmyp05Vcp/V3lRNIQuQ6wi3DIsDKX2862u+IfSpTQ+PcdGj8hHBn5PK3uVgQqbBFtff W9QJyw== --001a114be7e28989df0549388e1b-- From nobody Thu Feb 23 13:00:20 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 23C2512A2CC for ; Thu, 23 Feb 2017 13:00:18 -0800 (PST) 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 tvyCyGI3A-t0 for ; Thu, 23 Feb 2017 13:00:16 -0800 (PST) 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 C6890129AF7 for ; Thu, 23 Feb 2017 13:00:16 -0800 (PST) Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id D4F7E7A330A for ; Thu, 23 Feb 2017 21:00:15 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 23 Feb 2017 16:00:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <905199AC-51EE-42E9-AB54-68C99578A03E@dukhovni.org> References: To: uta@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Uta] Updated drafts for MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "uta@ietf.org" List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 21:00:18 -0000 > On Feb 23, 2017, at 3:35 PM, Daniel Margolis = wrote: >=20 >> 2. It prevents new MX records (eg new servers for increased capacity = or backups) not covered by the cached policy from being used until the = max_age, or until a failure to send with all the covered servers. This should be a non-problem. The DNS record exists precisely to signal a requirement for "early" policy refresh. So when the domain's policy changes, the DNS record policy "id" SHOULD change to alert remote caches that the cached data is likely stale. This applies whether or not the change is to the list of acceptable "mx" hosts, or to some other property. > So you've pointed out a somewhat subtle pitfall. If I deploy a policy > with "mx: ['*.google.com']" and I later deploy additional MXs with > higher priority on mail.google.net (and, because I'm smart, I > remember to update my deployed policy), senders may nonetheless > only send mail to the old .com MXs, resulting in an unexpected > traffic imbalance. Only if you're negligent, and fail to modify the DNS record. Negligence can cause many other operational issues, there are no designs immune to operator negligence. > 2. This could be fixed if we said that senders MUST seek a > new policy whenever some MXs are filtered out by policy > application (5.2 step 2). That's both unnecessary, and problematic. The issue is that this condition is "sticky", until the policy matches the MX RRset, the sender is in a constant "refetch" condition. It is best to avoid this trigger. The DNS record triggers a single update, and then its "id" is cached with the same or any new policy. > 3. This is optionally fixed by senders refreshing cached > policies at an arbitrary time, which they may (but need not) > do. In addition to the text record trigger, senders should attempt to opportunistically (not triggered by DNS changes) refresh the policy at or after the midpoint between the last retry attempt and the expiration (but at least an ~1 hour after that attempt). Thus when a policy is published for 90 days, and then the policy server goes off-line, the retries would be (approx): <=3D 45 days left <=3D 22 days <=3D 11 days <=3D 6 days <=3D 3 days <=3D 36 hours <=3D 18 hours <=3D 9 hours <=3D 4 hours <=3D 2 hours <=3D 1 hour More retry attempts just short of expiration are likely pointless. --=20 Viktor.= From nobody Thu Feb 23 13:01:26 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4106B12A2DE for ; Thu, 23 Feb 2017 13:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=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 70n1t5y9MGil for ; Thu, 23 Feb 2017 13:01:21 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 512EC129AF7 for ; Thu, 23 Feb 2017 13:01:21 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id l19so1563013ywc.2 for ; Thu, 23 Feb 2017 13:01:21 -0800 (PST) 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=+lDIoqYkzAlUjPxmRnsq/OluRv6FyUm4cM1bGKlwkcs=; b=iQhLKfzIRJp9Vh0Bgm/ulRe0TgayFiNhQ/6opoomqmG73kiuhu92YPZMPikvGH7oLi n1a4KKSIhixtWN4+LLF05U0ARZnN2ue/uQf4ovAcJ40SoiA7kSojlrfK1M3Z6lp2R/z9 JObKQNFsIMfzOeagdO0xoFsFvMcvz2FaUkIWKtsNU8p9gPfILbJ5qvrVmiVKxn5bhIQR mwDg2W4W0q7y4RSzMElK8XUURbfP1dFhooB7fTJePTBvaK+CdEoWH04i/sg+6/AaX/y6 auL70ooUX5gHNwbD8CT6lV3FSQMFfAH6kdtiD7NlcdEzrw1/GsNRt0VStBjQEmjo/s8j CVXg== 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=+lDIoqYkzAlUjPxmRnsq/OluRv6FyUm4cM1bGKlwkcs=; b=m+WcTu0x9nB8mJFOAvuP80NqYPGpeSklog3186oD4wP7AeHZnx/0HBp6ZtjLoEnGbv Lx2jsX6QF0FEIeqSYPzbomUKq0q1HgcDDfYh7LPgXk5HmivB1RotwyoDUUS4TjExb3UN 7vE91ijHYp5sJJmt3llieqIjrLzsnSqxW0RvIdDdAdOXaZY2gZN9O6iPRdXlppdx5+fR PSUrnAvDdV9dJhrCoN7krjAPFk/6CI53tm+qsb+fmUzx/D2FKhzq87pvmOCESgoU50o2 fkNsiJhBdzfHfgGBrGoINKf2+KMeLhXGxMT3tMRb0S18ykrmhCoiWpLLIG+LIxPNVJvH Ihmg== X-Gm-Message-State: AMke39nd2vgNeVH1XST6tW/r4/azk51XB59dFBzrSlt3xKDDsomexDxbA1ugiX5jZD/luucV1KNq61er8CqN1/TC X-Received: by 10.129.167.71 with SMTP id e68mr29681851ywh.303.1487883679788; Thu, 23 Feb 2017 13:01:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.24.6 with HTTP; Thu, 23 Feb 2017 13:01:18 -0800 (PST) In-Reply-To: <813df83a-841e-4e6a-e3a1-f2852b20ddbc@bluepopcorn.net> References: <813df83a-841e-4e6a-e3a1-f2852b20ddbc@bluepopcorn.net> From: Daniel Margolis Date: Thu, 23 Feb 2017 23:01:18 +0200 Message-ID: To: Jim Fenton Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c146cb44218b8054938ea9f" Archived-At: Cc: "uta@ietf.org" Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 21:01:24 -0000 --94eb2c146cb44218b8054938ea9f Content-Type: multipart/alternative; boundary=94eb2c146cb433e095054938ea59 --94eb2c146cb433e095054938ea59 Content-Type: text/plain; charset=UTF-8 Hey, thanks for the feedback. Comments inline. On Wed, Feb 22, 2017 at 1:55 AM, Jim Fenton wrote: > Below are comments from my recent reading of draft-ietf-uta-mta-sts-03. > > The biggest concern I have is the relationship between the DNS TXT > record and the HTTPS policy record. The policy is hosted in HTTPS rather > directly in DNS in order to attempt to provide security without DNSSEC. > But if attacks on DNS are in the threat model, one has to consider that > an attacker might make it appear that there is not a DNS TXT record at > all, which causes the HTTPS record not to be retrieved at all (MTA STS > is presumed not to be deployed). This makes MTA STS too easy to defeat. > I don't believe I can speak to this with authority, but I feel somewhat comfortable excluding an *ever-present* active MITM from our threat model. It's certainly trivial to defeat initial policy discovery, but an attacker must do this all the time. It's feasible, but there's some probability of discovery, of course. > ===== > > Abstract > > Introduces the acronym for the specification as SMTP STS. Should > probably be MTA STS. Is MTA STS hyphenated? Document is inconsistent. > Thanks, good point. We originally used "SMTP STS" and at some point switched, apparently imperfectly. Sigh. ;) > 1.0 Introduction > > "...delete parts of the SMTP session..." -> "...delete or corrupt parts > of the SMTP session..." (in view of common firewall behavior to change > STARTTLS to XXXXXXXX). > > "...downgrade or interception attacks..." -> "...downgrade or MITM > attacks..." (interception is the motive or result, not the attack). > > 2.0. Related Technologies > > "In addition, SMTP STS provides..." -> "In addition, MTA STS > provides..." (and elsewhere in the document) > > 3.0. Policy Discovery > > If an attacker is able to spoof an NXDOMAIN response to the TXT record > request, MTA STS is ignored. This seems like a pretty serious problem in > the absence of DNSSEC, the use of which is of course not being assumed. > > 3.1. MTA-STS TXT records > > There is no IANA registry for reserved hostnames, which is why protocols > like SPF store their policies at the domain itself. Is there some reason > this is not being done here? The version field can be used to > distinguish from SPF records and other TXT records at the domain level. > This is reasonable, but note that we still require the special hostname for the HTTPS host (necessary since some domains will not want to host the HTTPS endpoint at the top-level); reusing it for the TXT record seems reasonable, no? I'm not wedded to this, but I would avoid unnecessary changes unless there's a good reason at this point. Is the risks of collision with a pre-existing record high? I would think not. (I'm lazy here because we already have various code that refers to this record name, and already changed it between version 2 and version 3 of the draft...) > "...are discarded" -> "...MUST be discarded" > > 3.2. MTA-STS Policies > > "mx": Why is there an emphasis on providing confirmation of the response > to the MX lookup, when it is just as easy to spoof the A/AAAA record > lookup that follows the MX and yet there is no publication of an A/AAAA > policy? > The "mx" constraint isn't really about the hostnames (though of course it is applied to them); it's about the subject of the server certificates presented by the MX. A different (albeit, I think, needlessly confusing!) design could allow for the MX hostnames to be arbitrary and not match the "mx" constraint in any way; all that matters is the certificate name, for exactly the reason you give. > "A lenient parser SHOULD accept...": For the protocol to be extensible, > this has to be "Parsers MUST accept..." > > "...SHALL be ignored" -> "...MUST be ignored" > > 3.3. HTTPS Policy Fetching > > Why MUST 3xx redirects not be followed? > This was an arbitrary choice to avoid confusion. If we allowed the following of redirects, is a policy behind an HTTPS redirect to a different domain valid? What about to a non-HTTPS endpoint? On the flip side, redirects allow easy delegation of policy hosting without SNI--I could serve a 302 to "https://policy.myisp.net" on " mta-sts.mydomain.com". If people think the latter is compelling, I'm open to it, but we should have a good answer to the questions I posed above about which redirect targets are valid. "A suggested timeout is one minute..." This could quickly tie up SMTP > client resources. Is there any mitigation for that? It also seems like a > long timeout. > We discussed timeouts quite a bit here previously, I think. One minute seemed reasonable to me in the context of https://www.ietf.org/rfc/rfc2821.txt, but I'm not really wedded to it. That said, it seems to me from that RFC that a standards-compliant message delivery can (end-to-end) take substantially longer than 1 minute, if I am reading correctly. > 4.2. MX Certificate Validation > > Is there a way to allow either CA-based validation or DANE for a > certificate that is presented? This seems to conflict with the use of > DANE-based certificate validation, or at least there is no order of > precedence for certificate validation. > As you probably remember, we did try to have an "either/or" kind of arrangement in the initial draft. It was a lot of extra complexity, I think, for little gain--MTA-STS with DANE certificate validation is sort of pointless, since DANE implies DNSSEC, which implies MX records are themselves signed. > 5.0. Policy Application > > "When a message fails to deliver...": How does the check for the updated > policy occur, by looking for an updated TXT record or by re-retrieving > the HTTPS policy? > By looking for an updated TXT record, as per section 3--but your question suggests we should clarify this. ;) > 5.2. Policy Application Control Flow > > In step 1, it is not clear whether the attempt to fetch a new policy > involves the TXT record or directly the HTTPS policy. > Yep, as above, I think. > In step 2, should some sort of warning be generated if the retrieved > MXes differ from the current policy, or is this considered normal? It > might be a sign of spoofing or misconfiguration. > See also David's comment and my reply under the thread "Updated drafts for MTA-STS & TLSRPT." We could leverage TLSRPT to report such cases, or force a check for a new policy, or both, I think. Thoughts? > 6.1. Policy Updates > > "...HTTPS endpoint has been updated but the TXT record has not yet > been...": Throughout this specification, no mention is made of DNS > caching of the TXT records. Should the records be published with > relatively short TTL, or relatively long TTL? It definitely has an > effect on how dynamic the domain's policy can be. > To restate your comment, if one anticipates publishing breaking new policies, then one must account for the lifetime of cached TXT records. So if one plans to do so in the near future, one should probably choose a short TTL. It's reasonable for us to call this out, I Think. > > 8. Security Considerations > > Item 2, falsification of A/AAAA responses can also be used to redirect > client connections to a rogue server. > > "Sender policy cache": It's not clear how this resists the blockage of > the TXT record. If the record is consistently blocked, the policy will > never be discovered to be cached. Also, caches are of finite size and > can not be expected to be kept consistently. If a client discovers a > policy with serial number "xxx", and then subsequently doesn't discover > a policy through the TXT record, what does it do? > Honor the cache. If a valid override of a cached policy is not found, a compliant sender must honor the cached policy. > Malicious MTA-STS TXT record: This seems to assume that the motive of > the attacker is to create a rogue MX server, but suppose the motive of > the attacker is instead to foil reception of email by the domain. Could > they accomplish this by publishing a bogus STS policy that makes all the > MX records look bad? This relates to the problem of not having an IANA > host name registry. > Only if they can host a policy on a HTTPS endpoint. We note the denial of service risk as well in this section, and some of the mitigations. > > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --94eb2c146cb433e095054938ea59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey, thanks for the feedback. Comments inline.=C2=A0

On Wed, Feb 22, 2017 at= 1:55 AM, Jim Fenton <fenton@bluepopcorn.net> wrote:
Below are comments from = my recent reading of draft-ietf-uta-mta-sts-03.

The biggest concern I have is the relationship between the DNS TXT
record and the HTTPS policy record. The policy is hosted in HTTPS rather directly in DNS in order to attempt to provide security without DNSSEC.
But if attacks on DNS are in the threat model, one has to consider that
an attacker might make it appear that there is not a DNS TXT record at
all, which causes the HTTPS record not to be retrieved at all (MTA STS
is presumed not to be deployed). This makes MTA STS too easy to defeat.
=

I don't believe I can speak to this wi= th authority, but I feel somewhat comfortable excluding an ever-present<= /i>=C2=A0active MITM from our threat model. It's certainly trivial to d= efeat initial policy discovery, but an attacker must do this all the time. = It's feasible, but there's some probability of discovery, of course= .=C2=A0
=C2=A0
=3D=3D=3D=3D=3D

Abstract

Introduces the acronym for the specification as SMTP STS. Should
probably be MTA STS. Is MTA STS hyphenated? Document is inconsistent.

Thanks, good point. We originally used "= ;SMTP STS" and at some point switched, apparently imperfectly. Sigh. ;= )=C2=A0
=C2=A0
1.0 Introduction

"...delete parts of the SMTP session..." -> "...delete or= corrupt parts
of the SMTP session..." (in view of common firewall behavior to change=
STARTTLS to XXXXXXXX).

"...downgrade or interception attacks..." -> "...downgrad= e or MITM
attacks..." (interception is the motive or result, not the attack).
2.0. Related Technologies

"In addition, SMTP STS provides..." -> "In addition, MTA = STS
provides..." (and elsewhere in the document)

3.0. Policy Discovery

If an attacker is able to spoof an NXDOMAIN response to the TXT record
request, MTA STS is ignored. This seems like a pretty serious problem in the absence of DNSSEC, the use of which is of course not being assumed.

3.1. MTA-STS TXT records

There is no IANA registry for reserved hostnames, which is why protocols like SPF store their policies at the domain itself. Is there some reason this is not being done here? The version field can be used to
distinguish from SPF records and other TXT records at the domain level.
=

This is reasonable, but note that we still= require the special hostname for the HTTPS host (necessary since some doma= ins will not want to host the HTTPS endpoint at the top-level); reusing it = for the TXT record seems reasonable, no? I'm not wedded to this, but I = would avoid unnecessary changes unless there's a good reason at this po= int. Is the risks of collision with a pre-existing record high? I would thi= nk not.=C2=A0

(I'm lazy here because we alread= y have various code that refers to this record name, and already changed it= between version 2 and version 3 of the draft...)=C2=A0
=C2=A0
"...are discarded" -> "...MUST be discarded"

3.2. MTA-STS Policies

"mx": Why is there an emphasis on providing confirmation of the r= esponse
to the MX lookup, when it is just as easy to spoof the A/AAAA record
lookup that follows the MX and yet there is no publication of an A/AAAA
policy?

The "mx" constraint i= sn't really about the hostnames (though of course it is applied to them= ); it's about the subject of the server certificates presented by the M= X. A different (albeit, I think, needlessly confusing!) design could allow = for the MX hostnames to be arbitrary and not match the "mx" const= raint in any way; all that matters is the certificate name, for exactly the= reason you give.=C2=A0
=C2=A0=C2=A0
"A lenient parser SHOULD accept...": For the protocol to be exten= sible,
this has to be "Parsers MUST accept..."

"...SHALL be ignored" -> "...MUST be ignored"

3.3. HTTPS Policy Fetching

Why MUST 3xx redirects not be followed?

This was an arbitrary choice to avoid confusion. If we allowed the followi= ng of redirects, is a policy behind an HTTPS redirect to a different domain= valid? What about to a non-HTTPS endpoint?=C2=A0

= On the flip side, redirects allow easy delegation of policy hosting without= SNI--I could serve a 302 to "htt= ps://policy.myisp.net" on "mta-sts.mydomain.com". If people think the latter is compell= ing, I'm open to it, but we should have a good answer to the questions = I posed above about which redirect targets are valid.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> "A suggested timeout is one minute..." This could quickly tie up = SMTP
client resources. Is there any mitigation for that? It also seems like a long timeout.

We discussed timeouts qui= te a bit here previously, I think. One minute seemed reasonable to me in th= e context of=C2=A0https://= www.ietf.org/rfc/rfc2821.txt, but I'm not really wedded to it. That= said, it seems to me from that RFC that a standards-compliant message deli= very can (end-to-end) take substantially longer than 1 minute, if I am read= ing correctly.
=C2=A0
4.2. MX Certificate Validation

Is there a way to allow either CA-based validation or DANE for a
certificate that is presented? This seems to conflict with the use of
DANE-based certificate validation, or at least there is no order of
precedence for certificate validation.

= As you probably remember, we did try to have an "either/or" kind = of arrangement in the initial draft. It was a lot of extra complexity, I th= ink, for little gain--MTA-STS with DANE certificate validation is sort of p= ointless, since DANE implies DNSSEC, which implies MX records are themselve= s signed.=C2=A0


5.0. Policy Application

"When a message fails to deliver...": How does the check for the = updated
policy occur, by looking for an updated TXT record or by re-retrieving
the HTTPS policy?

By looking for an upd= ated TXT record, as per section 3--but your question suggests we should cla= rify this. ;)=C2=A0
=C2=A0
5.2. Policy Application Control Flow

In step 1, it is not clear whether the attempt to fetch a new policy
involves the TXT record or directly the HTTPS policy.
=
Yep, as above, I think.=C2=A0
=C2=A0
In step 2, should some sort of warning be generated if the retrieved
MXes differ from the current policy, or is this considered normal? It
might be a sign of spoofing or misconfiguration.

<= /div>
See also David's comment and my reply under the thread "= Updated drafts for MTA-STS & TLSRPT."=C2=A0

We could leverage TLSRPT to report such cases, or force a check for a ne= w policy, or both, I think. Thoughts?
=C2=A0
6.1. Policy Updates

"...HTTPS endpoint has been updated but the TXT record has not yet
been...": Throughout this specification, no mention is made of DNS
caching of the TXT records. Should the records be published with
relatively short TTL, or relatively long TTL? It definitely has an
effect on how dynamic the domain's policy can be.
=
To restate your comment, if one anticipates publishing break= ing new policies, then one must account for the lifetime of cached TXT reco= rds.

So if one plans to do so in the near future, = one should probably choose a short TTL. It's reasonable for us to call = this out, I Think.=C2=A0
=C2=A0

8. Security Considerations

Item 2, falsification of A/AAAA responses can also be used to redirect
client connections to a rogue server.

"Sender policy cache": It's not clear how this resists the bl= ockage of
the TXT record. If the record is consistently blocked, the policy will
never be discovered to be cached. Also, caches are of finite size and
can not be expected to be kept consistently. If a client discovers a
policy with serial number "xxx", and then subsequently doesn'= t discover
a policy through the TXT record, what does it do?

=
Honor the cache. If a valid override of a cached policy is not f= ound, a compliant sender must honor the cached policy.=C2=A0
=C2= =A0
Malicious MTA-STS TXT record: This seems to assume that the motive of
the attacker is to create a rogue MX server, but suppose the motive of
the attacker is instead to foil reception of email by the domain. Could
they accomplish this by publishing a bogus STS policy that makes all the MX records look bad? This relates to the problem of not having an IANA
host name registry.

Only if they can ho= st a policy on a HTTPS endpoint. We note the denial of service risk as well= in this section, and some of the mitigations.=C2=A0
=C2=A0
=



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

--94eb2c146cb433e095054938ea59-- --94eb2c146cb44218b8054938ea9f Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDc2/f9tfMj6hLm d5lti1AziFa+nGPqIddXZHB7gWZHrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAyMjMyMTAxMjBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAXn6Wu7GcKI8oAp0HFQ0BWGVnuwVtTk+Q Eyio3C2hT9X7NpRc2MvoL+zDdo9Jd9vrX3PAxBhN5PK9+81yGNqMfHwN8JXvrNbWNHRenjAmY4CN IycMiB4G5ayEEDAApw/dbfNIZF4mPoXAmTutzwW+tQMHqx8II2BlrBOguEe488nCclWvluIVkubQ wIU5CWJK6bzbIlMu4IoLLNKVKJ4mJfKaChiPNMQpszd3G+4/ZCwjARrQgpFty8kDPgBogypw/5kt LRWelY010jnOncpyEFRYWXyYhrGAP4eQqJuZB5twy25syrvcdGiR1/num1N+hKuhg0HVAiWKIZwF /XjfMg== --94eb2c146cb44218b8054938ea9f-- From nobody Thu Feb 23 13:05:01 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A333F129B01 for ; Thu, 23 Feb 2017 13:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmsaU371nODq for ; Thu, 23 Feb 2017 13:04:57 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 101BE12999C for ; Thu, 23 Feb 2017 13:04:57 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id z61so1780710wrc.1 for ; Thu, 23 Feb 2017 13:04:56 -0800 (PST) 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=0YptmcMv1b4kZzbV98VCR0qkIZlXLXeI4K0I4UUUpZU=; b=dEImRbXIOwTF4j3qBbkE/up+QH5VpAez++J+menKUGJLD6rYL7DS5Gr6ZQM5YNUW0j QeJDJWz2yoQn3t8Ydi6xjunsje8aR4sk4O3RYz8+lhFhVCxIfzscpHd9SCYKZtByNLZp ChIbUpR9dkdJ/s5WwItmg4GjwDhy0KUtqz5unpw6E4iCEUTjWs+B3TIY6EQ3ZjieG+4A CrjJiRNHy8fsHxdXlK9nSF98rKviknCZ0gMQElJ9bQgJI9FCciTb8pL0nYQc5V1q3m3I C0LgVHKNbxENhHWRj0zKhE8W7NlI0aZOW7brCtP6q8EGics5Del6ZH3XW38YfFg/3YzU oshg== 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=0YptmcMv1b4kZzbV98VCR0qkIZlXLXeI4K0I4UUUpZU=; b=rPdQq3/XriP+0ENLkx5FxDnXOxC/s/no08kmZIU3OUsCeNvL0AnHjZ4pgiPqaRLwvH v9X7XD39YS417iXQZ0fUTBDPtDP7wMdI8h7EhSHwatEQjV/B5L090Cj6wRZ7ojNB0k3a IBGkQZFlvITPotfIrZWZDLOlY07PiaG3o1gLIz/J6NIjtCJfwdwliUd+F/prwdI0OchA wQWW6jbI6i3AM/oHZ0VGg8l3GconRFaCOQ6VGWR9pAoZKSvjEH1BZDVEfvVzY9qikP3e chhHPJBqcCfWv4S4tWcsdHMkgfJJriuohwHDuzS8gpTJb2lD2x1HbyBJ1Nq5Nqf8kBff cBmQ== X-Gm-Message-State: AMke39lil+4NvIcx2Sq7W46VWoV0+Mhg/ZdH9AMXCg1CoRMyhbPkxKmfPQ9bTEW+5J29BvI3XvqF5GRZrZEkHTum X-Received: by 10.223.134.52 with SMTP id 49mr5390984wrv.50.1487883894796; Thu, 23 Feb 2017 13:04:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.55.132 with HTTP; Thu, 23 Feb 2017 13:04:53 -0800 (PST) In-Reply-To: <905199AC-51EE-42E9-AB54-68C99578A03E@dukhovni.org> References: <905199AC-51EE-42E9-AB54-68C99578A03E@dukhovni.org> From: Daniel Margolis Date: Thu, 23 Feb 2017 23:04:53 +0200 Message-ID: To: "uta@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1146c03c0e7621054938f7b0" Archived-At: Subject: Re: [Uta] Updated drafts for MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 21:04:59 -0000 --001a1146c03c0e7621054938f7b0 Content-Type: multipart/alternative; boundary=001a1146c03c047f6f054938f74c --001a1146c03c047f6f054938f74c Content-Type: text/plain; charset=UTF-8 On Thu, Feb 23, 2017 at 11:00 PM, Viktor Dukhovni wrote: > > > On Feb 23, 2017, at 3:35 PM, Daniel Margolis > wrote: > > > >> 2. It prevents new MX records (eg new servers for increased capacity or > backups) not covered by the cached policy from being used until the > max_age, or until a failure to send with all the covered servers. > > This should be a non-problem. The DNS record exists precisely to signal > a requirement for "early" policy refresh. So when the domain's policy > changes, the DNS record policy "id" SHOULD change to alert remote caches > that the cached data is likely stale. > > This applies whether or not the change is to the list of acceptable "mx" > hosts, or to some other property. > Yes, but my point was that we don't (to my recollection) actually require senders to check for new policies on every mail send--they can legitimately keep using an old, cached policy as long as it works. As you say below, there are many optional strategies for senders to refresh policies in a reasonable way, so I am not of the opinion this is a fatal flaw. On whether it would be better to say senders SHOULD take one of these policies, though, I am open to feedback. > > > So you've pointed out a somewhat subtle pitfall. If I deploy a policy > > with "mx: ['*.google.com']" and I later deploy additional MXs with > > higher priority on mail.google.net (and, because I'm smart, I > > remember to update my deployed policy), senders may nonetheless > > only send mail to the old .com MXs, resulting in an unexpected > > traffic imbalance. > > Only if you're negligent, and fail to modify the DNS record. > Negligence can cause many other operational issues, there are > no designs immune to operator negligence. > > > 2. This could be fixed if we said that senders MUST seek a > > new policy whenever some MXs are filtered out by policy > > application (5.2 step 2). > > That's both unnecessary, and problematic. The issue is that > this condition is "sticky", until the policy matches the MX > RRset, the sender is in a constant "refetch" condition. It > is best to avoid this trigger. The DNS record triggers a > single update, and then its "id" is cached with the same > or any new policy. > > > 3. This is optionally fixed by senders refreshing cached > > policies at an arbitrary time, which they may (but need not) > > do. > > In addition to the text record trigger, senders should > attempt to opportunistically (not triggered by DNS > changes) refresh the policy at or after the midpoint > between the last retry attempt and the expiration (but > at least an ~1 hour after that attempt). > > Thus when a policy is published for 90 days, and then the > policy server goes off-line, the retries would be (approx): > > <= 45 days left > <= 22 days > <= 11 days > <= 6 days > <= 3 days > <= 36 hours > <= 18 hours > <= 9 hours > <= 4 hours > <= 2 hours > <= 1 hour > > More retry attempts just short of expiration are likely pointless. > > -- > Viktor. > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a1146c03c047f6f054938f74c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 23, 2017 at 11:00 PM, Viktor Dukhovni <= ;ietf-dane@dukh= ovni.org> wrote:

> On Feb 23, 2017, at 3:35 PM, Daniel Margolis <dmargolis@google.com> wrote:
>
>> 2. It prevents new MX records (eg new servers for increased capaci= ty or backups) not covered by the cached policy from being used until the m= ax_age, or until a failure to send with all the covered servers.

This should be a non-problem.=C2=A0 The DNS record exists precisely = to signal
a requirement for "early" policy refresh.=C2=A0 So when the domai= n's policy
changes, the DNS record policy "id" SHOULD change to alert remote= caches
that the cached data is likely stale.

This applies whether or not the change is to the list of acceptable "m= x"
hosts, or to some other property.

Yes, = but my point was that we don't (to my recollection) actually require se= nders to check for new policies on every mail send--they can legitimately k= eep using an old, cached policy as long as it works.=C2=A0

As you say below, there are many optional strategies for senders t= o refresh policies in a reasonable way, so I am not of the opinion this is = a fatal flaw. On whether it would be better to say senders SHOULD take one = of these policies, though, I am open to feedback.
=C2=A0

> So you've pointed out a somewhat subtle pitfall. If I deploy a pol= icy
> with "mx: ['*.google.com']" and I later deploy additiona= l MXs with
> higher priority on mail.google.net (and, because I'm smart, I
> remember to update my deployed policy), senders may nonetheless
> only send mail to the old .com MXs, resulting in an unexpected
> traffic imbalance.

Only if you're negligent, and fail to modify the DNS record.
Negligence can cause many other operational issues, there are
no designs immune to operator negligence.

> 2. This could be fixed if we said that senders MUST seek a
> new policy whenever some MXs are filtered out by policy
> application (5.2 step 2).

That's both unnecessary, and problematic.=C2=A0 The issue is tha= t
this condition is "sticky", until the policy matches the MX
RRset, the sender is in a constant "refetch" condition.=C2=A0 It<= br> is best to avoid this trigger.=C2=A0 The DNS record triggers a
single update, and then its "id" is cached with the same
or any new policy.

> 3. This is optionally fixed by senders refreshing cached
> policies at an arbitrary time, which they may (but need not)
> do.

In addition to the text record trigger, senders should
attempt to opportunistically (not triggered by DNS
changes) refresh the policy at or after the midpoint
between the last retry attempt and the expiration (but
at least an ~1 hour after that attempt).

Thus when a policy is published for 90 days, and then the
policy server goes off-line, the retries would be (approx):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 45 days left
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 22 days
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 11 days
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 6 days
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 3 days
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 36 hours
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 18 hours
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 9 hours
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 4 hours
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 2 hours
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 1 hour

More retry attempts just short of expiration are likely pointless.

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

--001a1146c03c047f6f054938f74c-- --001a1146c03c0e7621054938f7b0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCC4NNJZXvsjy44d 3zHjDeNmw1wdrFQ0EBI30K5TEbJ4mzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAyMjMyMTA0NTVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAUYeJKHI/8wLtxSGMmdKojV4vLc6MinNT DxtNKdvonJX8V5Vp5a/w9i4TGg+CPwEv7bV3jcRKwCIOHa+1QSPnXk5wgiVlIpxFHWySs6d10EXQ uiBHJqSuLYLuEbx+ULVrxWWdpuPrmlbyEI8GW0NPCfMVwUllH7oLEGFGF+8N6VmkR3CCD5j/nRIr 475aJ5Ob6oeVt8Gt+q+GfrsrcHokmlcMxTlvY0g5wThRd0BGnvlv9waad6Jw76Et6ye/8cDPcMda l9Ct+ITZTzGYo1Mm8WaUZwki8wKlCzlXW/lyiqwiWXWzSla8VDtoO5PhCRYRWSuDKvDZjR1Nhvew TXWg9Q== --001a1146c03c0e7621054938f7b0-- From nobody Thu Feb 23 13:14:07 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0595E129B05 for ; Thu, 23 Feb 2017 13:14:06 -0800 (PST) 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 Yq7EX5kVqR3K for ; Thu, 23 Feb 2017 13:14:04 -0800 (PST) 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 AF67712999C for ; Thu, 23 Feb 2017 13:14:04 -0800 (PST) Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id D165F7A330A for ; Thu, 23 Feb 2017 21:14:03 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 23 Feb 2017 16:14:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <46F3DACC-8C7C-4871-BC40-4CE97E0A4120@dukhovni.org> References: To: uta@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Uta] Updated drafts for MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: uta@ietf.org List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 21:14:06 -0000 > On Feb 23, 2017, at 3:35 PM, Daniel Margolis = wrote: >=20 >> Having pondered it a bit, my suggestion is: >> 1. A SHOULD that max_age is set to at least 6 months, other than = during roll-out >> 2. A SHOULD that well-behaved clients with a cached policy should = re-check DNS TXT policy weekly, and retrieve via HTTPS if the policy id = has changed. >=20 > I think the phrasing you give here suggests that if I send > mail to your domain less than once a week, I should run a > cron job to refresh the cache--and I hate cron jobs.=20 That's extremely unlikely to be implemented in Postfix, for example. To avoid a "roach motel" policy cache, refresh will be driven only by actual mail flow. The DNS record needs to be specified as the primary trigger for "early" refresh, wil an optional refresh when >50% of the time from last refresh to expiration has elapsed and sufficient (say 1 hour or more) time = remains that the policy isn't about to be refreshed due to actual expiration. A frequency cutoff avoids firing refresh triggers minutes or seconds apart close to expiration. > So to be slightly pedantic, would it work just as well to say senders > SHOULD check for an updated policy if using a policy which is older > than one week? (My phrasing may be unclear, but I mean, of course, > that they need only check for an updated policy if they are otherwise > sending mail to that domain anyway.) See proposed scheme. It has no artificial scale (1 week), and is = instead based on the policy lifetime. Sending systems should probably cap the policy lifetime on their end to something sensible (shorter for sites that send lots of mail, and are unlikely to not contact a given peer for a long time, longer for sites that don't send much mail). So if a receiving system advertises a 100-year policy, something more sensible will be stored in the sending side. > Of course, we could still simply suggest/require senders *always* > check for a new policy--it's one more DNS lookup to the recursive > resolver per-send--but I bet in some implementations there are > good reasons not to do this. If/when Postfix implements STS, the DNS id will be checked for each new SMTP connection. Changes in the DNS id will trigger (background) policy refresh. Non-changes in the DNS id will continue to use the cached policy until it is 50% closer to expiration since the last refresh (with a sensible cutoff). --=20 Viktor.= From nobody Thu Feb 23 13:21: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 42378129984 for ; Thu, 23 Feb 2017 13:21:42 -0800 (PST) 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 98NydvbqI1TS for ; Thu, 23 Feb 2017 13:21:40 -0800 (PST) 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 B83E41297F1 for ; Thu, 23 Feb 2017 13:21:40 -0800 (PST) Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 0A3087A330A for ; Thu, 23 Feb 2017 21:21:40 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 23 Feb 2017 16:21:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <94042B6B-F408-4C53-A831-F0912F117D64@dukhovni.org> References: <905199AC-51EE-42E9-AB54-68C99578A03E@dukhovni.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Uta] Updated drafts for MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: uta@ietf.org List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 21:21:42 -0000 > On Feb 23, 2017, at 4:04 PM, Daniel Margolis = wrote: >=20 >> This applies whether or not the change is to the list of acceptable = "mx" >> hosts, or to some other property. >=20 > Yes, but my point was that we don't (to my recollection) actually = require > senders to check for new policies on every mail send--they can = legitimately > keep using an old, cached policy as long as it works. Poorly crafted implementations will err in many interesting ways, but = with luck their users will clamour for fixes or switch to less broken = systems. The DNS lookup is cheap and should happen frequently, and doing so on = each SMTP connection should be recommended in the draft. > As you say below, there are many optional strategies for senders to = refresh > policies in a reasonable way, so I am not of the opinion this is a = fatal flaw. > On whether it would be better to say senders SHOULD take one of these = policies, > though, I am open to feedback. I think recommending well thought-out approaches to these issues is = useful: 1. It makes implementors think about the issues. 2. It gives them usable solutions that they can adopt or improve on. Nothing this proposed RFC can say will force compliance, the SMTP server is a passive actor in this space, and has no idea whether the client is using STS at all, let alone correctly. --=20 Viktor. From nobody Fri Feb 24 07:44: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 E402412983F for ; Fri, 24 Feb 2017 07:44:44 -0800 (PST) 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 1IXQGMHFfxtM for ; Fri, 24 Feb 2017 07:44:43 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 DD4C312970A for ; Fri, 24 Feb 2017 07:44:42 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id o22so10054097wro.1 for ; Fri, 24 Feb 2017 07:44:42 -0800 (PST) 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=QSkjF1jl+0cRVZZ1yJbEJRVVf6VKLt+SZT8jkZp7pYs=; b=XgbOAGp/B4GJx1lMVpzHOV4GpGXD2l7d/W50ewOweJYrOgf2Q/HCvmfETw9c+a0M6F yHzpHgAkfWsNbfhDWliViHfNqtDrR7MFsNDPssIlrwkfG3UmGrS6ot/g9m7DPS5goR8/ UgX7ctY1wGCdrZshVA52sU4zMg/AwrRS8QIm8TISeuc4wcr6tn7Gg298xJhy9uyx3B6B PpHHI4LFoiWlpmz7YlNZwtxBmMRNvyY19Ol7Hv+y92pcBigDsL0nNtJIfs+aj2Q7APGz 687gzSGqvG2VvhWasJ08RyUolCaRtUF4jlkcQDt4jX8LVxo/QpmjjYUCuT6d11lBWroe 0Ymg== 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=QSkjF1jl+0cRVZZ1yJbEJRVVf6VKLt+SZT8jkZp7pYs=; b=bDOT3Pms+jgPc7eKZUTn2zGMnq3CiTQJjn6iRcUBkhKhntBcdcgSOZHPNGeo6tjhMG c7Xbes4E4/D5r5o1usklHUqAIQiXlLPvAwxjCgDVMuXXe3RhXfhFvWaXjjDjF6xaPtC6 G3efFIrCjTivqEnE0Ouqy0/a1wlKj/6zigpktEiBA4he1HGY0gjyoBanqCAOti5co0wt Sbke3edwzPbjhWLcnYK7MMXbang6MbtkIeO0UfiChmX/3n+O4q17Hu4Wgl/EDSh8z0XI FlabfpGBPtokRf5vL7LCsgf6Y3zl1O+6BJ1HPjK7/ap6pU4AwvmNQ1uQSNIOskMbufIk aKZQ== X-Gm-Message-State: AMke39n4+e+mSwH7+stKmH93DaVRA3C8Rhh5/GjpMGjA9YQGgMMjVnGx3h4xZRf1K+y5tiRUhvky9g1bFmYKhWU5 X-Received: by 10.223.134.52 with SMTP id 49mr3101087wrv.50.1487951080740; Fri, 24 Feb 2017 07:44:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.55.132 with HTTP; Fri, 24 Feb 2017 07:44:39 -0800 (PST) In-Reply-To: <94042B6B-F408-4C53-A831-F0912F117D64@dukhovni.org> References: <905199AC-51EE-42E9-AB54-68C99578A03E@dukhovni.org> <94042B6B-F408-4C53-A831-F0912F117D64@dukhovni.org> From: Daniel Margolis Date: Fri, 24 Feb 2017 16:44:39 +0100 Message-ID: To: uta@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1146c03ca565a90549489b2e" Archived-At: Subject: Re: [Uta] Updated drafts for MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 15:44:45 -0000 --001a1146c03ca565a90549489b2e Content-Type: multipart/alternative; boundary=001a1146c03c9cac3d0549489b2f --001a1146c03c9cac3d0549489b2f Content-Type: text/plain; charset=UTF-8 Yes, I think we agree here. But presently the RFC doesn't really recommend frequent updating of the policy, AFAIR, though of course doing so is indeed cheap and a good idea. So we should recommend it! On Thu, Feb 23, 2017 at 10:21 PM, Viktor Dukhovni wrote: > > > On Feb 23, 2017, at 4:04 PM, Daniel Margolis > wrote: > > > >> This applies whether or not the change is to the list of acceptable "mx" > >> hosts, or to some other property. > > > > Yes, but my point was that we don't (to my recollection) actually require > > senders to check for new policies on every mail send--they can > legitimately > > keep using an old, cached policy as long as it works. > > Poorly crafted implementations will err in many interesting ways, but with > luck their users will clamour for fixes or switch to less broken systems. > > The DNS lookup is cheap and should happen frequently, and doing so on each > SMTP connection should be recommended in the draft. > > > As you say below, there are many optional strategies for senders to > refresh > > policies in a reasonable way, so I am not of the opinion this is a fatal > flaw. > > On whether it would be better to say senders SHOULD take one of these > policies, > > though, I am open to feedback. > > I think recommending well thought-out approaches to these issues is useful: > > 1. It makes implementors think about the issues. > 2. It gives them usable solutions that they can adopt or improve on. > > Nothing this proposed RFC can say will force compliance, the SMTP server > is a passive actor in this space, and has no idea whether the client is > using STS at all, let alone correctly. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a1146c03c9cac3d0549489b2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, I think we agree here. But presently the RFC doesn= 9;t really recommend frequent updating of the policy, AFAIR, though of cour= se doing so is indeed cheap and a good idea. So we should recommend it!=C2= =A0

On Thu, = Feb 23, 2017 at 10:21 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:

> On Feb 23, 2017, at 4:04 PM, Daniel Margolis <dmargolis@google.com> wrote:
>
>> This applies whether or not the change is to the list of acceptabl= e "mx"
>> hosts, or to some other property.
>
> Yes, but my point was that we don't (to my recollection) actually = require
> senders to check for new policies on every mail send--they can legitim= ately
> keep using an old, cached policy as long as it works.

Poorly crafted implementations will err in many interesting ways, bu= t with
luck their users will clamour for fixes or switch to less broken systems.
The DNS lookup is cheap and should happen frequently, and doing so on each<= br> SMTP connection should be recommended in the draft.

> As you say below, there are many optional strategies for senders to re= fresh
> policies in a reasonable way, so I am not of the opinion this is a fat= al flaw.
> On whether it would be better to say senders SHOULD take one of these = policies,
> though, I am open to feedback.

I think recommending well thought-out approaches to these issues is = useful:

=C2=A0 =C2=A01.=C2=A0 It makes implementors think about the issues.
=C2=A0 =C2=A02.=C2=A0 It gives them usable solutions that they can adopt or= improve on.

Nothing this proposed RFC can say will force compliance, the SMTP server is a passive actor in this space, and has no idea whether the client is
using STS at all, let alone correctly.

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

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

--001a1146c03c9cac3d0549489b2f-- --001a1146c03ca565a90549489b2e Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCvVWpRzYMumgmA PmKImmv/TPTsLs7zKAZ6l8zh8sc2UTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAyMjQxNTQ0NDFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAbJjHf2VGInF6p+AIrUYEkoFlqCXi1uCg 5D0dmhQ/GJzwsNjypdw7yBRursdgHEo43vq4I76slD5kO5snSCQr1OtQiwN7GAGNVdI5C49VM5Zb gdi3N5zg4BKbvkQeJeJgn2Je8RHYyg/L30HfkPv00nTi3iS2mg/Flu0OB7fkIJq4R+IDdnmG/33R HnI3FqKTaiBCtqzwl30Kqyp9BOBvZHZAv5DNS8t2Eod+WAnAiYUYXJM/ijaingmxIPmyAhZA0prx 2swUeH69nuAwNnkOckqj4ETok1iHB64RAzVxFMuEqQ6f0PS9UjF3QDCfMMXnWx6/UN99bExrIY9X 3gjVtg== --001a1146c03ca565a90549489b2e-- From nobody Fri Feb 24 12:33:37 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955131294EF for ; Fri, 24 Feb 2017 12:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GB_wOsBueB4K for ; Fri, 24 Feb 2017 12:33:33 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 9ACDD1294E3 for ; Fri, 24 Feb 2017 12:33:33 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id w44so21680543otw.2 for ; Fri, 24 Feb 2017 12:33:33 -0800 (PST) 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=kLOlPgE63bRfFG51JfvgOj4yH6pxArBcO4cUAWuHW8s=; b=GKlUtVhpWe8DOcKQPmsi9Mb2dexWlzfayBddTdjp84gexR1ei4R63Awy4bR+x/4T+i DOo2/y6/9wterVFgqt7rsgJZKMh2GopbS/k7tFl2SLhLhgRMtr4JnBP7p3iWOTW119y+ w/J50ZFBhE1dBAYe+huI2TplaQADAhskqrcE5ieib1+avVuLEf2cFttShR4od7b3qtAj WWZtscYvf8cmvFfwRgFRRHtDFF73d/Brl91PBH2D2v61Y75IptQff4AnO+PvadHLUOVK DOGD2PN9s+ubSVaw5Rcq213FbpNYVWrDZ4v/8jwZ9UhrNoGIgLD6GJQIuLW2XmRlC5Jm oNQQ== 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=kLOlPgE63bRfFG51JfvgOj4yH6pxArBcO4cUAWuHW8s=; b=i384V58NrxsuSNHb8nBSFYL1LEfQPiCBG2poB0uT8a+cVsz/nrPVW7cb6BJzTZL5WM Yq9SiesPvclOlQOJVnKKq0+Joa3q138x0YpCKMQRZSZfN6zi63iJGHQK/YAMFuRuCUnH xLFAm++ec1HhamUiQrSmFUl56JzFSuRmjhFuzUxcU2jm46uJnCOz+c/Rf59zyMWvRg4l Pc8ivg6SzYIQ2BQgDTc7sjoPatR87ePYEYlrRUQ0vEr6BNPvWmbYKFz3kvA1mrkpVtPb VTxYXKNwliuk/ztWZ2ITsW/VgyDGqi7vfSYfxJN05W28DyZU4gU4sMbxLHhXfqt1ZAfe nrYQ== X-Gm-Message-State: AMke39mn+ngOtCuYtNX9RjRMwwAVooVrymHPwpis9OK56qM9SsTVgvfIPBQvI8o10rbDrgsXNOKFr3ri5mVMrQ== X-Received: by 10.157.43.15 with SMTP id o15mr2928892otb.206.1487968413032; Fri, 24 Feb 2017 12:33:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.24.110 with HTTP; Fri, 24 Feb 2017 12:33:32 -0800 (PST) In-Reply-To: References: <905199AC-51EE-42E9-AB54-68C99578A03E@dukhovni.org> <94042B6B-F408-4C53-A831-F0912F117D64@dukhovni.org> From: David Illsley Date: Fri, 24 Feb 2017 20:33:32 +0000 Message-ID: To: Daniel Margolis Content-Type: multipart/alternative; boundary=001a113dc99eb22a3a05494ca4e6 Archived-At: Cc: uta@ietf.org Subject: Re: [Uta] Updated drafts for MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 20:33:35 -0000 --001a113dc99eb22a3a05494ca4e6 Content-Type: text/plain; charset=UTF-8 I think I agree with where you've got to, but I do want to clarify that I think it's important that a shorter refresh period doesn't shorten the policy expiry - we want a 6 month policy to be cached and relied on for 6 months, even if, for most of that 6 months an attacker is blocking a more frequent DNS policy check. On Fri, Feb 24, 2017 at 3:44 PM, Daniel Margolis wrote: > Yes, I think we agree here. But presently the RFC doesn't really recommend > frequent updating of the policy, AFAIR, though of course doing so is indeed > cheap and a good idea. So we should recommend it! > > On Thu, Feb 23, 2017 at 10:21 PM, Viktor Dukhovni > wrote: > >> >> > On Feb 23, 2017, at 4:04 PM, Daniel Margolis >> wrote: >> > >> >> This applies whether or not the change is to the list of acceptable >> "mx" >> >> hosts, or to some other property. >> > >> > Yes, but my point was that we don't (to my recollection) actually >> require >> > senders to check for new policies on every mail send--they can >> legitimately >> > keep using an old, cached policy as long as it works. >> >> Poorly crafted implementations will err in many interesting ways, but with >> luck their users will clamour for fixes or switch to less broken systems. >> >> The DNS lookup is cheap and should happen frequently, and doing so on each >> SMTP connection should be recommended in the draft. >> >> > As you say below, there are many optional strategies for senders to >> refresh >> > policies in a reasonable way, so I am not of the opinion this is a >> fatal flaw. >> > On whether it would be better to say senders SHOULD take one of these >> policies, >> > though, I am open to feedback. >> >> I think recommending well thought-out approaches to these issues is >> useful: >> >> 1. It makes implementors think about the issues. >> 2. It gives them usable solutions that they can adopt or improve on. >> >> Nothing this proposed RFC can say will force compliance, the SMTP server >> is a passive actor in this space, and has no idea whether the client is >> using STS at all, let alone correctly. >> >> -- >> Viktor. >> >> _______________________________________________ >> Uta mailing list >> Uta@ietf.org >> https://www.ietf.org/mailman/listinfo/uta >> > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > > --001a113dc99eb22a3a05494ca4e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think I agree with where you've got to, but I do wan= t to clarify that I think it's important that a shorter refresh period = doesn't shorten the policy expiry - we want a 6 month policy to be cach= ed and relied on for 6 months, even if, for most of that 6 months an attack= er is blocking a more frequent DNS policy check.

On Fri, Feb 24, 2017 at 3:44 PM, Da= niel Margolis <dmargolis@google.com> wrote:
Yes, I think we agree here. But prese= ntly the RFC doesn't really recommend frequent updating of the policy, = AFAIR, though of course doing so is indeed cheap and a good idea. So we sho= uld recommend it!=C2=A0

On Thu, Feb 23, 2017 at= 10:21 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wro= te:

> On Feb 23, 2017, at 4:04 PM, Daniel Margolis <dmargolis@google.com> wrote: >
>> This applies whether or not the change is to the list of acceptabl= e "mx"
>> hosts, or to some other property.
>
> Yes, but my point was that we don't (to my recollection) actually = require
> senders to check for new policies on every mail send--they can legitim= ately
> keep using an old, cached policy as long as it works.

Poorly crafted implementations will err in many interesting ways, bu= t with
luck their users will clamour for fixes or switch to less broken systems.
The DNS lookup is cheap and should happen frequently, and doing so on each<= br> SMTP connection should be recommended in the draft.

> As you say below, there are many optional strategies for senders to re= fresh
> policies in a reasonable way, so I am not of the opinion this is a fat= al flaw.
> On whether it would be better to say senders SHOULD take one of these = policies,
> though, I am open to feedback.

I think recommending well thought-out approaches to these issues is = useful:

=C2=A0 =C2=A01.=C2=A0 It makes implementors think about the issues.
=C2=A0 =C2=A02.=C2=A0 It gives them usable solutions that they can adopt or= improve on.

Nothing this proposed RFC can say will force compliance, the SMTP server is a passive actor in this space, and has no idea whether the client is
using STS at all, let alone correctly.

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

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


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


--001a113dc99eb22a3a05494ca4e6-- From nobody Fri Feb 24 13:04: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 AEDA51294FB for ; Fri, 24 Feb 2017 13:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLupCIpAi3kL for ; Fri, 24 Feb 2017 13:04:14 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::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 33A67129507 for ; Fri, 24 Feb 2017 13:04:14 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id w44so22159354otw.2 for ; Fri, 24 Feb 2017 13:04:14 -0800 (PST) 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=JGn8bnK9c8KIlqnWUQasdmzLBnMCWDJzYA+Sle8nul4=; b=ghOtABALkxzEGPZumyGolJlDhfhIW/Gigkb+XnwhfpHUz5KTRI/tZ0BnDsUIpVoDzj MPFKWxhnZXDohw7h6WYtQUKArREs8wMbOHrS0cspr5LDs9FySyVQFvS7CV/tVa1KV2wk SaljTKEBP/kQqSkblogjJQ3Wx+MiJYQH0TMH/8cgFT0v8rF2MGSinhltC6XUnLpscAOb 03Ol/4ss+ya9W20PKEkqR+WXgeq6g5p94UgOCEPp/1nKN6FryaMvTBlsFDo7pSdB/jS/ r9/3bMZcfYmqIMrb593aw+gO5RkI7LfKw/8Mdp9NsdXKTwTGAYiulTLmInPFdNvsO6EZ VYJQ== 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=JGn8bnK9c8KIlqnWUQasdmzLBnMCWDJzYA+Sle8nul4=; b=PzJHXxCMALBNsMjhYg900eZ/vzbx2lCn7wFjR0+1tl5IEseW8kGqfvtLCFhv5dL7NA wlk+S3HpBjyE4YXt1CPWET/XE88F+ustmi1s/xdxcxFAVxvP/UNr0TkOKSuJBySdbKgB 0ZH92A74TL5GWdCMXohfPc+9KFljZ5TaieY3ImjOhOrf4IKLsDz+QWFWWE0y/sITYigb jmSYuH6vehjMrea1AbPXSDuKFbVZ7tXgqLE5hPf7SIQjcatdLQ2cSNGdf87AeGwqxbvx uaHSJgcJnqRkvBGy941X0yI7dzMtU093ejLutlbd0fUh3PrEilo3eNcaAymn83PVeSem fc5g== X-Gm-Message-State: AMke39nSFbEKCz6nc21LZls9/dh9o4F79fB/hRAusYGaTKPNPppd2IWh4EVrCOIXBfEB40U37NqKO8filB2Y8A== X-Received: by 10.157.43.15 with SMTP id o15mr3001663otb.206.1487970253521; Fri, 24 Feb 2017 13:04:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.24.110 with HTTP; Fri, 24 Feb 2017 13:04:13 -0800 (PST) In-Reply-To: References: From: David Illsley Date: Fri, 24 Feb 2017 21:04:13 +0000 Message-ID: To: "Brotman, Alexander" Content-Type: multipart/alternative; boundary=001a113dc99e65c9c405494d1289 Archived-At: Cc: "uta@ietf.org" Subject: Re: [Uta] Updated drafts for MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 21:04:15 -0000 --001a113dc99e65c9c405494d1289 Content-Type: text/plain; charset=UTF-8 On: "1) Remove the "_" from DNS records to be consistent with A/AAAA records used with the HTTPS retrieval, and make this a bit less confusing for deployments. We did this for both MTA-STS and TLSRPT." Having just tried to implement this, I bumped into a problem that I can't use a CNAME to an ELB for the https bit and set the TXT record in the same zone because it has the same DNS name and CNAME is special. Have I missed something, or does this mean it's not possible to use CNAMEs for hosting the policy document? If so, I think that's going to be a pretty painful blocker for a lot of people. Cheers, David On Wed, Feb 15, 2017 at 7:57 PM, Brotman, Alexander < Alexander_Brotman@comcast.com> wrote: > Folks, > > We uploaded new revisions for MTA-STS and TLSRPT. There are minor changes > to each: > > 1) Remove the "_" from DNS records to be consistent with A/AAAA records > used with the HTTPS retrieval, and make this a bit less confusing for > deployments. We did this for both MTA-STS and TLSRPT. > 2) Clarify language around punycode > > Please give these a review and get back to us with any comments. Thank > you. > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse > Comcast > x5364 > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > --001a113dc99e65c9c405494d1289 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On: "1) Remove the "_" = from DNS records to be consistent with A/AAAA records=20 used with the HTTPS retrieval, and make this a bit less confusing for=20 deployments.=C2=A0 We did this for both MTA-STS and TLSRPT."

Having just tried to implement this, I bumped into a problem that I can= 't use a CNAME to an ELB for the https bit and set the TXT record in th= e same zone because it has the same DNS name and CNAME is special.

<= /div>Have I missed something, or does this mean it's not possible to us= e CNAMEs for hosting the policy document? If so, I think that's going t= o be a pretty painful blocker for a lot of people.

Cheers,
=
David




On Wed, Feb 15, 2017 at 7:57 PM, Brot= man, Alexander <Alexander_Brotman@comcast.com> w= rote:
Folks,

We uploaded new revisions for MTA-STS and TLSRPT.=C2=A0 There are minor cha= nges to each:

1) Remove the "_" from DNS records to be consistent with A/AAAA r= ecords used with the HTTPS retrieval, and make this a bit less confusing fo= r deployments.=C2=A0 We did this for both MTA-STS and TLSRPT.
2) Clarify language around punycode

Please give these a review and get back to us with any comments.=C2=A0 Than= k you.

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


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

--001a113dc99e65c9c405494d1289-- From nobody Fri Feb 24 13:43:29 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FA5129513 for ; Fri, 24 Feb 2017 13:43:27 -0800 (PST) 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 s2aun_xnAAB8 for ; Fri, 24 Feb 2017 13:43:26 -0800 (PST) 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 D005A1294F8 for ; Fri, 24 Feb 2017 13:43:25 -0800 (PST) Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id A93EC7A330A for ; Fri, 24 Feb 2017 21:43:24 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 24 Feb 2017 16:43:23 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <905199AC-51EE-42E9-AB54-68C99578A03E@dukhovni.org> <94042B6B-F408-4C53-A831-F0912F117D64@dukhovni.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Uta] Updated drafts for MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: uta@ietf.org List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 21:43:27 -0000 > On Feb 24, 2017, at 3:33 PM, David Illsley wrote: > > I think I agree with where you've got to, but I do want to clarify > that I think it's important that a shorter refresh period doesn't > shorten the policy expiry - we want a 6 month policy to be cached > and relied on for 6 months, even if, for most of that 6 months an > attacker is blocking a more frequent DNS policy check. That's a given, modulo local policy on the sending side that might set a lower ceiling on the length of time for which policies are allowed be cached. Remote systems should not be able to force cache storage indefinitely. The effective cache lifetime will be the lower of the remotely requested lifetime and the local policy ceiling. Refresh failure with periodic probing does not invalidate already cached unexpired data. If you feel this needs to be said explicitly, that's OK. It seemed pretty obvious to me. -- Viktor. From nobody Mon Feb 27 02:24: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 17B7F129CE6 for ; Mon, 27 Feb 2017 02:24:36 -0800 (PST) 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 RcaVOtF-iged for ; Mon, 27 Feb 2017 02:24:34 -0800 (PST) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::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 B22CB12943D for ; Mon, 27 Feb 2017 02:24:34 -0800 (PST) Received: by mail-yb0-x22c.google.com with SMTP id l4so9163286ybl.3 for ; Mon, 27 Feb 2017 02:24:34 -0800 (PST) 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=V/A/MWOwVHhnXGP+qCFUde3AtW3J2K8ehkMhETPsI5s=; b=nGP7BkhkE7grUovyCPMfTZmQYYsf2Eo1VRTEgBxCgSnSE0j64BzHatxgDiItg3BOII c9TdzunHpvXpH9UMoZYRLq0gn0IpAzHueD/Tkx57W9sKv+id7zA0xZa4QKlBn0dkkV+M l9pHOV2oLji/4KC9ZIVk5O5IMwPIEDwSRlMVT2nU608qhjw/5A7uNDb/A50F7y7frR1X 7teNyO3UYfTcup2JxqrZuhBxMJ0Z1Z/l0efIFkU5rQQ/N1Z9JnO8zL+PApfAf/2gwJie iV5LA6N4aX7SfGHrb2TeJoMrkmd82wG2LwSXp28U7+yokFJ/KlQjDye/XuGZR9ZV6npQ 6FmA== 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=V/A/MWOwVHhnXGP+qCFUde3AtW3J2K8ehkMhETPsI5s=; b=pANNJSz9m3ztQPBz+fO8OU1+4yHJTlO9W/+Arsc2GAJuToOK3oFPvwGWkyqiXd9zY0 puaRKn8I7NmrpQA8B9uPK3VA76KWV64708Xz2hvWuPQ4+EuQRyn+Syre3nDETUXFn/7B ngaa3GU/X8tTEzJ3mDM6gi1zrIJdnLRw4NQCGz2G2TremLdqTVBCuq90osw5I7c2286x L0TnVIP4sz0B71hIZ9FhFnUS09SG54huZAeWPNY4g7R3h2040iAFU+lShL3KEhL6ym31 +M4IMmmvhKei/dNaGnQTdm1ZERsqUBwuzG7PG3+I+dMHHBin7BqdLvbNw/gMTDetuVZc B+UQ== X-Gm-Message-State: AMke39nC43L6sGV/hTEO2JbSHuFwLuJ2P/wnfzJDuLpKHeKFyXbIJ79TIpuF8dFCV3gj/EgkGMMGrmFZrYrpwdZL X-Received: by 10.37.68.214 with SMTP id r205mr10656194yba.14.1488190705419; Mon, 27 Feb 2017 02:18:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.24.6 with HTTP; Mon, 27 Feb 2017 02:18:24 -0800 (PST) In-Reply-To: References: From: Daniel Margolis Date: Mon, 27 Feb 2017 11:18:24 +0100 Message-ID: To: David Illsley Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113f4d1a53fcc40549807cbd" Archived-At: Cc: "uta@ietf.org" , "Brotman, Alexander" Subject: Re: [Uta] Updated drafts for MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 10:24:36 -0000 --001a113f4d1a53fcc40549807cbd Content-Type: multipart/alternative; boundary=001a113f4d1a5b3f4e0549806606 --001a113f4d1a5b3f4e0549806606 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 24, 2017 at 10:04 PM, David Illsley wrote: > Having just tried to implement this, I bumped into a problem that I can't > use a CNAME to an ELB for the https bit and set the TXT record in the same > zone because it has the same DNS name and CNAME is special. > > Have I missed something, or does this mean it's not possible to use CNAMEs > for hosting the policy document? If so, I think that's going to be a pretty > painful blocker for a lot of people. > Oh, damn. I'd forgotten you can't have a CNAME where another record exists, but yeah, you can't. And I don't think that's desirable--we should support CNAMEs here, obviously. So let's undo that change. *sigh* --001a113f4d1a5b3f4e0549806606 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Feb 24, 2017 at 10:04 PM, David Illsley <davidillsley@gmail.c= om> wrote:
Having just= tried to implement this, I bumped into a problem that I can't use a CN= AME to an ELB for the https bit and set the TXT record in the same zone bec= ause it has the same DNS name and CNAME is special.

Have I mis= sed something, or does this mean it's not possible to use CNAMEs for ho= sting the policy document? If so, I think that's going to be a pretty p= ainful blocker for a lot of people.

Oh, damn. I&#= 39;d forgotten you can't have a CNAME where another record exists, but = yeah, you can't. And I don't think that's desirable--we should = support CNAMEs here, obviously.=C2=A0

<= /div>
So let's undo that change. *sigh*
=
--001a113f4d1a5b3f4e0549806606-- --001a113f4d1a53fcc40549807cbd Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+ q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0 TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg 5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27 8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAZdg1nojYBxqgl jo8Bhac7259Xe+IMWqSseU/QxFOhbjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAyMjcxMDI0MzRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAGGdQ4YYmLukaPOoHzJpwpNC/QkE2FxYo yDIkY6X1eZ67hjyXrnMa/j/N9TP81o1DJ/WznqTEBECM5sC9PFtsyg1X/V0TelMtrGMwsLAaWyyT ZDOx6ZMUvz3IMYLQEhdfUuL2WRReX9oeVuEF369FoVTmywdwLTWh6MCkvnYau70SbMvUr+HGioGW S6n6g4Zj1JA7H+D5t9Fl9jaCrSfgOGF61dWi8F2FhJMjehQ8Od3M5E3bP52RWXpSFNRcuRoO/rWj JnrW1M+7K4F2Tg2jZLyKR8JjHMOoWPaIiZIo6oP+mUjM1RfCzgxKSEw8ShAVs202RimDkkxwYQtg dr+wOQ== --001a113f4d1a53fcc40549807cbd-- From nobody Mon Feb 27 13:46:27 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D07712A34C for ; Mon, 27 Feb 2017 13:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 g4eCzq7DgEgd for ; Mon, 27 Feb 2017 13:46:23 -0800 (PST) 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 E1A091293DC for ; Mon, 27 Feb 2017 13:46:23 -0800 (PST) Received: from [IPv6:2601:647:4001:a0c0:d4f7:e950:e672:8e08] ([IPv6:2601:647:4001:a0c0:d4f7:e950:e672:8e08]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v1RLkLon019604 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 27 Feb 2017 13:46:22 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1488231983; bh=m1QY6RJBXsZZssielr8gtYsnwhA8WPeiKMy2mNpFy7Q=; h=Subject:To:References:From:Date:In-Reply-To; b=hJjB6FVUNE3/+/Rxd0ODq2pasIcuwlsJKqI7xZlm8vdo9Jgz6QK7XR3RePmaevqj/ czun4DeVVvz24tsSHgLn6+gzsvtNhr3cXIPVaxT/XB7c6Nfupv/8R1W/0IyJf6eqKu PKntsEu9ZbeDtpLNo+3kgF8RUKFBmVHrzCPqAdVU= To: uta@ietf.org References: <813df83a-841e-4e6a-e3a1-f2852b20ddbc@bluepopcorn.net> From: Jim Fenton Message-ID: <2c2520c9-3068-cd07-6c44-861a19fea458@bluepopcorn.net> Date: Mon, 27 Feb 2017 13:46:16 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D1C67D390FE214A2C8B5D345" Archived-At: Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 21:46:26 -0000 This is a multi-part message in MIME format. --------------D1C67D390FE214A2C8B5D345 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/23/2017 01:01 PM, Daniel Margolis wrote: > Hey, thanks for the feedback. Comments inline.=20 > > On Wed, Feb 22, 2017 at 1:55 AM, Jim Fenton > wrote: > > Below are comments from my recent reading of > draft-ietf-uta-mta-sts-03. > > The biggest concern I have is the relationship between the DNS TXT > record and the HTTPS policy record. The policy is hosted in HTTPS > rather > directly in DNS in order to attempt to provide security without > DNSSEC. > But if attacks on DNS are in the threat model, one has to consider > that > an attacker might make it appear that there is not a DNS TXT record= at > all, which causes the HTTPS record not to be retrieved at all (MTA = STS > is presumed not to be deployed). This makes MTA STS too easy to > defeat. > > > I don't believe I can speak to this with authority, but I feel > somewhat comfortable excluding an /ever-present/ active MITM from our > threat model. It's certainly trivial to defeat initial policy > discovery, but an attacker must do this all the time. It's feasible, > but there's some probability of discovery, of course. It's not that the attack has to be ever-present, it's that client MTAs that don't have a cached policy for the recipient domain will be showing up all the time, and will need to retrieve the policy. To the extent that they don't get the TXT record on the first try, they will infer that there is no policy, and will continue to do so while the negative response is cached by their responder (minimum TTL, typically only a few minutes, but the SOA in the NXDOMAIN response could also be spoofed to make this much longer). This waters down the effectiveness of MTA STS. > 3.1. MTA-STS TXT records > > There is no IANA registry for reserved hostnames, which is why > protocols > like SPF store their policies at the domain itself. Is there some > reason > this is not being done here? The version field can be used to > distinguish from SPF records and other TXT records at the domain > level. > > > This is reasonable, but note that we still require the special > hostname for the HTTPS host (necessary since some domains will not > want to host the HTTPS endpoint at the top-level); reusing it for the > TXT record seems reasonable, no? I'm not wedded to this, but I would > avoid unnecessary changes unless there's a good reason at this point. > Is the risks of collision with a pre-existing record high? I would > think not.=20 > > (I'm lazy here because we already have various code that refers to > this record name, and already changed it between version 2 and version > 3 of the draft...) It looks like the _ may be coming back as a result of the CNAME problem noted on the other discussion thread. But the point is that IETF/IANA have consistently declined to register specific hostnames for specific purposes -- not even www. for the Web -- and I don't see why an exception would be made now. > =20 > > "...are discarded" -> "...MUST be discarded" > > 3.2. MTA-STS Policies > > "mx": Why is there an emphasis on providing confirmation of the > response > to the MX lookup, when it is just as easy to spoof the A/AAAA recor= d > lookup that follows the MX and yet there is no publication of an > A/AAAA > policy? > > > The "mx" constraint isn't really about the hostnames (though of course > it is applied to them); it's about the subject of the server > certificates presented by the MX. A different (albeit, I think, > needlessly confusing!) design could allow for the MX hostnames to be > arbitrary and not match the "mx" constraint in any way; all that > matters is the certificate name, for exactly the reason you give. Fair enough -- the certificate name addresses the A/AAAA issue. > > 3.3. HTTPS Policy Fetching > > Why MUST 3xx redirects not be followed? > > > This was an arbitrary choice to avoid confusion. If we allowed the > following of redirects, is a policy behind an HTTPS redirect to a > different domain valid? What about to a non-HTTPS endpoint?=20 > > On the flip side, redirects allow easy delegation of policy hosting > without SNI--I could serve a 302 to "https://policy.myisp.net" on > "mta-sts.mydomain.com ". If people think > the latter is compelling, I'm open to it, but we should have a good > answer to the questions I posed above about which redirect targets are > valid. I was mostly asking that there be some explanation of the "no 3xx" thing. Unless it introduces a definite security vulnerability, it's worth considering whether there are email use cases that would be easier to set up. You could potentially just prohibit redirect to non-HTTPS, although a non-HTTPS policy might still be better than nothing. > > "A suggested timeout is one minute..." This could quickly tie up SM= TP > client resources. Is there any mitigation for that? It also seems > like a > long timeout. > > > We discussed timeouts quite a bit here previously, I think. One minute > seemed reasonable to me in the context > of https://www.ietf.org/rfc/rfc2821.txt, but I'm not really wedded to > it. That said, it seems to me from that RFC that a standards-compliant > message delivery can (end-to-end) take substantially longer than 1 > minute, if I am reading correctly. Rather than (or in addition to) a specific value, it might be better to have some guidelines on choosing the proper value in various situations. > =20 > > 4.2. MX Certificate Validation > > Is there a way to allow either CA-based validation or DANE for a > certificate that is presented? This seems to conflict with the use = of > DANE-based certificate validation, or at least there is no order of= > precedence for certificate validation. > > > As you probably remember, we did try to have an "either/or" kind of > arrangement in the initial draft. It was a lot of extra complexity, I > think, for little gain--MTA-STS with DANE certificate validation is > sort of pointless, since DANE implies DNSSEC, which implies MX records > are themselves signed. So what takes precedence: if there is a DANE policy, is MTA-STS ignored? > > > 5.0. Policy Application > > "When a message fails to deliver...": How does the check for the > updated > policy occur, by looking for an updated TXT record or by re-retriev= ing > the HTTPS policy? > > > By looking for an updated TXT record, as per section 3--but your > question suggests we should clarify this. ;) Yes, but Viktor's observation on the other thread (that TXT record lookups are cheap) applies here so maybe just start all the flows with a TXT record lookup. > =20 > > 5.2. Policy Application Control Flow > > In step 1, it is not clear whether the attempt to fetch a new polic= y > involves the TXT record or directly the HTTPS policy. > > > Yep, as above, I think.=20 > =20 > > In step 2, should some sort of warning be generated if the retrieve= d > MXes differ from the current policy, or is this considered normal? = It > might be a sign of spoofing or misconfiguration. > > > See also David's comment and my reply under the thread "Updated drafts > for MTA-STS & TLSRPT."=20 > > We could leverage TLSRPT to report such cases, or force a check for a > new policy, or both, I think. Thoughts? Will get into this once I have had a chance to review TLSRPT. -Jim --------------D1C67D390FE214A2C8B5D345 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 02/23/2017 01:01 PM, Daniel Margolis wrote:
Hey, thanks for the feedback. Comments inline. 

On Wed, Feb 22, 2017 at 1:55 AM, Jim Fenton <fenton@bluepopcorn.net> wrote:
Below are comments from my recent reading of draft-ietf-uta-mta-sts-03.

The biggest concern I have is the relationship between the DNS TXT
record and the HTTPS policy record. The policy is hosted in HTTPS rather
directly in DNS in order to attempt to provide security without DNSSEC.
But if attacks on DNS are in the threat model, one has to consider that
an attacker might make it appear that there is not a DNS TXT record at
all, which causes the HTTPS record not to be retrieved at all (MTA STS
is presumed not to be deployed). This makes MTA STS too easy to defeat.

I don't believe I can speak to this with authority, but I feel somewhat comfortable excluding an ever-present active MITM from our threat model. It's certainly trivial to defeat initial policy discovery, but an attacker must do this all the time. It's feasible, but there's some probability of discovery, of course.

It's not that the attack has to be ever-present, it's that client MTAs that don't have a cached policy for the recipient domain will be showing up all the time, and will need to retrieve the policy. To the extent that they don't get the TXT record on the first try, they will infer that there is no policy, and will continue to do so while the negative response is cached by their responder (minimum TTL, typically only a few minutes, but the SOA in the NXDOMAIN response could also be spoofed to make this much longer). This waters down the effectiveness of MTA STS.

3.1. MTA-STS TXT records

There is no IANA registry for reserved hostnames, which is why protocols
like SPF store their policies at the domain itself. Is there some reason
this is not being done here? The version field can be used to
distinguish from SPF records and other TXT records at the domain level.

This is reasonable, but note that we still require the special hostname for the HTTPS host (necessary since some domains will not want to host the HTTPS endpoint at the top-level); reusing it for the TXT record seems reasonable, no? I'm not wedded to this, but I would avoid unnecessary changes unless there's a good reason at this point. Is the risks of collision with a pre-existing record high? I would think not. 

(I'm lazy here because we already have various code that refers to this record name, and already changed it between version 2 and version 3 of the draft...)

It looks like the _ may be coming back as a result of the CNAME problem noted on the other discussion thread. But the point is that IETF/IANA have consistently declined to register specific hostnames for specific purposes -- not even www. for the Web -- and I don't see why an exception would be made now.

 
"...are discarded" -> "...MUST be discarded"

3.2. MTA-STS Policies

"mx": Why is there an emphasis on providing confirmation of the response
to the MX lookup, when it is just as easy to spoof the A/AAAA record
lookup that follows the MX and yet there is no publication of an A/AAAA
policy?

The "mx" constraint isn't really about the hostnames (though of course it is applied to them); it's about the subject of the server certificates presented by the MX. A different (albeit, I think, needlessly confusing!) design could allow for the MX hostnames to be arbitrary and not match the "mx" constraint in any way; all that matters is the certificate name, for exactly the reason you give.

Fair enough -- the certificate name addresses the A/AAAA issue.


3.3. HTTPS Policy Fetching

Why MUST 3xx redirects not be followed?

This was an arbitrary choice to avoid confusion. If we allowed the following of redirects, is a policy behind an HTTPS redirect to a different domain valid? What about to a non-HTTPS endpoint? 

On the flip side, redirects allow easy delegation of policy hosting without SNI--I could serve a 302 to "https://policy.myisp.net" on "mta-sts.mydomain.com". If people think the latter is compelling, I'm open to it, but we should have a good answer to the questions I posed above about which redirect targets are valid.

I was mostly asking that there be some explanation of the "no 3xx" thing. Unless it introduces a definite security vulnerability, it's worth considering whether there are email use cases that would be easier to set up. You could potentially just prohibit redirect to non-HTTPS, although a non-HTTPS policy might still be better than nothing.

"A suggested timeout is one minute..." This could quickly tie up SMTP
client resources. Is there any mitigation for that? It also seems like a
long timeout.

We discussed timeouts quite a bit here previously, I think. One minute seemed reasonable to me in the context of https://www.ietf.org/rfc/rfc2821.txt, but I'm not really wedded to it. That said, it seems to me from that RFC that a standards-compliant message delivery can (end-to-end) take substantially longer than 1 minute, if I am reading correctly.

Rather than (or in addition to) a specific value, it might be better to have some guidelines on choosing the proper value in various situations.

 
4.2. MX Certificate Validation

Is there a way to allow either CA-based validation or DANE for a
certificate that is presented? This seems to conflict with the use of
DANE-based certificate validation, or at least there is no order of
precedence for certificate validation.

As you probably remember, we did try to have an "either/or" kind of arrangement in the initial draft. It was a lot of extra complexity, I think, for little gain--MTA-STS with DANE certificate validation is sort of pointless, since DANE implies DNSSEC, which implies MX records are themselves signed.

So what takes precedence: if there is a DANE policy, is MTA-STS ignored?



5.0. Policy Application

"When a message fails to deliver...": How does the check for the updated
policy occur, by looking for an updated TXT record or by re-retrieving
the HTTPS policy?

By looking for an updated TXT record, as per section 3--but your question suggests we should clarify this. ;)

Yes, but Viktor's observation on the other thread (that TXT record lookups are cheap) applies here so maybe just start all the flows with a TXT record lookup.

 
5.2. Policy Application Control Flow

In step 1, it is not clear whether the attempt to fetch a new policy
involves the TXT record or directly the HTTPS policy.

Yep, as above, I think. 
 
In step 2, should some sort of warning be generated if the retrieved
MXes differ from the current policy, or is this considered normal? It
might be a sign of spoofing or misconfiguration.

See also David's comment and my reply under the thread "Updated drafts for MTA-STS & TLSRPT." 

We could leverage TLSRPT to report such cases, or force a check for a new policy, or both, I think. Thoughts?

Will get into this once I have had a chance to review TLSRPT.

-Jim


--------------D1C67D390FE214A2C8B5D345-- From nobody Mon Feb 27 18:49: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 446311294A5 for ; Mon, 27 Feb 2017 18:49:21 -0800 (PST) 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 2_OZN0TxCMws for ; Mon, 27 Feb 2017 18:49:19 -0800 (PST) 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 92CDF129476 for ; Mon, 27 Feb 2017 18:49:19 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3C50A7A330D; Tue, 28 Feb 2017 02:49:18 +0000 (UTC) Date: Tue, 28 Feb 2017 02:49:18 +0000 From: Viktor Dukhovni To: uta@ietf.org Message-ID: <20170228024917.GF7733@mournblade.imrryr.org> References: <813df83a-841e-4e6a-e3a1-f2852b20ddbc@bluepopcorn.net> <2c2520c9-3068-cd07-6c44-861a19fea458@bluepopcorn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2c2520c9-3068-cd07-6c44-861a19fea458@bluepopcorn.net> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: uta@ietf.org List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 02:49:21 -0000 On Mon, Feb 27, 2017 at 01:46:16PM -0800, Jim Fenton wrote: > > I don't believe I can speak to this with authority, but I feel > > somewhat comfortable excluding an /ever-present/ active MITM from our > > threat model. It's certainly trivial to defeat initial policy > > discovery, but an attacker must do this all the time. It's feasible, > > but there's some probability of discovery, of course. > > It's not that the attack has to be ever-present, it's that client MTAs > that don't have a cached policy for the recipient domain will be showing > up all the time, and will need to retrieve the policy. To the extent > that they don't get the TXT record on the first try, they will infer > that there is no policy, and will continue to do so while the negative > response is cached by their responder (minimum TTL, typically only a few > minutes, but the SOA in the NXDOMAIN response could also be spoofed to > make this much longer). This waters down the effectiveness of MTA STS. This is a fundamental limitation of STS. STS cannot protect first contact. There is no reasonable way to design around this. If you want downgrade resistance, deploy DANE. > > The "mx" constraint isn't really about the hostnames (though of course > > it is applied to them); it's about the subject of the server > > certificates presented by the MX. A different (albeit, I think, > > needlessly confusing!) design could allow for the MX hostnames to be > > arbitrary and not match the "mx" constraint in any way; all that > > matters is the certificate name, for exactly the reason you give. > > Fair enough -- the certificate name addresses the A/AAAA issue. Indeed constraining the names in the certificate is exactly how mandatory TLS policy works in Postfix. We don't filter the MX hostnames, rather the destination policy can filter the acceptable certificate names regardless of the MX hostname. http://www.postfix.org/postconf.5.html#smtp_tls_secure_cert_match Filtering the MX hostnames is an indirect way of solving the same underlying problem. Perhaps "mx" should be renamed to "san" and MX host selection then completely decouples from the security policy. When the connection is to a host whose certificate is not suitable, the client hangs up and tries another MX host (up to whatever limits on the number of such attempts are applicable). Since this simplifies the protocol, and reduces the code changes needed in MTAs, it is worth considering. > > As you probably remember, we did try to have an "either/or" kind of > > arrangement in the initial draft. It was a lot of extra complexity, I > > think, for little gain--MTA-STS with DANE certificate validation is > > sort of pointless, since DANE implies DNSSEC, which implies MX records > > are themselves signed. > > So what takes precedence: if there is a DANE policy, is MTA-STS ignored? A sane client that supports DANE should prefer DANE when TLSA records are published by the destination. This is based on the stronger downgrade resistance of DANE and no requirement for long-term local storage. Policy lookups have costs, and once a DANE policy is found, it is simplest to not even bother looking for STS policy. Clients that want to eke out as much security as possible might support both, and use DANE when possible and otherwise STS when possible. > > "When a message fails to deliver...": How does the check for the > > updated policy occur, by looking for an updated TXT record or by > > re-retrieving the HTTPS policy? > > > > By looking for an updated TXT record, as per section 3--but your > > question suggests we should clarify this. ;) > > Yes, but Viktor's observation on the other thread (that TXT record > lookups are cheap) applies here so maybe just start all the flows with a > TXT record lookup. I am sticking with that position. -- Viktor. From nobody Tue Feb 28 13:02:26 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C887E1295B5 for ; Tue, 28 Feb 2017 13:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 f2Z8L3Ju-fr2 for ; Tue, 28 Feb 2017 13:02:23 -0800 (PST) Received: from blitiri.com.ar (cdt.blitiri.com.ar [IPv6:2001:41d0:401:3100::2c1a]) (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 6E785129702 for ; Tue, 28 Feb 2017 13:02:23 -0800 (PST) Received: from blitiri.com.ar (authenticated as alb@blitiri.com.ar) by cdt.blitiri.com.ar (chasquid) (over submission TLS-1.2-TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) (envelope from "albertito@blitiri.com.ar") ; Tue, 28 Feb 2017 22:02:19 +0100 Date: Tue, 28 Feb 2017 21:02:18 +0000 From: Alberto Bertogli To: Daniel Margolis Message-ID: <20170228210218.GU28122@blitiri.com.ar> References: <813df83a-841e-4e6a-e3a1-f2852b20ddbc@bluepopcorn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: Jim Fenton , "uta@ietf.org" Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 21:02:25 -0000 On Thu, Feb 23, 2017 at 11:01:18PM +0200, Daniel Margolis wrote: > > 3.1. MTA-STS TXT records > > > > There is no IANA registry for reserved hostnames, which is why protocols > > like SPF store their policies at the domain itself. Is there some reason > > this is not being done here? The version field can be used to > > distinguish from SPF records and other TXT records at the domain level. > > > > This is reasonable, but note that we still require the special hostname for > the HTTPS host (necessary since some domains will not want to host the > HTTPS endpoint at the top-level); reusing it for the TXT record seems > reasonable, no? I'm not wedded to this, but I would avoid unnecessary > changes unless there's a good reason at this point. Is the risks of > collision with a pre-existing record high? I would think not. > > (I'm lazy here because we already have various code that refers to this > record name, and already changed it between version 2 and version 3 of the > draft...) For what is worth, as one of the persons who suggested the removal of the "_" previously (and I'm sorry I didn't realize the problem with the CNAMEs!), having the TXT at the top level sounds nice to me, pretty much for the same reasons mentioned before (makes deployment easier). It has the additional nicety that SPF and friends are also expected to be at the top level too. None of this is crucial, but anyway :) Thanks! Alberto From nobody Tue Feb 28 13:13:28 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BDA129722 for ; Tue, 28 Feb 2017 13:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 8xNKHtnTXfQ5 for ; Tue, 28 Feb 2017 13:13:25 -0800 (PST) Received: from blitiri.com.ar (cdt.blitiri.com.ar [IPv6:2001:41d0:401:3100::2c1a]) (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 31F5C129721 for ; Tue, 28 Feb 2017 13:13:25 -0800 (PST) Received: from blitiri.com.ar (authenticated as alb@blitiri.com.ar) by cdt.blitiri.com.ar (chasquid) (over submission TLS-1.2-TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) (envelope from "albertito@blitiri.com.ar") ; Tue, 28 Feb 2017 22:13:23 +0100 Date: Tue, 28 Feb 2017 21:13:23 +0000 From: Alberto Bertogli To: "Brotman, Alexander" Message-ID: <20170228211322.GV28122@blitiri.com.ar> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "uta@ietf.org" Subject: Re: [Uta] Updated drafts for MTA-STS & TLSRPT X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 21:13:26 -0000 On Wed, Feb 15, 2017 at 07:57:48PM +0000, Brotman, Alexander wrote: > Folks, > > We uploaded new revisions for MTA-STS and TLSRPT. There are minor changes to each: > > 1) Remove the "_" from DNS records to be consistent with A/AAAA > records used with the HTTPS retrieval, and make this a bit less > confusing for deployments. We did this for both MTA-STS and > TLSRPT. Thanks a lot for this! Even though unfortunately it will be reverted/changed due to the CNAME incompatibility mentioned in the thread, FWIW I still appreciate it. > 2) Clarify language around punycode I don't see any punicode related changes in the diffs. Are you sure they went in? In both MTA-STS and TLSRPT all I can find are removals of the "_". I'm looking at the links included in the emails: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-tlsrpt-03 https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-mta-sts-03 What I assume is the/a corresponding issue in github is still open: https://github.com/mrisher/smtp-sts/issues/127. There was a commit adding some wording [1] which was removed the same day [2], maybe that caused some confusion? Thanks! Alberto [1]: https://github.com/mrisher/smtp-sts/commit/4b5bed7b9faf0b23c701367b9e147e559e16b373 [2]: https://github.com/mrisher/smtp-sts/commit/dc8abacbb728863739bd24ffd44d5ce595f1e6b4 From nobody Tue Feb 28 20:55: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 D79B21294A2 for ; Tue, 28 Feb 2017 20:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.08, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75-TqY40ZnoH for ; Tue, 28 Feb 2017 20:55:47 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6C01294A0 for ; Tue, 28 Feb 2017 20:55:46 -0800 (PST) Received: (qmail 18044 invoked from network); 1 Mar 2017 04:55:44 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 1 Mar 2017 04:55:44 -0000 Date: 1 Mar 2017 04:55:22 -0000 Message-ID: <20170301045522.1001.qmail@ary.lan> From: "John Levine" To: uta@ietf.org In-Reply-To: <813df83a-841e-4e6a-e3a1-f2852b20ddbc@bluepopcorn.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: fenton@bluepopcorn.net Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 04:55:48 -0000 In article <813df83a-841e-4e6a-e3a1-f2852b20ddbc@bluepopcorn.net> you write: >3.1. MTA-STS TXT records > >There is no IANA registry for reserved hostnames, which is why protocols >like SPF store their policies at the domain itself. Urrgh. SPF is as far as I know the only protocol published by the IETF that stores policies at the unprefixed hostname, and that is widely agreed to be a mistake. DKIM and DMARC use prefixes. There's the somewhat separate issue that if the prefixed name has to be a hostname so it can be used in a URI, it can't contain an underscore. R's, John PS: Dave Crocker and I have been working on a prefix registry, but it's a thankless task.