From nobody Mon Dec 4 06:05:56 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 46008127369; Mon, 4 Dec 2017 06:05:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: uta@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151239635024.6410.17920726220145541416@ietfa.amsl.com> Date: Mon, 04 Dec 2017 06:05:50 -0800 Archived-At: Subject: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-12.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 14:05:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications WG of the IETF. Title : SMTP TLS Reporting Authors : Daniel Margolis Alexander Brotman Binu Ramakrishnan Janet Jones Mark Risher Filename : draft-ietf-uta-smtp-tlsrpt-12.txt Pages : 25 Date : 2017-12-04 Abstract: A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and MTA-STS. These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attackers and diagnose unintentional misconfigurations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-uta-smtp-tlsrpt-12 https://datatracker.ietf.org/doc/html/draft-ietf-uta-smtp-tlsrpt-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-tlsrpt-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 4 06:06:21 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 E3AA81274A5; Mon, 4 Dec 2017 06:06:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: uta@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151239637487.6445.16956625455886051443@ietfa.amsl.com> Date: Mon, 04 Dec 2017 06:06:14 -0800 Archived-At: Subject: [Uta] I-D Action: draft-ietf-uta-mta-sts-12.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 14:06: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 WG of the IETF. Title : SMTP MTA Strict Transport Security (MTA-STS) Authors : Daniel Margolis Mark Risher Binu Ramakrishnan Alexander Brotman Janet Jones Filename : draft-ietf-uta-mta-sts-12.txt Pages : 25 Date : 2017-12-04 Abstract: SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections, and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-uta-mta-sts-12 https://datatracker.ietf.org/doc/html/draft-ietf-uta-mta-sts-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-mta-sts-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 4 07:41:01 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 111E712785F; Mon, 4 Dec 2017 07:41:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: uta@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151240206003.6432.9638942434848342694@ietfa.amsl.com> Date: Mon, 04 Dec 2017 07:41:00 -0800 Archived-At: Subject: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-13.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 15:41:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications WG of the IETF. Title : SMTP TLS Reporting Authors : Daniel Margolis Alexander Brotman Binu Ramakrishnan Janet Jones Mark Risher Filename : draft-ietf-uta-smtp-tlsrpt-13.txt Pages : 26 Date : 2017-12-04 Abstract: A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and MTA-STS. These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attackers and diagnose unintentional misconfigurations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-uta-smtp-tlsrpt-13 https://datatracker.ietf.org/doc/html/draft-ietf-uta-smtp-tlsrpt-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-tlsrpt-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 4 07:41: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 A12EC1276AF; Mon, 4 Dec 2017 07:41:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: uta@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151240208462.6476.5490424002196408425@ietfa.amsl.com> Date: Mon, 04 Dec 2017 07:41:24 -0800 Archived-At: Subject: [Uta] I-D Action: draft-ietf-uta-mta-sts-13.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 15:41:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications WG of the IETF. Title : SMTP MTA Strict Transport Security (MTA-STS) Authors : Daniel Margolis Mark Risher Binu Ramakrishnan Alexander Brotman Janet Jones Filename : draft-ietf-uta-mta-sts-13.txt Pages : 25 Date : 2017-12-04 Abstract: SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections, and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-uta-mta-sts-13 https://datatracker.ietf.org/doc/html/draft-ietf-uta-mta-sts-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-mta-sts-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 4 11:01: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 16BBB12878D; Mon, 4 Dec 2017 11:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, SPOOF_COM2OTH=2.723] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=kqY3fbtO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nBQpMcH/ 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 0jI0pL62aSz1; Mon, 4 Dec 2017 11:01:37 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93117127010; Mon, 4 Dec 2017 11:01:37 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id CD65C20DAF; Mon, 4 Dec 2017 14:01:36 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Mon, 04 Dec 2017 14:01:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=LAXRSSCkasds03cS36PLVfjxRGlER yLTsQOCRSj/7+s=; b=kqY3fbtOCrIufmwjIuV9dUOarwJOHLvbitHU0CETcaEQy 2pdIuliYh9DvSLxZDWdVUouLfVk2D8supRNeYeLx92yztSkREcF5Mi7vJBlb74/9 c5+XREPQdt2rGwNpMNi/Ag2FlSBViaGhswdzKx+JesBK1rRLhDH1vo4PK65PAWTz qlQ3ujkWFRENUQ0lsILhuGNhnYzxl+5e174sBD/vvcBwUmYuV6b8OVXZI3avvvCn 5sXW6TIL0KmslJW/IgMKsZYIQInO2vClIOAQ2UBCctFxv48d9/FR3hIsi5RZxrIu Qcz5Cx5MXpo8qKbJKHsVNS18X0TUaVj6MpUJ0xisA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=LAXRSS Ckasds03cS36PLVfjxRGlERyLTsQOCRSj/7+s=; b=nBQpMcH/bKOckvwzmdgkaE woKpa58nLLABG3hqpfM0z7iqYyf/SFerYTdDACXlgB0Mx7B7RaZVMb2ETIqtp0ux 7Vy8NchD19o2BS7kyv5vtizKcokZ0WpMAj7mygvGescInh7CstS6/jtm3FubtFX5 wXmjIUNFJNOtBau7OF8QkKw++WYzmToQUk5bzVp0Nk2e8fZOB+qsMbnwrO0pGrLZ oF9phOIALHLiLkucfGPKfVPfAObMLAaJTturNrkegThNOLnjBWpA2XvwCxcqBoyb LI30ZZxM1tS10sVk4NpLm7e7qEG0/EgaqsPiAALRVbtEITKO7FuWEX0iEZhqs4hA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9F43D9E0C7; Mon, 4 Dec 2017 14:01:36 -0500 (EST) Message-Id: <1512414096.2279769.1193703080.61B9F662@webmail.messagingengine.com> From: Alexey Melnikov To: Chris Newman , Keith Moore Cc: Eric Rescorla , uta@ietf.org, uta-chairs@ietf.org, draft-ietf-uta-email-deep@ietf.org, The IESG , Leif Johansson MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-1b87d328 References: <150852235551.15416.1247335476327491501.idtracker@ietfa.amsl.com> <98fddd93-a0a8-efa3-ce2e-530449ae536c@network-heretics.com> <8B20BC5A-A60A-4A31-9345-E970B31BC2C3@oracle.com> <412F718C-F4C9-427C-8D07-3561F374C804@oracle.com> <29ec2879-c811-ef64-46e9-b19adb7fef8e@network-heretics.com> <8b2d406e-0d08-40e0-ee32-28c97367ac74@network-heretics.com> <479574C0-431C-4CEE-8B57-5ED9EC5D5D54@oracle.com> Date: Mon, 04 Dec 2017 19:01:36 +0000 In-Reply-To: <479574C0-431C-4CEE-8B57-5ED9EC5D5D54@oracle.com> Archived-At: Subject: Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-email-deep-09: (with COMMENT) X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 19:01:39 -0000 On Tue, Oct 31, 2017, at 06:29 PM, Chris Newman wrote: > On 30 Oct 2017, at 19:30, Keith Moore wrote: > > After a bit more thought on this, I've concluded that using the mail=20 > > server's server certificates to verify authenticity of SRV records=20 > > probably isn't a good idea - or at least there are more considerations= =20 > > and pitfalls than can reasonably be thought through in the context of=20 > > this document. >=20 > I think what RFC 7817 says about certificate validation is fine, so I=20 > don't want to repeat or contradict what it says. >=20 > > One consideration is that TLS "reverse proxies" can (and likely=20 > > do/will) use SNI to dispatch to different hosts on the back end, as=20 > > one way to implement "virtual hosting" of mail services. >=20 > I don't know if this is done for mail, but SNI routing appears to be in=20 > use: > http://proxy.dockerflow.com/sni-routing/ >=20 > Luckily domain names are cheap, so example.com SRV can point to an=20 > example.com.mailhosting.example.net domain name or something like that=20 > so there's no ambiguity and RFC 7817 cert validation will work fine on=20 > that domain name. >=20 > > Also, of course, being able to authenticate to two different servers=20 > > (even if both present valid certificates for their respective domain=20 > > names) is not the same thing as those two servers being the same. >=20 > It's becoming less likely over time that two connections to a particular= =20 > domain name will be handled by the same physical hardware. Luckily=20 > certificates don't restrict this. >=20 > > So now I'm inclined to add a simple sentence or two along the lines of= =20 > > Chris's suggestion.=C2=A0=C2=A0 I think that's the best we can do in a = short=20 > > time without additional review cycles. >=20 > Agreed. I agree as well. From nobody Tue Dec 5 18:57: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 7926712762F for ; Tue, 5 Dec 2017 18:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 etkUDdBmxio2 for ; Tue, 5 Dec 2017 18:57: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 9E6281201F8 for ; Tue, 5 Dec 2017 18:57:04 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (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 6935B7A3309 for ; Wed, 6 Dec 2017 02:57:03 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) From: Viktor Dukhovni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <911447D0-E7B9-4BFC-8E8C-CBE6F4DD3075@dukhovni.org> Date: Tue, 5 Dec 2017 21:56:59 -0500 To: uta@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [Uta] TLSRPT nit (change DANE RFC from 6698 to 7672) X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 02:57:06 -0000 The RFC6698 references in = https://tools.ietf.org/html/draft-ietf-uta-smtp-tlsrpt-13 should largely be replaced with RFC7672 references. TLSRPT is an SMTP = specification, and DANE for SMTP is defined in RFC7672. --=20 Viktor. From nobody Tue Dec 5 20:13:40 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18691124207 for ; Tue, 5 Dec 2017 20:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 QX8Eqzb0OPS5 for ; Tue, 5 Dec 2017 20:13:37 -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 CC6CE1201F2 for ; Tue, 5 Dec 2017 20:13:36 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (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 B6ABF7A3309 for ; Wed, 6 Dec 2017 04:13:35 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) From: Viktor Dukhovni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <8302CAA0-4F9F-408C-B41A-76C1FD56A9EB@dukhovni.org> Date: Tue, 5 Dec 2017 23:13:34 -0500 To: uta@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [Uta] TLSRPT further comments X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 04:13:39 -0000 Section 4.3.2.1: "dnssec-invalid": This would indicate that no valid records were returned from the recursive resolver. The request returned with SERVFAIL for the requested TLSA record. It should be noted that if the reporter's systems are having problems resolving destination DNS records due to DNSSEC failures, it's possible they will also be unable to resolve the TLSRPT record, therefore these types of reports may be rare. Unfortunately, failure to resolve TLSA records is not yet always a result of a broader DNS outage. A small fraction of systems have nameservers that are either behind firewalls which implement misguided filtering of queries by RRtype (blocking TLSA and other "unusual" queries) or are buggy and mishandle authenticated denial of existence. Therefore, the "may be rare" sentence should I think be deleted. We could perhaps add a "dane-required" failure mode for cases where DANE is mandatory (by mutual agreement perhaps), but then the receiving domain's TLSA records (really the records for the underlying MX hosts) are unexpectedly removed, or become "insecure" if DNSSEC is disabled (DS records removed from parent zone). Speaking of field names, a recent discussion on the ACME list concerned field names and whether to use "camelCase" or "kebab-case" (I hope the distinction is immediately apparent), and noted that "camelCase" is = often a much better fit for programming language bindings because "camelCase" field names can be used directly as structure member field identifiers, enabling machine generation of encoding/decoding code from structure definitions. I think this is a reasonable argument for camels over kebabs, any thoughts on whether it is possible to revise the field names accordingly? Section 4.4: I notice that: "failure-details": [ { "result-type": result-type, "sending-mta-ip": ip-address, "receiving-mx-hostname": receiving-mx-hostname, "receiving-mx-helo": receiving-mx-helo, "failed-session-count": failed-session-count, "additional-information": additional-info-uri, "failure-reason-code": failure-reason-code } ] includes only the "receiving-mx-hostname" and not its IP address. Some sites have multiple hosts behind a single name, e.g. sometimes the IPv4 address for mail.example.com lands on a different machine than the IPv6 address for the same name (and indeed they present different certificate chains, ...). Leaving out the address might make it more difficult to identify the problem receiving machine. Perhaps the intention here is that receiving systems should make an effort to assign different "receiving-mx-helo" names in such to disambiguate these cases? If so, perhaps that should be mentioned in the text. The format for DANE "policy-string" values is both under-specified, and needlessly complex: "policy-string": A string representation of the policy, whether TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples: TLSA: ""_25._tcp.mx.example.com. IN TLSA ( 3 0 1 \ 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D )""... It should be more clear whether the "TLSA:" prefix is part of of the string (I believe it is not), and what the pair of consecutive double quotes is about, and how multiple TLSA records are represented. The JSON policy includes "\n" separators (which JSON maps to actual = newlines), are TLSA records to be separated with similar logical newlines? More importantly, the form: _25._tcp.mx.example.com. IN TLSA ( 3 0 1 = 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D) carries much unnecessary syntax. It should instead be a simple quintuple (qname, usage, selector, mtype, data): _25._tcp.mx.example.com. 3 0 1 = 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D with the implied "IN TLSA" and "(" ")" removed, and the hex data presented without any internal whitespace. With that simplified it remains only to specify clearly how present a complete TLSA RRset. Another nit: o "domain": The Policy Domain is the domain against which the MTA- STS or DANE policy is defined. In the case of Internationalized Domain Names ([RFC5891]), the domain is the Punycode-encoded A-label ([RFC3492]) and not the U-label. A domain name is not a "label" it consists of labels separated by "." characters. Also how are "policy-domain" and "mx-host" to be specified in the DANE case? DANE policy is per-MX, not per-domain, and mx-host seems redundant in both cases, since with STS the policy string surely contains the same data. What goes in these fields when no policy is obtained, they don't appear to be optional... Why in Section 5.1 is there a "report filename"? Surely the processing and storage of reports is entirely up to the receiving system, which should ignore filename hints from the sender. Why is the Content-Encoding (gzip or not) specified via a filename and not the standard header used for this purpose? In section 5.3 what are these "%s" prefixes in front of literal quoted strings? Is this a standard syntax? The [RFC5322].Subject field for report submissions SHOULD conform to the following ABNF: tlsrpt-subject =3D %s"Report" FWS ; "Report" %s"Domain:" FWS ; "Domain:" domain-name FWS ; per [RFC6376] %s"Submitter:" FWS ; "Submitter:" domain-name FWS ; per [RFC6376] %s"Report-ID:" FWS ; "Report-ID: "<" id-left "@" id-right ">" ; per [RFC5322] [CFWS] ; per [RFC5322] ; (as with FWS) In section 5.4, why a separate GZIP-specific media type and not just a Content-Encoding? Surely the media type is just the JSON report format, and GZIP is an encoding layer... In section 5.5 there's talk of a "logarithmic scale" for retries, but normally we speak of *exponential* backoff, not logarithmic! I can't make head nor tail of the verbiage in 5.6. Sounds like someone ran over a thesaurus while riding a lawn mower... :-) Finally, I am concerned that TLSRPT appears to preclude timely reports, requiring each report to cover a full 24 hours. Might it not be reasonable, in some cases to send a timely report on first failure, to be followed by a summary end of day report later? Surely receiving systems might want to learn of problems more promptly. Or are do we want to leave that to a separate spec for in-band reporting (which I guess nobody has yet had the cycles to work on)? --=20 Viktor. From nobody Wed Dec 6 21:35:16 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 7F0C51200C5; Wed, 6 Dec 2017 21:35:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: uta@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151262490948.31228.8659983397128531008@ietfa.amsl.com> Date: Wed, 06 Dec 2017 21:35:09 -0800 Archived-At: Subject: [Uta] I-D Action: draft-ietf-uta-email-deep-12.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 05:35:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications WG of the IETF. Title : Cleartext Considered Obsolete: Use of TLS for Email Submission and Access Authors : Keith Moore Chris Newman Filename : draft-ietf-uta-email-deep-12.txt Pages : 30 Date : 2017-12-06 Abstract: This specification outlines current recommendations for the use of Transport Layer Security (TLS) to provide confidentiality of email traffic between a mail user agent (MUA) and a mail submission or mail access server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-email-deep/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-uta-email-deep-12 https://datatracker.ietf.org/doc/html/draft-ietf-uta-email-deep-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-email-deep-12 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 Thu Dec 7 05:17: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 069CC126FDC for ; Thu, 7 Dec 2017 05:17:55 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDvANvSF_EHi for ; Thu, 7 Dec 2017 05:17: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 945BD126C25 for ; Thu, 7 Dec 2017 05:17:52 -0800 (PST) X-AuditID: a2962c47-bebff700000011f9-56-5a293f7f0382 Received: from COPDCEX22.cable.comcast.com (Unknown_Domain [96.114.156.147]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by copdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 45.79.04601.F7F392A5; Thu, 7 Dec 2017 06:17:52 -0700 (MST) Received: from COPDCEX19.cable.comcast.com (147.191.124.150) by COPDCEX22.cable.comcast.com (147.191.124.153) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 7 Dec 2017 06:17:50 -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.1347.000; Thu, 7 Dec 2017 06:17:50 -0700 From: "Brotman, Alexander" To: "uta@ietf.org" Thread-Topic: [Uta] TLSRPT further comments Thread-Index: AQHTbkictXY8Nix8/E29C3cstHNZ6aM32fXw Date: Thu, 7 Dec 2017 13:17:49 +0000 Message-ID: References: <8302CAA0-4F9F-408C-B41A-76C1FD56A9EB@dukhovni.org> In-Reply-To: <8302CAA0-4F9F-408C-B41A-76C1FD56A9EB@dukhovni.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42JJKJozWbfBXjPKYKu7xamjzYwOjB5Llvxk CmCM4rJJSc3JLEst0rdL4Mp4fW8zW8EFn4qFfbENjH+tuhg5OSQETCS+NHxj7GLk4hASWMEk 0Xb6GAuEc5BR4t3t68wgVUICJxgl5rd5gNhsAlYSb/+3g8VFBBQlXvx5z97FyMEhLKAlceao M0RYW2J122aoEiOJW4d3soHYLAIqEve797KA2LwCXhJzFh9jhBhvL7HkRi9YnFPAQWLBrt1g NqOAmMT3U2uYQGxmAXGJW0/mM0EcLSCxZM95ZghbVOLl43+sELaBxNal+1ggbDmJZT/vMEP0 6kgs2P2JDcLWlli28DUzxA2CEidnPoGqF5c4fGQH6wRG8VlI1s1C0j4LSfssJO0LGFlWMfIa mhnpGZoa6JmY6JkbbmIExsuiaTruOxg/nI89xCjAwajEw5unqRklxJpYVlyZe4hRgoNZSYT3 Ch9QiDclsbIqtSg/vqg0J7X4EKM0B4uSOG9Ig2qUkEB6YklqdmpqQWoRTJaJg1OqgVF3+R+B 1H/Nzyb82Xpd4sx5izsWUls4LpxY7h1rGLlK4hdrdwPfbMMlPts9pP+9W6okpn72uOMduyOf nc0i7l2Z+CKgdtXVZxG7J321tLjnwNVycOOH+QuS2r53TnnuvkNE2eSbVM2LQ3brI74d49m5 6vybTb+3M1snTK/dyntUWOtvd6DtPCd+JZbijERDLeai4kQAd6gJZpMCAAA= Archived-At: Subject: Re: [Uta] TLSRPT further comments X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 13:17:55 -0000 To reference the other message, we'll change that reference for DANE. I'll = try to respond in-line for this one. -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast -----Original Message----- From: Uta [mailto:uta-bounces@ietf.org] On Behalf Of Viktor Dukhovni Sent: Tuesday, December 05, 2017 11:14 PM To: uta@ietf.org Subject: [Uta] TLSRPT further comments Section 4.3.2.1: "dnssec-invalid": This would indicate that no valid records were returned from the recursive resolver. The request returned with SERVFAIL for the requested TLSA record. It should be noted that if the reporter's systems are having problems resolving destination DNS records due to DNSSEC failures, it's possible they will also be unable to resolve the TLSRPT record, therefore these types of reports may be rare. Unfortunately, failure to resolve TLSA records is not yet always a result o= f a broader DNS outage. A small fraction of systems have nameservers that = are either behind firewalls which implement misguided filtering of queries = by RRtype (blocking TLSA and other "unusual" queries) or are buggy and mishandle authenticated denial of existence. Therefore, the "may be rare" sentence should I think be deleted. ---------- This seems to be a different type of operation issue. If an admin can neve= r resolve a TLSA record from an external site, there may be larger issues g= oing on. We can alter/remove the sentence, but I don't think it will chang= e the frequency of those types reports. ---------- We could perhaps add a "dane-required" failure mode for cases where DANE is= mandatory (by mutual agreement perhaps), but then the receiving domain's T= LSA records (really the records for the underlying MX hosts) are unexpected= ly removed, or become "insecure" if DNSSEC is disabled (DS records removed = from parent zone). ------ I'd be inclined to say that this would appear in a "v2" of this draft. ------ Speaking of field names, a recent discussion on the ACME list concerned fie= ld names and whether to use "camelCase" or "kebab-case" (I hope the distinc= tion is immediately apparent), and noted that "camelCase" is often a much b= etter fit for programming language bindings because "camelCase" field names can be used directly as structure member field identifiers, ena= bling machine generation of encoding/decoding code from structure definitio= ns. I think this is a reasonable argument for camels over kebabs, any thou= ghts on whether it is possible to revise the field names accordingly? ----- The draft has been like this since the inception, and I can't say I'm incli= ned to change it. If there's strong group consensus, we can do it. ----- Section 4.4: I notice that: "failure-details": [ { "result-type": result-type, "sending-mta-ip": ip-address, "receiving-mx-hostname": receiving-mx-hostname, "receiving-mx-helo": receiving-mx-helo, "failed-session-count": failed-session-count, "additional-information": additional-info-uri, "failure-reason-code": failure-reason-code } ] includes only the "receiving-mx-hostname" and not its IP address. Some sit= es have multiple hosts behind a single name, e.g. sometimes the IPv4 addres= s for mail.example.com lands on a different machine than the IPv6 address f= or the same name (and indeed they present different certificate chains, ...= ). Leaving out the address might make it more difficult to identify the pr= oblem receiving machine. Perhaps the intention here is that receiving syst= ems should make an effort to assign different "receiving-mx-helo" names in = such to disambiguate these cases? If so, perhaps that should be mentioned = in the text. ---------- We can add this, though, in the case of a front-end VIP, you're going to ha= ve the same target IP in many stanzas. I understand the rationale, just wo= nder how useful it will be in the end. --------- The format for DANE "policy-string" values is both under-specified, and nee= dlessly complex: "policy-string": A string representation of the policy, whether TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples: TLSA: ""_25._tcp.mx.example.com. IN TLSA ( 3 0 1 \ 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D )""... It should be more clear whether the "TLSA:" prefix is part of of the string= (I believe it is not), and what the pair of consecutive double quotes is a= bout, and how multiple TLSA records are represented. The JSON policy inclu= des "\n" separators (which JSON maps to actual newlines), are TLSA records = to be separated with similar logical newlines? More importantly, the form: _25._tcp.mx.example.com. IN TLSA ( 3 0 1 1F850A337E6DB9C609C522D136A47563= 8CC43E1ED424F8EEC8513D7 47D1D085D) carries much unnecessary syntax. It should instead be a simple quintuple (= qname, usage, selector, mtype, data): _25._tcp.mx.example.com. 3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED= 424F8EEC8513D747D1D085D with the implied "IN TLSA" and "(" ")" removed, and the hex data presented = without any internal whitespace. With that simplified it remains only to s= pecify clearly how present a complete TLSA RRset. ------------ The intent was to have the record and the result. Your changes are accepta= ble, and we can make the alterations. In the case of multiple record res= ults, how would you like that to be displayed? Separated with a semicolon = is sufficient I would think. We'll firm up the examples. ------------- Another nit: o "domain": The Policy Domain is the domain against which the MTA- STS or DANE policy is defined. In the case of Internationalized Domain Names ([RFC5891]), the domain is the Punycode-encoded A-label ([RFC3492]) and not the U-label. A domain name is not a "label" it consists of labels separated by "." characters. ---- I believe you're asking to replace "label" with "labels", and that's fine. ---- Also how are "policy-domain" and "mx-host" to be specified in the DANE case= ? DANE policy is per-MX, not per-domain, and mx-host seems redundant in bo= th cases, since with STS the policy string surely contains the same data. = What goes in these fields when no policy is obtained, they don't appear to = be optional... ----- Perhaps I'm misinterpreting the statement. The policy domain is the recipie= nt domain, while the mx-host is the MX that is attempted. Those do not nee= d to align, and multiple recipient domains can point to a single MX. I'm n= ot quite sure which policy you're referring to in the last portion of that = paragraph. ----- Why in Section 5.1 is there a "report filename"? Surely the processing and= storage of reports is entirely up to the receiving system, which should ig= nore filename hints from the sender. ----- This is the filename upon delivery. The receiver can rename the file to an= ything they'd like. ----- Why is the Content-Encoding (gzip or not) specified via a filename and not = the standard header used for this purpose? ----- It's specified as both the attached filename and in the Content-Type header= . In section 5.3 what are these "%s" prefixes in front of literal quoted stri= ngs? Is this a standard syntax? The [RFC5322].Subject field for report submissions SHOULD conform to the following ABNF: tlsrpt-subject =3D %s"Report" FWS ; "Report" %s"Domain:" FWS ; "Domain:" domain-name FWS ; per [RFC6376] %s"Submitter:" FWS ; "Submitter:" domain-name FWS ; per [RFC6376] %s"Report-ID:" FWS ; "Report-ID: "<" id-left "@" id-right ">" ; per [RFC5322] [CFWS] ; per [RFC5322] ; (as with FWS) ----- Yes, I believe Chris asked for that change. I'd have to check list history= . ----- In section 5.4, why a separate GZIP-specific media type and not just a Cont= ent-Encoding? Surely the media type is just the JSON report format, and GZ= IP is an encoding layer... ---- I believe this was at the request of the WG Chairs. I'd have to go back th= rough history to verify this. ----- In section 5.5 there's talk of a "logarithmic scale" for retries, but norma= lly we speak of *exponential* backoff, not logarithmic! ------ Agreed ------ I can't make head nor tail of the verbiage in 5.6. Sounds like someone ran= over a thesaurus while riding a lawn mower... :-) -------- If the filename/subject disagree with the report, then the report is the au= thoritative source. -------- Finally, I am concerned that TLSRPT appears to preclude timely reports, req= uiring each report to cover a full 24 hours. Might it not be reasonable, i= n some cases to send a timely report on first failure, to be followed by a = summary end of day report later? Surely receiving systems might want to le= arn of problems more promptly. Or are do we want to leave that to a separate spec for in-band reporting (w= hich I guess nobody has yet had the cycles to work on)? ------- In-band would be a better place I would think. The sender cannot guarantee= that the receiving site will process reports in a timely fashion. ------- --=20 Viktor. _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta From nobody Thu Dec 7 10:31:06 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E56F1294B5 for ; Thu, 7 Dec 2017 10:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lK3dxNe7adm for ; Thu, 7 Dec 2017 10:31:01 -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 5ECE7127698 for ; Thu, 7 Dec 2017 10:31:01 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 3BFA17A3309 for ; Thu, 7 Dec 2017 18:31:00 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 7 Dec 2017 13:30:58 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: <2A124E40-EE68-4847-A91A-79D178ACE181@dukhovni.org> References: <8302CAA0-4F9F-408C-B41A-76C1FD56A9EB@dukhovni.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Uta] TLSRPT further comments X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 18:31:04 -0000 > On Dec 7, 2017, at 8:17 AM, Brotman, Alexander = wrote: >=20 >=20 >> Section 4.3.2.1: >>=20 >> "dnssec-invalid": This would indicate that no valid records were >> returned from the recursive resolver. The request returned with >> SERVFAIL for the requested TLSA record. It should be noted that >> if the reporter's systems are having problems resolving >> destination DNS records due to DNSSEC failures, it's possible = they >> will also be unable to resolve the TLSRPT record, therefore = these >> types of reports may be rare. >>=20 >> Unfortunately, failure to resolve TLSA records is not yet always a = result of a broader DNS outage. A small fraction of systems have = nameservers that are either behind firewalls which implement misguided = filtering of queries by RRtype (blocking TLSA and other "unusual" >> queries) or are buggy and mishandle authenticated denial of = existence. >> Therefore, the "may be rare" sentence should I think be deleted. >=20 > This seems to be a different type of operation issue. If an admin can = never resolve a TLSA record from an external site, there may be larger = issues going on. We can alter/remove the sentence, but I don't think it = will change the frequency of those types reports. I run a roughly daily survey of the now ~5.1 million DNSSEC-signed domains that I've gathered from various sources. Today, among these 5.1 million domains 132 have the property that: 0. They have a working MX host 1. DNS lookups work fine for "typical" MX/A/AAAA/... queries. 2. TLSA lookups consistently ServFail. The reason is either misguided firewall that filters the query stream or incorrect handling of DNSSEC "denial of existence", causing some or all queries for records that don't exist to fail. The problem is even more common (another ~400 domains) if we remove requirement 0 and include parked or otherwise non-email domains, but these are of course out of the scope for the moment. Also today 87 MX hosts have non-matching TLSA records, 4 don't offer STARTTLS despite published TLSA records, 2 have certificates with non-matching names, and 2 more are expired. So in the "problem landscape" DNSSEC failures that break primarily TLSA records, while the DNS appears to otherwise be working are not actually unusual. One would expect that all TLS policy problems are comparatively rare (and indeed at present they are), and the question is now about frequency among problem destinations. So in fact the qualifier that "these types of reports may be rare" is unnecessary, speculative and does not match present reality. >> We could perhaps add a "dane-required" failure mode for cases where = DANE is mandatory (by mutual agreement perhaps), but then the receiving = domain's TLSA records (really the records for the underlying MX hosts) = are unexpectedly removed, or become "insecure" if DNSSEC is disabled (DS = records removed from parent zone). >=20 > I'd be inclined to say that this would appear in a "v2" of this draft. Drafts don't have a "v2". I don't expect to see a "bis" revision of the published RFC any time soon, the WG will soon be closed. There is still time to make some final changes. I apologize for the belated "tlsrpt" feedback, I was too busy with STS and other matters to give any feedback on "tlsrpt", so here it is, "late", but not "never". >> I think this is a reasonable argument for camels over kebabs, any = thoughts on whether it is possible to revise the field names = accordingly? >=20 > The draft has been like this since the inception, and I can't say I'm = inclined to change it. If there's strong group consensus, we can do it. Please do consider this. I've lately been doing some Haskell programming, and it supports implicit generation of JSON encoders from structure type definitions, freeing the developer from having to write any code to get JSON output, but with "kebab-case" direct "deriving" of a JSON encoder is no longer possible and one would have to explicitly define some encoding rules. I don't think that Haskell is unique in allowing camelCase identifiers and not "kebab-case" identifiers. >> Section 4.4: >>=20 >> I notice that: >>=20 >> "failure-details": [ >> { >> "result-type": result-type, >> "sending-mta-ip": ip-address, >> "receiving-mx-hostname": receiving-mx-hostname, >> "receiving-mx-helo": receiving-mx-helo, >> "failed-session-count": failed-session-count, >> "additional-information": additional-info-uri, >> "failure-reason-code": failure-reason-code >> } >> ] >>=20 >> includes only the "receiving-mx-hostname" and not its IP address. = Some sites have multiple hosts behind a single name, e.g. sometimes the = IPv4 address for mail.example.com lands on a different machine than the = IPv6 address for the same name (and indeed they present different = certificate chains, ...). Leaving out the address might make it more = difficult to identify the problem receiving machine. Perhaps the = intention here is that receiving systems should make an effort to assign = different "receiving-mx-helo" names in such to disambiguate these cases? = If so, perhaps that should be mentioned in the text. >=20 > We can add this, though, in the case of a front-end VIP, you're going = to have the same target IP in many stanzas. I understand the rationale, = just wonder how useful it will be in the end. Yes, the IP will not always be sufficient to disambiguate all problems, but load-balanced MX-pools are more typical of large providers that presumably have more operational discipline and one hopes will rarely if ever mess up. On the other hand, smaller SOHO domains do make mistakes from time to time, and it is among these that I in fact sometimes see TLS working for (say) IPv4 and not (say) IPv6 of the "same" MX host, which turns out to be the "same" in name only. >> The format for DANE "policy-string" values is both under-specified, = and needlessly complex: >>=20 >> "policy-string": A string representation of the policy, whether >> TLSA record ([RFC6698] section 2.3) or MTA-STS policy. = Examples: >> TLSA: ""_25._tcp.mx.example.com. IN TLSA ( 3 0 1 \ >> 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 = 47D1D085D >> )""... >>=20 >> It should be more clear whether the "TLSA:" prefix is part of of the = string (I believe it is not), and what the pair of consecutive double = quotes is about, and how multiple TLSA records are represented. The = JSON policy includes "\n" separators (which JSON maps to actual = newlines), are TLSA records to be separated with similar logical = newlines? >>=20 >> More importantly, the form: >>=20 >> _25._tcp.mx.example.com. IN TLSA ( 3 0 1 = 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D) >>=20 >> carries much unnecessary syntax. It should instead be a simple = quintuple (qname, usage, selector, mtype, data): >>=20 >> _25._tcp.mx.example.com. 3 0 1 = 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D >>=20 >> with the implied "IN TLSA" and "(" ")" removed, and the hex data = presented without any internal whitespace. With that simplified it = remains only to specify clearly how present a complete TLSA RRset. >=20 > The intent was to have the record and the result. Your changes are = acceptable, and we can make the alterations. In the case of multiple = record results, how would you like that to be displayed? Separated with = a semicolon is sufficient I would think. We'll firm up the examples. The "(" and ")" are entirely optional, the TLSA record is well-formed without them. Since the policy type is TLSA, why repeat "IN TLSA", it is redundant. Internal optional white-space in the data payload needlessly and significantly complicates parsing. As for separators, I would much prefer newline ("\n" just like in the STS policy blob). This portion of the spec really should be more formal, it presently just presents a free-form example, rather than a well-defined syntax. What's the intent of the consecutive double-quote characters for example? >> Another nit: >>=20 >> o "domain": The Policy Domain is the domain against which the MTA- >> STS or DANE policy is defined. In the case of Internationalized >> Domain Names ([RFC5891]), the domain is the Punycode-encoded >> A-label ([RFC3492]) and not the U-label. >>=20 >> A domain name is not a "label" it consists of labels separated by "." >> characters. >=20 > I believe you're asking to replace "label" with "labels", and that's = fine. Yes, basically though the change requires a few more words to make the grammar work. >> Also how are "policy-domain" and "mx-host" to be specified in the = DANE case? DANE policy is per-MX, not per-domain, and mx-host seems = redundant in both cases, since with STS the policy string surely = contains the same data. What goes in these fields when no policy is = obtained, they don't appear to be optional... >=20 > Perhaps I'm misinterpreting the statement. The policy domain is the = recipient domain, while the mx-host is the MX that is attempted. That's not what the draft text says. Instead it has: o "mx-host-pattern": The pattern of MX hostnames from the applied policy. It is provided as a string, and is interpreted in the same manner as the "Checking of Wildcard Certificates" rules in Section 6.4.3 of [RFC6125]. In the case of Internationalized Domain Names ([RFC5891]), the domain is the Punycode-encoded A-label ([RFC3492]) and not the U-label. So it sure seems to be the "mx" element of the policy, repeated for some reason. > Those do not need to align, and multiple recipient domains can point = to a single MX. I'm not quite sure which policy you're referring to in = the last portion of that paragraph. The "policy-string" in the JSON report in Section 4 already contains the same "mx-host-pattern" (called just "mx"). >> Why in Section 5.1 is there a "report filename"? Surely the = processing >> and storage of reports is entirely up to the receiving system, which >> should ignore filename hints from the sender. >=20 > This is the filename upon delivery. The receiver can rename the file = to > anything they'd like. A JSON report is NOT a file. It makes no sense to have to specify a filename and just creates security issues when one is processed by poorly thought out receiving software. If the intended purpose of the filename is to carry useful metadata (rather than suggest a storage location), such metadata should be encoded via additional MIME attributes of the media type. >> Why is the Content-Encoding (gzip or not) specified via a filename = and not the standard header used for this purpose? >=20 > It's specified as both the attached filename and in the Content-Type = header. I see this as a mistake. There is only one media type involved here, which may have a Content-Encoding. A receiving system may always decompress any compressed form as it comes in (or just use uncompressed inputs as-is) parse the JSON and load the data into a database. Another receiving system may always compress any uncompressed inputs and save the reports into a file store for archival or onward delivery. This is up to the receiving system, but either way I see only the one media type here. The issue is perhaps that while "HTTP" has "Content-Encoding", MIME as defined in RFC-2045 does not: https://www.ucolick.org/~sla/fits/mime/inetstds.html MIME media types and the WWW ... Section 14.11 gives the proper means of describing the HTTP transmission of a file which is already compressed The Content-Encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header = field. Content-Encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type. Unfortunately it seems reasonably clear that = Content-Encoding cannot be applied as if it were a MIME "Optional parameter" with = the expectation that it could be used when transferring compressed = files via e-mail. This observation is based upon section 19.4.4. It = appears that a complete description of compressed files transmitted via = e-mail requires a new RFC enhancing the MIME standard. =20 https://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.4.4 19.4.4 Introduction of Content-Encoding RFC 2045 does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier on the media type, proxies and gateways from HTTP to MIME-compliant protocols MUST either change the value of the Content-Type = header field or decode the entity-body before forwarding the message. (Some experimental applications of Content-Type for Internet = mail have used a media-type parameter of = ";conversions=3D" to perform a function equivalent to Content-Encoding. However, = this parameter is not part of RFC 2045.) Thus, at the very least for HTTP, there should be just one media type, and Content-Encoding should be used to signal compression. For email, since we're introducing a new "multipart/report" subtype, and = "Content-Encoding" is not a standard MIME header, an appropriate media-type parameter (what I earlier referred to as MIME "attribute") should be defined for "application/tlsrpt". It could be the above "; conversions=3Dgzip" or something similar. The "application/tlsrpt" being a new media type, you're free to define appropriate additional metadata. >> In section 5.3 what are these "%s" prefixes in front of literal = quoted strings? Is this a standard syntax? >>=20 >> The [RFC5322].Subject field for report submissions SHOULD conform = to >> the following ABNF: >>=20 >> tlsrpt-subject =3D %s"Report" FWS ; "Report" >> %s"Domain:" FWS ; "Domain:" >> domain-name FWS ; per [RFC6376] >> %s"Submitter:" FWS ; "Submitter:" >> domain-name FWS ; per [RFC6376] >> %s"Report-ID:" FWS ; "Report-ID: >> "<" id-left "@" id-right ">" ; per [RFC5322] >> [CFWS] ; per [RFC5322] >> ; (as with FWS) >=20 > Yes, I believe Chris asked for that change. I'd have to check list = history. A reference to a document that defines such syntax would be helpful. It just looked confusing to me... >> In section 5.4, why a separate GZIP-specific media type and not just = a Content-Encoding? Surely the media type is just the JSON report = format, and GZIP is an encoding layer... >=20 > I believe this was at the request of the WG Chairs. I'd have to go = back through history to verify this. Please do. Keep in mind that absent a "Content-Encoding" header, one should indeed specify that the content is compressed by means other than a filename (which I argue should not be present at all). However, the solution as I see it is to employ the already defined for this purpose "Content-Encoding" header (with HTTP, and a new media-type parameter for MIME email) and avoid a separate media type for compressed JSON reports. >> I can't make head nor tail of the verbiage in 5.6. Sounds like = someone ran over a thesaurus while riding a lawn mower... :-) >=20 > If the filename/subject disagree with the report, then the report is = the authoritative source. That's much simpler and clearer than the current text. Of course no "filename" should be used to convey *any* structured information about the report, indeed a filename should be entirely optional (unspecified in this draft). Like the optional filename, the subject should be for human consumption only. A suggested subject does make it easier for reports from multiple sources to stand out as such at a glance, when the "rua" email address is for a human postmaster and lands in a general-purpose (personal?) mailbox. Solely as a *convenience* to a human postmaster, the only structured data that might be appropriate to include as part of an optinal filename would be a ".gz" or a ".txt.gz" suffix to make it easier for postmasters to save reports that land in their mailbox. The rest of any filename should be uninterpreted opaque data, and it could simply be "tlsrpt.txt" or "tlsrpt.gz", but again for convenience it *may* be friendlier to include a date: tlsrpt-20171206.txt tlsrpt-20171206.txt.gz Whether or where the recipient saves such reports in some filesystem is entirely at the recipient's discretion. --=20 Viktor. From nobody Fri Dec 8 11:05:10 2017 Return-Path: X-Original-To: uta@ietf.org Delivered-To: uta@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DEC12773A; Fri, 8 Dec 2017 11:05:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , uta-chairs@ietf.org, uta@ietf.org, draft-ietf-uta-email-deep@ietf.org, alexey.melnikov@isode.com, leifj@sunet.se, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151275990322.5842.16991565150629449024.idtracker@ietfa.amsl.com> Date: Fri, 08 Dec 2017 11:05:03 -0800 Archived-At: Subject: [Uta] Protocol Action: 'Cleartext Considered Obsolete: Use of TLS for Email Submission and Access' to Proposed Standard (draft-ietf-uta-email-deep-12.txt) X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 19:05:03 -0000 The IESG has approved the following document: - 'Cleartext Considered Obsolete: Use of TLS for Email Submission and Access' (draft-ietf-uta-email-deep-12.txt) as Proposed Standard This document is the product of the Using TLS in Applications Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-email-deep/ Technical Summary This specification outlines current recommendations for use of Transport Layer Security (TLS) to provide confidentiality of email traffic between a mail user agent (MUA) and a mail submission or mail access server. Working Group Summary Discussion in the WG went through several iterations and the document went through major restructure with respect to the initial submission. Document Quality The document accurately reflects consensus and closely matches much of current practice for how mail services are operated. The WGLC went through with no opposition and clear indication of consensus from the community. There have been no expert reviews of the document and an ABNF expert review along with the secdir review would be useful. Personnel Shepherd: Leif Johansson (WG chair) AD: Alexey Melnikov From nobody Fri Dec 15 05:46:14 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2CC128BBB for ; Fri, 15 Dec 2017 05:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x51gOCUIAaOK for ; Fri, 15 Dec 2017 05:46:09 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BECA51200B9 for ; Fri, 15 Dec 2017 05:46:08 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id y78so4865234lfd.1 for ; Fri, 15 Dec 2017 05:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Wif8Xa4QFj1/xbgr9w0AfRa+QqY/np3bdHodS8yU9S4=; b=IZ9T/OwykpgxT3hDhLLvHRuFpk+r+PfdyGs/1H1VrsbmEqcAirGzNd3z5TQc0QWA6z bl53E10wCKma1YCwl6C9bxAplLC0pY50sNNvnxvfbB9MwIf5xZW3trBcBAm9XCtlWRIA CA/VsO12ZcVGFltbzpZiLzh28pEUQQWbSAQGFrvZYmRMYSjyPccf1HhyixdHmF3Xtmrn APiNxrtaFeYAqypToovDNeugD1u7HUa2gjj7+GhAJLlZbkhNFi8k/aE0b5mnz1Shp7xy QuUdycFNAF05Il6TLD/akp5/EJqnkTz4NGivb87MqEMGQxR8diM5fsyqVCaVxiIuwbby EcNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Wif8Xa4QFj1/xbgr9w0AfRa+QqY/np3bdHodS8yU9S4=; b=IpXBnAeqymvQkiIrXFQnmwVH2D36tfFG+mSi+5Hyu2i0Bf6RfiW/QRW3YvmrDkiH/u Aygv2tXGPAml5xuyPQ1Od2t1V0CwkaGYM4ZM5fRutP81699QQ2whvzW+a43QCPWufhpI ab5li8zlvRtqQeJG5Pdhfp+iMPz9P3UXUn+6gn0QI0mVhZE4/9v4PpVAGFqQPH+TZ+eo bplPpVPtYzD//m4W/Tees3iqtIzlmDpuC39iLEElgvB93d/bQubEnTK1MxlS0X9s92LB CtFc3v2THWqQUw/oWkmRpy8oum3VpmFGNhoSemJlrkGv/wi4Vc9OWONWH7zziRd+WjX/ Zb0Q== X-Gm-Message-State: AKGB3mI0zO7GxlP/WzbrUufo8Ce0bxvFzBiCoX7ME4/qrO+tRTe0jVzb //KxqhJjAjfTGsBfSrHSo/o= X-Google-Smtp-Source: ACJfBouyk5ItM6MjfC/2hiLbMF9eJLo2bQeGi8pgU6L0IlZ68uCXRdGSyrTjV1VKpBI5gLbLx2Ioyw== X-Received: by 10.25.24.76 with SMTP id o73mr3799948lfi.79.1513345565634; Fri, 15 Dec 2017 05:46:05 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id t76sm1319603lff.84.2017.12.15.05.46.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Dec 2017 05:46:04 -0800 (PST) From: "Valery Smyslov" To: "'Viktor Dukhovni'" , "'Brotman, Alexander'" Cc: References: <8302CAA0-4F9F-408C-B41A-76C1FD56A9EB@dukhovni.org> <2A124E40-EE68-4847-A91A-79D178ACE181@dukhovni.org> In-Reply-To: <2A124E40-EE68-4847-A91A-79D178ACE181@dukhovni.org> Date: Fri, 15 Dec 2017 16:46:10 +0300 Message-ID: <08d701d375ab$110712d0$33153870$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLPjL/Uq29+m8IIhV0HlwGpKui99QHP7eUwAjG0sKihLAjEAA== Content-Language: ru Archived-At: Subject: Re: [Uta] TLSRPT further comments X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 13:46:12 -0000 Hi, a few comments are below. > >> "dnssec-invalid": This would indicate that no valid records were > >> returned from the recursive resolver. The request returned with > >> SERVFAIL for the requested TLSA record. It should be noted that > >> if the reporter's systems are having problems resolving > >> destination DNS records due to DNSSEC failures, it's possible they > >> will also be unable to resolve the TLSRPT record, therefore these > >> types of reports may be rare. > >> > >> Unfortunately, failure to resolve TLSA records is not yet always a result of a broader DNS outage. A small > fraction of systems have nameservers that are either behind firewalls which implement misguided filtering of > queries by RRtype (blocking TLSA and other "unusual" > >> queries) or are buggy and mishandle authenticated denial of existence. > >> Therefore, the "may be rare" sentence should I think be deleted. > > > > This seems to be a different type of operation issue. If an admin can never resolve a TLSA record from an > external site, there may be larger issues going on. We can alter/remove the sentence, but I don't think it will > change the frequency of those types reports. I think this sentence can be deleted, since what is really "rare" is highly personal and subjective. > >> We could perhaps add a "dane-required" failure mode for cases where DANE is mandatory (by mutual > agreement perhaps), but then the receiving domain's TLSA records (really the records for the underlying MX > hosts) are unexpectedly removed, or become "insecure" if DNSSEC is disabled (DS records removed from > parent zone). > > > > I'd be inclined to say that this would appear in a "v2" of this draft. > > Drafts don't have a "v2". I don't expect to see a "bis" revision > of the published RFC any time soon, the WG will soon be closed. > There is still time to make some final changes. I apologize for > the belated "tlsrpt" feedback, I was too busy with STS and other > matters to give any feedback on "tlsrpt", so here it is, "late", > but not "never". Victor, can you please provide a new text? > >> I think this is a reasonable argument for camels over kebabs, any thoughts on whether it is possible to > revise the field names accordingly? > > > > The draft has been like this since the inception, and I can't say I'm inclined to change it. If there's strong > group consensus, we can do it. > > Please do consider this. I've lately been doing some Haskell > programming, and it supports implicit generation of JSON encoders > from structure type definitions, freeing the developer from having > to write any code to get JSON output, but with "kebab-case" direct > "deriving" of a JSON encoder is no longer possible and one would > have to explicitly define some encoding rules. I don't think that > Haskell is unique in allowing camelCase identifiers and not > "kebab-case" identifiers. While having this feature would be nice, I don't think it justifies changing the document. Note that RFC7469, from which this schema was derived, also uses "kebab" style. > >> I notice that: > >> > >> "failure-details": [ > >> { > >> "result-type": result-type, > >> "sending-mta-ip": ip-address, > >> "receiving-mx-hostname": receiving-mx-hostname, > >> "receiving-mx-helo": receiving-mx-helo, > >> "failed-session-count": failed-session-count, > >> "additional-information": additional-info-uri, > >> "failure-reason-code": failure-reason-code > >> } > >> ] > >> > >> includes only the "receiving-mx-hostname" and not its IP address. Some sites have multiple hosts behind a > single name, e.g. sometimes the IPv4 address for mail.example.com lands on a different machine than the > IPv6 address for the same name (and indeed they present different certificate chains, ...). Leaving out the > address might make it more difficult to identify the problem receiving machine. Perhaps the intention here is > that receiving systems should make an effort to assign different "receiving-mx-helo" names in such to > disambiguate these cases? If so, perhaps that should be mentioned in the text. > > > > We can add this, though, in the case of a front-end VIP, you're going to have the same target IP in many > stanzas. I understand the rationale, just wonder how useful it will be in the end. > > Yes, the IP will not always be sufficient to disambiguate > all problems, but load-balanced MX-pools are more typical > of large providers that presumably have more operational > discipline and one hopes will rarely if ever mess up. On > the other hand, smaller SOHO domains do make mistakes from > time to time, and it is among these that I in fact sometimes > see TLS working for (say) IPv4 and not (say) IPv6 of the > "same" MX host, which turns out to be the "same" in name > only. I think this makes sense. > >> The format for DANE "policy-string" values is both under-specified, and needlessly complex: > >> > >> "policy-string": A string representation of the policy, whether > >> TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples: > >> TLSA: ""_25._tcp.mx.example.com. IN TLSA ( 3 0 1 \ > >> 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D > >> )""... > >> > >> It should be more clear whether the "TLSA:" prefix is part of of the string (I believe it is not), and what the > pair of consecutive double quotes is about, and how multiple TLSA records are represented. The JSON policy > includes "\n" separators (which JSON maps to actual newlines), are TLSA records to be separated with similar > logical newlines? > >> > >> More importantly, the form: > >> > >> _25._tcp.mx.example.com. IN TLSA ( 3 0 1 > 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D) > >> > >> carries much unnecessary syntax. It should instead be a simple quintuple (qname, usage, selector, mtype, > data): > >> > >> _25._tcp.mx.example.com. 3 0 1 > 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D > >> > >> with the implied "IN TLSA" and "(" ")" removed, and the hex data presented without any internal > whitespace. With that simplified it remains only to specify clearly how present a complete TLSA RRset. > > > > The intent was to have the record and the result. Your changes are acceptable, and we can make the > alterations. In the case of multiple record results, how would you like that to be displayed? Separated with a > semicolon is sufficient I would think. We'll firm up the examples. > > The "(" and ")" are entirely optional, the TLSA record is well-formed > without them. Since the policy type is TLSA, why repeat "IN TLSA", > it is redundant. Internal optional white-space in the data payload > needlessly and significantly complicates parsing. As for separators, > I would much prefer newline ("\n" just like in the STS policy blob). > > This portion of the spec really should be more formal, it presently > just presents a free-form example, rather than a well-defined syntax. > What's the intent of the consecutive double-quote characters for > example? Can you please provide an alternate format? > >> Why in Section 5.1 is there a "report filename"? Surely the processing > >> and storage of reports is entirely up to the receiving system, which > >> should ignore filename hints from the sender. > > > > This is the filename upon delivery. The receiver can rename the file to > > anything they'd like. > > A JSON report is NOT a file. It makes no sense to have to specify > a filename and just creates security issues when one is processed > by poorly thought out receiving software. If the intended purpose > of the filename is to carry useful metadata (rather than suggest > a storage location), such metadata should be encoded via additional > MIME attributes of the media type. I tend to agree. > >> Why is the Content-Encoding (gzip or not) specified via a filename and not the standard header used for > this purpose? > > > > It's specified as both the attached filename and in the Content-Type header. > > I see this as a mistake. There is only one media type involved > here, which may have a Content-Encoding. A receiving system may > always decompress any compressed form as it comes in (or just > use uncompressed inputs as-is) parse the JSON and load the data > into a database. Another receiving system may always compress > any uncompressed inputs and save the reports into a file store > for archival or onward delivery. This is up to the receiving > system, but either way I see only the one media type here. > > The issue is perhaps that while "HTTP" has "Content-Encoding", > MIME as defined in RFC-2045 does not: > > https://www.ucolick.org/~sla/fits/mime/inetstds.html > > MIME media types and the WWW > ... > Section 14.11 gives the proper means of describing the HTTP > transmission of a file which is already compressed > > The Content-Encoding entity-header field is used as a modifier > to the media-type. When present, its value indicates what > additional content codings have been applied to the entity-body, > and thus what decoding mechanisms must be applied in order to > obtain the media-type referenced by the Content-Type header field. > Content-Encoding is primarily used to allow a document to be > compressed without losing the identity of its underlying media > type. Unfortunately it seems reasonably clear that Content-Encoding > cannot be applied as if it were a MIME "Optional parameter" with the > expectation that it could be used when transferring compressed files > via e-mail. This observation is based upon section 19.4.4. It appears > that a complete description of compressed files transmitted via e-mail > requires a new RFC enhancing the MIME standard. > > https://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.4.4 > > 19.4.4 Introduction of Content-Encoding > > RFC 2045 does not include any concept equivalent to HTTP/1.1's > Content-Encoding header field. Since this acts as a modifier on > the media type, proxies and gateways from HTTP to MIME-compliant > protocols MUST either change the value of the Content-Type header > field or decode the entity-body before forwarding the message. > (Some experimental applications of Content-Type for Internet mail > have used a media-type parameter of ";conversions=" > to perform a function equivalent to Content-Encoding. However, this > parameter is not part of RFC 2045.) > > Thus, at the very least for HTTP, there should be just one media type, > and Content-Encoding should be used to signal compression. For email, > since we're introducing a new "multipart/report" subtype, and "Content-Encoding" > is not a standard MIME header, an appropriate media-type parameter (what > I earlier referred to as MIME "attribute") should be defined for > "application/tlsrpt". It could be the above "; conversions=gzip" or > something similar. The "application/tlsrpt" being a new media type, > you're free to define appropriate additional metadata. Again, can you please provide a text? Regards, Valery. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta From nobody Sun Dec 17 19:01:42 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CA8127599 for ; Sun, 17 Dec 2017 19:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Ho8_g7b9Wsah for ; Sun, 17 Dec 2017 19:01:39 -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 BFB9C124E15 for ; Sun, 17 Dec 2017 19:01:38 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8FE237A330A; Mon, 18 Dec 2017 03:01:37 +0000 (UTC) Date: Mon, 18 Dec 2017 03:01:37 +0000 From: Viktor Dukhovni To: uta@ietf.org Message-ID: <20171218030137.GS3322@mournblade.imrryr.org> Reply-To: uta@ietf.org References: <8302CAA0-4F9F-408C-B41A-76C1FD56A9EB@dukhovni.org> <2A124E40-EE68-4847-A91A-79D178ACE181@dukhovni.org> <08d701d375ab$110712d0$33153870$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <08d701d375ab$110712d0$33153870$@gmail.com> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Uta] TLSRPT further comments X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 03:01:41 -0000 On Fri, Dec 15, 2017 at 04:46:10PM +0300, Valery Smyslov wrote: > > >> It should be noted that > > >> if the reporter's systems are having problems resolving > > >> destination DNS records due to DNSSEC failures, it's possible they > > >> will also be unable to resolve the TLSRPT record, therefore these > > >> types of reports may be rare. > > >> > > >> ..., the "may be rare" sentence should I think be deleted. > > I think this sentence can be deleted, since what is really "rare" is highly personal and subjective. Thanks. I hope the draft will be amended accordingly. > > >> We could perhaps add a "dane-required" failure mode for cases where DANE is mandatory (by mutual > > >> agreement perhaps), but then the receiving domain's TLSA records (really the records for the underlying MX > > >> hosts) are unexpectedly removed, or become "insecure" if DNSSEC is disabled (DS records removed from > > >> parent zone). > > > > > > I'd be inclined to say that this would appear in a "v2" of this draft. > > > > Drafts don't have a "v2". I don't expect to see a "bis" revision > > of the published RFC any time soon, the WG will soon be closed. > > There is still time to make some final changes. I apologize for > > the belated "tlsrpt" feedback, I was too busy with STS and other > > matters to give any feedback on "tlsrpt", so here it is, "late", > > but not "never". > > Vi[ck]tor, can you please provide a new text? o "dane-required": This indicates that the sending system is configured to require DANE TLSA records for all the MX hosts of the destination domain, but no DNSSEC-validated TLSA records were present for the MX host that is the subject of the report. Mandatory DANE for SMTP is described in section 6 of RFC7672. Such policies may be created by mutual agreement between two organizations that frequently exchange sensitive content via email. > > Yes, the IP will not always be sufficient to disambiguate > > all problems, but load-balanced MX-pools are more typical > > of large providers that presumably have more operational > > discipline and one hopes will rarely if ever mess up. On > > the other hand, smaller SOHO domains do make mistakes from > > time to time, and it is among these that I in fact sometimes > > see TLS working for (say) IPv4 and not (say) IPv6 of the > > "same" MX host, which turns out to be the "same" in name > > only. > > I think this makes sense. Thanks, so I would like to see the IP address (v4 or v6, the type should be clear from the address syntax) added to the report schema. > > This portion of the spec really should be more formal, it presently > > just presents a free-form example, rather than a well-defined syntax. > > What's the intent of the consecutive double-quote characters for > > example? > > Can you please provide an alternate format? I don't have cycles to draft a more formal grammar, but it should be done. The TLSA part should be a JSON encoding of the RData of the MX host's TLSA RRSet in the form: _25._tcp.smtp.example.com 3 1 1 _25._tcp.smtp.example.com 2 1 1 The name on each line should be the QNAME from the question section of the DNS query that elicited the TLSA records, that is, "_25._tcp." prefixed to the "TLSA base domain". When that name is an alias, the actual answer TLSA RRset may have a different "owner", but the report should convey the initial QNAME. A JSON encoding of this "policy-string" will be something like: "_25._tcp.smtp.example.com 3 1 1 \n_25._tcp.smtp.example.com 2 1 1 \n" Mind you, a more natural form might be not "policy-string", but rather "policy-records": [ "_25._tcp.smtp.example.com 3 1 1 " , "_25._tcp.smtp.example.com 3 1 1 " ] which would probably also be a good fit for STS policies as well. So it probably makes more sense to switch to that than invent some in-string record separator/terminator. > > A JSON report is NOT a file. It makes no sense to have to specify > > a filename and just creates security issues when one is processed > > by poorly thought out receiving software. If the intended purpose > > of the filename is to carry useful metadata (rather than suggest > > a storage location), such metadata should be encoded via additional > > MIME attributes of the media type. > > I tend to agree. Anyone else? > > Thus, at the very least for HTTP, there should be just one media type, > > and Content-Encoding should be used to signal compression. For email, > > since we're introducing a new "multipart/report" subtype, and "Content-Encoding" > > is not a standard MIME header, an appropriate media-type parameter (what > > I earlier referred to as MIME "attribute") should be defined for > > "application/tlsrpt". It could be the above "; conversions=gzip" or > > something similar. The "application/tlsrpt" being a new media type, > > you're free to define appropriate additional metadata. > > Again, can you please provide a text? No, but I don't think it is much to ask from the draft authors. The text can describe: Content-Type: application/tlsrpt; conversions=gzip Content-Type: application/tlsrpt; conversions=none Content-Type: application/tlsrpt with the last form implicitly equivalent to the second. -- Viktor. From nobody Mon Dec 18 05:23: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 99917129516 for ; Mon, 18 Dec 2017 05:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[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 fvOa9CPARlVc for ; Mon, 18 Dec 2017 05:23:19 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 13FE51242F7 for ; Mon, 18 Dec 2017 05:23:18 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id g74so7812777lfk.7 for ; Mon, 18 Dec 2017 05:23:18 -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-language:content-transfer-encoding; bh=mByOJXXTTOmUsUm+S9kaEkXfF8BVD2UpOVFK+s1YNpA=; b=FYg723YYbC+QsoZ0YbGct8h0l8SpdsBVgw38nGnWadxv70dJN3pRrGVyK8/Kd2NXHW rD3i/sM3xlYt6pP8gzCmy372o8OV/yVdtZfGWV1XjMjUkraNRpH8EptkZwonkNZYfwPa ww3uml29aLpaeUfxssQbspS6Gzg96WdyTDS+j+NGGnvzDy9/gllUPD3IP+wb1XkcORDk jhANy44fCdEGc2h7lffLmpdvYewUX5YQ5BOccYL0TTKRQ1zjNlrIwItfJpmlvoHQIhbO +qsmFFuj75bgPyudr0JwZD52K8Q7Xd6/SaX/Kdd/xBP+zPfEOYqaoNMp5gIEGxSVEg14 ERVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mByOJXXTTOmUsUm+S9kaEkXfF8BVD2UpOVFK+s1YNpA=; b=Nf43YV2UOOrbXQUnnfGt/IZCJsbo4XpkgUSaxbturbJAeeQaYO17kcCh7fzUf4jb2v F+lFsR5Y7sfMqnHT5RILaDuLPfwf7mWidKM7Pt3+WfDsMf7opa4RsuNErB0stKG8wBpN x3oflC7TgaHWmHODDeBNhZ7tYy8HXEAkoKT+UGbiApxuI+uMY3B4fgD/wtXLq5YqhNjN dy0/z7rkr9LsE5pl9jZqM1KUVytM0Ps+GlW61j/NjYvbYa1jgOT+NWqFBriGlWF6OtOE 7GTYvwNFdH7gvomeEDjfEkwKWNKaMBI44zf8KpCnPvKYuNjEqVvlng5YQ0UJLVp7/xMq yQ9g== X-Gm-Message-State: AKGB3mIanNXdUHiV69UMBC3SD4RY2Q4joZDcI9RpTbjbbzkUj8Vu5OJ1 Qv9Kbz6lxUmST6SFSwNHPUAzE1dzSQw= X-Google-Smtp-Source: ACJfBotdsfwCCD+zB8IL+/6bjMybqgre9U9My0eFi6pI6w31PcCrh+lDGIMRijPhgZ9o1u7WHkGAcQ== X-Received: by 10.46.116.9 with SMTP id p9mr5263892ljc.28.1513603396693; Mon, 18 Dec 2017 05:23:16 -0800 (PST) Received: from ?IPv6:2001:6b0:7:1:3dbc:b13:e271:f365? ([2001:6b0:7:1:3dbc:b13:e271:f365]) by smtp.gmail.com with ESMTPSA id s15sm2792426lfg.69.2017.12.18.05.23.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 05:23:16 -0800 (PST) To: uta@ietf.org References: <8302CAA0-4F9F-408C-B41A-76C1FD56A9EB@dukhovni.org> <2A124E40-EE68-4847-A91A-79D178ACE181@dukhovni.org> <08d701d375ab$110712d0$33153870$@gmail.com> <20171218030137.GS3322@mournblade.imrryr.org> From: Leif Johansson Message-ID: Date: Mon, 18 Dec 2017 14:23:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171218030137.GS3322@mournblade.imrryr.org> Content-Type: text/plain; charset=utf-8 Content-Language: sv Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Uta] TLSRPT further comments X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 13:23:21 -0000 >> >> Can you please provide an alternate format? > > I don't have cycles to draft a more formal grammar, but it should be > done. The TLSA part should be a JSON encoding of the RData of the > MX host's TLSA RRSet in the form: Victor - this draft has passed WGLC and since you're the only one who has (so far) raised a requirement for a formal syntax here, so unless you or somebody provides concrete suggestions *and* there is clear WG support for the change, we are not going to spend more time on this. This does not *exclude* making further change but we are past the time for open-ended discussions about this document. > > No, but I don't think it is much to ask from the draft authors. > The text can describe: cf my comments above. Cheers Leif From nobody Mon Dec 18 07:50:39 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034C71201F8 for ; Mon, 18 Dec 2017 07:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, 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 ssl_0Qu0Dc8i for ; Mon, 18 Dec 2017 07:50:35 -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 08F751200B9 for ; Mon, 18 Dec 2017 07:50:34 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 0BF987A3309 for ; Mon, 18 Dec 2017 15:50:34 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 18 Dec 2017 10:50:13 -0500 Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Message-Id: <05239F7E-BDC8-414A-8FAC-1897F5711C99@dukhovni.org> References: <8302CAA0-4F9F-408C-B41A-76C1FD56A9EB@dukhovni.org> <2A124E40-EE68-4847-A91A-79D178ACE181@dukhovni.org> <08d701d375ab$110712d0$33153870$@gmail.com> <20171218030137.GS3322@mournblade.imrryr.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Uta] TLSRPT further comments X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 15:50:38 -0000 > On Dec 18, 2017, at 8:23 AM, Leif Johansson wrote: > > Victor - this draft has passed WGLC and since you're the only one who > has (so far) raised a requirement for a formal syntax here, so unless > you or somebody provides concrete suggestions *and* there is clear WG > support for the change, we are not going to spend more time on this. > > This does not *exclude* making further change but we are past the > time for open-ended discussions about this document. My hope is that the authors/editors will recognize the defect and make the necessary changes. The current syntax (of the "policy-string" element) is under-specified. It contains just a vague example. So the original actual intent is unclear. At the very least the original intent should be more specific. This is an esoteric topic, I don't expect that very many others did a close reading of the document. I am sorry I got to it somewhat late, but it is not a published RFC yet, and I hope that bug-fixes are still possible. Perhaps one of the authors is willing to propose a more explicit grammar. The "policy-string" should be machine-readable, and therefore should have an explicit syntax. -- -- Viktor. From nobody Mon Dec 18 08:05:04 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FAB12D779 for ; Mon, 18 Dec 2017 08:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, 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 pxSKnok_aqe1 for ; Mon, 18 Dec 2017 08:05:00 -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 D649212708C for ; Mon, 18 Dec 2017 08:05:00 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 1F0E97A3309 for ; Mon, 18 Dec 2017 16:05:00 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: <05239F7E-BDC8-414A-8FAC-1897F5711C99@dukhovni.org> Date: Mon, 18 Dec 2017 11:04:59 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: <3EDC97BF-4169-400E-80FC-1AD447905511@dukhovni.org> References: <8302CAA0-4F9F-408C-B41A-76C1FD56A9EB@dukhovni.org> <2A124E40-EE68-4847-A91A-79D178ACE181@dukhovni.org> <08d701d375ab$110712d0$33153870$@gmail.com> <20171218030137.GS3322@mournblade.imrryr.org> <05239F7E-BDC8-414A-8FAC-1897F5711C99@dukhovni.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Uta] TLSRPT further comments X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 16:05:02 -0000 > On Dec 18, 2017, at 10:50 AM, Viktor Dukhovni = wrote: >=20 > This is an esoteric topic, I don't expect that very many others > did a close reading of the document. I am sorry I got to it > somewhat late, but it is not a published RFC yet, and I hope > that bug-fixes are still possible. If one or more of the authors/editors are willing to do some rapid iterations on final changes, I promise to provide feedback in near-real-time to get through this quickly. --=20 Viktor. From nobody Mon Dec 18 08:42:44 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89B7126C25 for ; Mon, 18 Dec 2017 08:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbKnu1ldwfEw for ; Mon, 18 Dec 2017 08:42:40 -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 7B7CA1243F3 for ; Mon, 18 Dec 2017 08:42:40 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id f20so18507669lfe.3 for ; Mon, 18 Dec 2017 08:42:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=KE+e/qJASkcVzLTPwWZPw+4KCv+SbVUohO2gEZi756Q=; b=yDHi0SoSW0fTECqZRw4Hwn0BJVNAhA8p0lhrJu6bQNHnLbGwJkxJGuGhF2+gI5ieDH kNfOq56vDB7tcL52gC5J4GsiuZP6ua1nBqDD1mD9mX40/rASKE4ESQXCsJRRZgKWWzkS Kk3QXvNhfcgPtdv09UhtDSde66/VuTHXmgVdDuD/YgxCzLyhu3QAkgdVWWJKrZsMLEHr t767WqEhL61wP+4tH0mgzkgcFs3fwG3s9cZwuljHzZBINT86A4tERGm02+QdDJymy6Su jGICNMZNjOUW+PD/YtNFq6a0ud90Zpyd1FbUnezwC8rt3dHCCChwLQ+ZppW6COOFAOZn pQKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KE+e/qJASkcVzLTPwWZPw+4KCv+SbVUohO2gEZi756Q=; b=QFo/K6T+2RJDs1S1cfy8PaGThktJbWwFSj/B5TXhJ+U8sQUhN4RAiEe50gXcixSP9H WQJsXH9jQu+0cQpWPHuwavGrqtwmOzqjm8yJ81yHoDsAQl91gu46VqlfEAAOEzilsDBj wOiT1vPCo+v/P9UeNUj/YDGqQ33chslpgWKHYsyf3boJzRKunqgic7hab6/JYNo88wgP pZrHfKBuAs2qhghiloinN7B19Rtf3IhTh8ecaHMqgw9si+TfxqXo4GOI4IHWjAJkn901 OYrCGH8/YpgcSfrxoz1MwC8MRoGl9G9dAC/3LeEyUtZQu5ATfpTkZiBn8nZ9vq6VOOhQ TzLg== X-Gm-Message-State: AKGB3mLQ6chrqpBC1za3mBaZjMi535iHhp11DmVvuEuEsiPgieSa2G2G 2HMdX+o2ObkQZIKVnsbjTMGHyMAHyncDUg== X-Google-Smtp-Source: ACJfBosaGwHEEP34aHem/09pq+CPtpScM55JPef++r3fic8CatQcu43IDU2V+zwSeKntKP2i+DrxNA== X-Received: by 10.46.99.84 with SMTP id x81mr347764ljb.55.1513615358036; Mon, 18 Dec 2017 08:42:38 -0800 (PST) Received: from ?IPv6:2a02:aa1:1000:985:3dbc:b13:e271:f365? ([2a02:aa1:1000:985:3dbc:b13:e271:f365]) by smtp.gmail.com with ESMTPSA id w29sm1889354lfc.30.2017.12.18.08.42.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 08:42:36 -0800 (PST) To: uta@ietf.org References: <8302CAA0-4F9F-408C-B41A-76C1FD56A9EB@dukhovni.org> <2A124E40-EE68-4847-A91A-79D178ACE181@dukhovni.org> <08d701d375ab$110712d0$33153870$@gmail.com> <20171218030137.GS3322@mournblade.imrryr.org> <05239F7E-BDC8-414A-8FAC-1897F5711C99@dukhovni.org> From: Leif Johansson Message-ID: Date: Mon, 18 Dec 2017 17:42:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <05239F7E-BDC8-414A-8FAC-1897F5711C99@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Language: sv Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] TLSRPT further comments X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 16:42:43 -0000 On 2017-12-18 16:50, Viktor Dukhovni wrote: > > >> On Dec 18, 2017, at 8:23 AM, Leif Johansson wrote: >> >> Victor - this draft has passed WGLC and since you're the only one who >> has (so far) raised a requirement for a formal syntax here, so unless >> you or somebody provides concrete suggestions *and* there is clear WG >> support for the change, we are not going to spend more time on this. >> >> This does not *exclude* making further change but we are past the >> time for open-ended discussions about this document. > > My hope is that the authors/editors will recognize the defect and > make the necessary changes. The current syntax (of the "policy-string" > element) is under-specified. It contains just a vague example. > So the original actual intent is unclear. At the very least the > original intent should be more specific. > > This is an esoteric topic, I don't expect that very many others > did a close reading of the document. I am sorry I got to it > somewhat late, but it is not a published RFC yet, and I hope > that bug-fixes are still possible. Certainly we can do changes to the document but the IETF consensus process depends on multiple people making their voices heard - this is the rough part of "rough consensus and running code". Sometimes under-specified is actually good enough. As somebody who implements specifications I totally sympathize with your desire to have a specification that is as specific as possible... However as chair, the later in the process we get the more I'm going to insist on putting "pen to paper" in order to progress the document. Cheers Leif > > Perhaps one of the authors is willing to propose a more > explicit grammar. > > The "policy-string" should be machine-readable, and therefore > should have an explicit syntax. > From nobody Mon Dec 18 12:52:09 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B6812D86B for ; Mon, 18 Dec 2017 12:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, 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 UXmqBC7ziwEC for ; Mon, 18 Dec 2017 12:52:06 -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 692AA1200FC for ; Mon, 18 Dec 2017 12:52:06 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (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 5BC347A3309 for ; Mon, 18 Dec 2017 20:52:05 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 18 Dec 2017 15:52:03 -0500 Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Message-Id: References: <8302CAA0-4F9F-408C-B41A-76C1FD56A9EB@dukhovni.org> <2A124E40-EE68-4847-A91A-79D178ACE181@dukhovni.org> <08d701d375ab$110712d0$33153870$@gmail.com> <20171218030137.GS3322@mournblade.imrryr.org> <05239F7E-BDC8-414A-8FAC-1897F5711C99@dukhovni.org> To: uta@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Uta] TLSRPT further comments X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 20:52:08 -0000 > On Dec 18, 2017, at 11:42 AM, Leif Johansson wrote: > > Certainly we can do changes to the document but the IETF consensus > process depends on multiple people making their voices heard - this > is the rough part of "rough consensus and running code". Sometimes > under-specified is actually good enough. > > As somebody who implements specifications I totally sympathize with > your desire to have a specification that is as specific as possible... > > However as chair, the later in the process we get the more I'm going > to insist on putting "pen to paper" in order to progress the document. I am sympathetic to your perspective, and indeed an effective chair is one who moves ready documents along, fending off spurious late changes. However, in this case, I think we have a situation in which despite appearances the document is not actually ready. There were not enough eyeballs to make all the bugs shallow. * The MIME issues should be resolved, and there should not be any semantics associated with any optional "filename" for the report. The requisite metadata should be explicit in the Content-Type and (in the case of HTTP) Content-Encoding. The Content-Disposition (where any optional filenames lives) should be entirely optional. * The "policy-string" is poorly specified, the below: o "policy-string": A string representation of the policy, whether TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples: TLSA: ""_25._tcp.mx.example.com. IN TLSA ( 3 0 1 \ 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D )"" MTA-STS: ""version: STSv1\nmode: report\nmx: mx1.example.com\nmx: \ mx2.example.com\nmx: mx.backup- example.com\nmax_age: 12345678"" is not a sound way to specify the format, and JSON has array types, that obviate the need to "stringify" record-oriented data. As I already mentioned, the exammple TLSA syntax carries needless extra syntax that just makes parsing more difficult. Since the TLSA base domain is potentially subject to CNAME expansion, there needs to be text that asks the sender to specify the QNAME used to locate the TLSA RRset. I did suggest a better format for the policy string, though not a BNF grammar, but I think that the final step is easy enough. * I provided suggested text for "dane-required". * The IP address of the MX host should be included in the report schema. -- Viktor. From nobody Mon Dec 18 14:58:50 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A3E126C3D for ; Mon, 18 Dec 2017 14:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfMvtS-y3R7g for ; Mon, 18 Dec 2017 14:58:42 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B327B12D94F for ; Mon, 18 Dec 2017 14:58:41 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id a12so19572262lfe.4 for ; Mon, 18 Dec 2017 14:58:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=mwKSHWimhWHYBMNMpJEFDK7Wj7kSiawJsxhzydCXvUI=; b=mJ8N8CdgTf16VKSForEENLuXEuYRXz/Tawp9GDVFKYzvqXjdCOHAYil4N5cUvAtCTe Ynjy+1+jehUw6h4W+SHeAXb37/gCcOxsK1gb5OIrUFCOIbUUH2Y4qASi3y5zgBVrwcKa +xtGcHPsURQll8VCse3WMrEBI4d45gjFh3SLCd5JrEqrl+cZvAqm5w53QmhS6Kt1rKfs A7EhYJMhFJDlxKqcGIwLzGLE6mP7uoWMgxziu1HTRDdlpFGUSfQJgkKfULH1dQAqlaMe 2uCfY7Io3gk7kbLiuS40U23YgGHYu4Uj2A/HTGh1/xplHKtxO4iG5zRs+nZTubSyFevh bCSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mwKSHWimhWHYBMNMpJEFDK7Wj7kSiawJsxhzydCXvUI=; b=IkZXHSS+oNtUkV/2npdDwsXBFUsxNb5URoWluXrEFgzw4CnVJToaJleF+8ENfrEuJt b8mcDnnYUVU2ByISATpV0hrCG6iC888S3CTm6EfN6CfTqtpRN/yJykg6Hbu/SG0c8jNg PK/I3NkDDLqOa/26eDyrDVGOsaHmgrnNfQ/CC8us5jHNuIWNQn9Uyy9sHnUaiD9jJio3 cr1ZP43reA2GaLFkX8gAjWl3qb7czWZXpKPAi73dsWGmrNJl9swDhnrhash4fWw1Svv7 okLu1u39YyFiWyLIwtWXUHxC2U+wVb/PyGGkZ18Kn8Hmu+nHz9v/MMvCtX5eO0nu8iRB x1SQ== X-Gm-Message-State: AKGB3mIiy2xHwFRtkly08R7RxNSJNNLv8bA2uVFPLp8Suupqq7uQOTTL WXMmS+4ligwVVuov40X9FkKaaTkaQz0= X-Google-Smtp-Source: ACJfBosDGwA5VLmFkF/oJwwCNdJF0JKQsm9uTJWNh8l5NnIr1m3d06kHV97kXc/a4O6echD8JR+mug== X-Received: by 10.25.121.23 with SMTP id u23mr906224lfc.140.1513637919531; Mon, 18 Dec 2017 14:58:39 -0800 (PST) Received: from [10.0.0.129] (h-155-4-129-189.NA.cust.bahnhof.se. [155.4.129.189]) by smtp.gmail.com with ESMTPSA id r74sm2823645ljb.28.2017.12.18.14.58.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 14:58:38 -0800 (PST) To: uta@ietf.org References: <8302CAA0-4F9F-408C-B41A-76C1FD56A9EB@dukhovni.org> <2A124E40-EE68-4847-A91A-79D178ACE181@dukhovni.org> <08d701d375ab$110712d0$33153870$@gmail.com> <20171218030137.GS3322@mournblade.imrryr.org> <05239F7E-BDC8-414A-8FAC-1897F5711C99@dukhovni.org> From: Leif Johansson Message-ID: <453702c3-f2a1-1fc8-45f7-81ca1b2110ca@mnt.se> Date: Mon, 18 Dec 2017 23:58:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: sv Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] TLSRPT further comments X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 22:58:44 -0000 On 2017-12-18 21:52, Viktor Dukhovni wrote: > > >> On Dec 18, 2017, at 11:42 AM, Leif Johansson wrote: >> >> Certainly we can do changes to the document but the IETF consensus >> process depends on multiple people making their voices heard - this >> is the rough part of "rough consensus and running code". Sometimes >> under-specified is actually good enough. >> >> As somebody who implements specifications I totally sympathize with >> your desire to have a specification that is as specific as possible... >> >> However as chair, the later in the process we get the more I'm going >> to insist on putting "pen to paper" in order to progress the document. > > I am sympathetic to your perspective, and indeed an effective chair is > one who moves ready documents along, fending off spurious late changes. Great. I suggest we spend the time reading and reviewing specific text instead of spending additional time re-iterating "bugreports". Putting some words together is arguably less work than you're spending arguing that they are necessary :-) > > However, in this case, I think we have a situation in which despite > appearances the document is not actually ready. There were not enough > eyeballs to make all the bugs shallow. > > * The MIME issues should be resolved, and there should not be any > semantics associated with any optional "filename" for the report. > The requisite metadata should be explicit in the Content-Type > and (in the case of HTTP) Content-Encoding. The Content-Disposition > (where any optional filenames lives) should be entirely optional. > > * The "policy-string" is poorly specified, the below: > > o "policy-string": A string representation of the policy, whether > TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples: > TLSA: ""_25._tcp.mx.example.com. IN TLSA ( 3 0 1 \ > 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D > )"" MTA-STS: ""version: STSv1\nmode: report\nmx: > mx1.example.com\nmx: \ mx2.example.com\nmx: mx.backup- > example.com\nmax_age: 12345678"" > > is not a sound way to specify the format, and JSON has array types, > that obviate the need to "stringify" record-oriented data. As I > already mentioned, the exammple TLSA syntax carries needless extra > syntax that just makes parsing more difficult. Since the TLSA base > domain is potentially subject to CNAME expansion, there needs to > be text that asks the sender to specify the QNAME used to locate > the TLSA RRset. > > I did suggest a better format for the policy string, though not a BNF > grammar, but I think that the final step is easy enough. > > * I provided suggested text for "dane-required". > > * The IP address of the MX host should be included in the report schema. > From nobody Tue Dec 19 19:14:44 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09ED312D948 for ; Tue, 19 Dec 2017 19:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 PP51_8vGdkJS for ; Tue, 19 Dec 2017 19:14:41 -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 AE00F124D85 for ; Tue, 19 Dec 2017 19:14:41 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (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 598147A3309 for ; Wed, 20 Dec 2017 03:14:40 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: <453702c3-f2a1-1fc8-45f7-81ca1b2110ca@mnt.se> Date: Tue, 19 Dec 2017 22:14:39 -0500 Content-Transfer-Encoding: 7bit Reply-To: uta@ietf.org Message-Id: References: <8302CAA0-4F9F-408C-B41A-76C1FD56A9EB@dukhovni.org> <2A124E40-EE68-4847-A91A-79D178ACE181@dukhovni.org> <08d701d375ab$110712d0$33153870$@gmail.com> <20171218030137.GS3322@mournblade.imrryr.org> <05239F7E-BDC8-414A-8FAC-1897F5711C99@dukhovni.org> <453702c3-f2a1-1fc8-45f7-81ca1b2110ca@mnt.se> To: uta@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Uta] TLSRPT further comments X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 03:14:43 -0000 > On Dec 18, 2017, at 5:58 PM, Leif Johansson wrote: > > Great. I suggest we spend the time reading and reviewing specific text > instead of spending additional time re-iterating "bugreports". > > Putting some words together is arguably less work than you're spending > arguing that they are necessary :-) I will allocate some time to work with Alex to draft the requisite changes... -- Viktor. From nobody Wed Dec 20 02:29:45 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131D1126C22 for ; Wed, 20 Dec 2017 02:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B13mMqFQti1I for ; Wed, 20 Dec 2017 02:29:42 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 18D351200F3 for ; Wed, 20 Dec 2017 02:29:41 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id y78so17757407lfd.1 for ; Wed, 20 Dec 2017 02:29:41 -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-language:content-transfer-encoding; bh=9UdtIHK+blRz3GBIFSQSfabq5WyT9JmyVv9mJwL+Ux4=; b=n3Qdeov/cvRAbhSD9s3MzP0H3daRpR75T/I0vW2PooVFMUhBkf93pS9tbHlLKKCNMx RSeM/sXYaVorayxvFSg800mqDOAdUHJcZpZE5EaqJWPyZDJSXNG8MzRtcCvpRiTn63No xO+ZisUQkqYyIesyl/31WNuARmnZsLZZO0Ba38LZHijpXnYTr2y3auXKouSWpINROPMH A6P1UZOJ2u4VpQdenR6TUdRKn4tW+g67BwsET4xlQtYMmCy7INPL1gmJzfwTqpFCgAfk rner1v6359zzpNll1MjAMICU8yktO2NxfEj/XvyA+QdbJjVkpyUUB7Ne3uvePNph+cUt v0aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9UdtIHK+blRz3GBIFSQSfabq5WyT9JmyVv9mJwL+Ux4=; b=INpc9wVSX2zYX6ctRksuVB5g5FVLvX8tLwK9FltzjOWUkRhMezvJKY5tYbrwNt3mKy rFShJciq7n9Dm6AxcvJ16w3lx4aP6F8Nyc+dSm6tE74zT+VIVQjkRObQdLYazF+t3syx L7Xqq/NYXnEcFBBdJYmur+lHT5RvCG/+9Tdxbalq5JkcpQeiUEy3UnXFY9GW9UdXl/uL l6cgpGyMiFun0Q6KT1wwVEuetgT2jOPRGCMBuvRzyx9gyk3pi4fjq14YcQ9qnPor2tlL J+l8PlhdXzuMef6GKpxs1jOWUpoBozK4fNDfeEcDtCDzU1fw6yaeLZJ+EW7ipFQSO/eZ 6fKQ== X-Gm-Message-State: AKGB3mLFfrWja27t11yGS1B6c+hi1/tCvI1vKcTY6HiLP3mOBEQsvjET Ach4KMiBE2WNgI8SecTMC2pMbfWUIj0= X-Google-Smtp-Source: ACJfBosnZ8HrUO5qEcqYcD5UE8nFkmEcmlHTfC8nxvxBBWZMKiLthdYb521ejv3hORd2RaF3nxV03g== X-Received: by 10.46.0.86 with SMTP id 83mr4209298lja.64.1513765779516; Wed, 20 Dec 2017 02:29:39 -0800 (PST) Received: from ?IPv6:2001:6b0:7:1:51cd:cb8a:4f47:1151? ([2001:6b0:7:1:51cd:cb8a:4f47:1151]) by smtp.gmail.com with ESMTPSA id h97sm3583044lji.77.2017.12.20.02.29.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Dec 2017 02:29:38 -0800 (PST) To: uta@ietf.org References: <8302CAA0-4F9F-408C-B41A-76C1FD56A9EB@dukhovni.org> <2A124E40-EE68-4847-A91A-79D178ACE181@dukhovni.org> <08d701d375ab$110712d0$33153870$@gmail.com> <20171218030137.GS3322@mournblade.imrryr.org> <05239F7E-BDC8-414A-8FAC-1897F5711C99@dukhovni.org> <453702c3-f2a1-1fc8-45f7-81ca1b2110ca@mnt.se> From: Leif Johansson Message-ID: Date: Wed, 20 Dec 2017 11:29:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: sv Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] TLSRPT further comments X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 10:29:44 -0000 On 2017-12-20 04:14, Viktor Dukhovni wrote: > > >> On Dec 18, 2017, at 5:58 PM, Leif Johansson wrote: >> >> Great. I suggest we spend the time reading and reviewing specific text >> instead of spending additional time re-iterating "bugreports". >> >> Putting some words together is arguably less work than you're spending >> arguing that they are necessary :-) > > I will allocate some time to work with Alex to draft the requisite > changes... > Great!