From nobody Fri Jun 23 17:14:38 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 261F412EB52; Fri, 23 Jun 2017 17:07:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: uta@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826283415.7840.11907216901047114317.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:14 -0700 Archived-At: Subject: [Uta] uta - Requested session has been scheduled for IETF 99 X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:15 -0000 Dear Leif Johansson, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. uta Session 1 (1:00:00) Thursday, Afternoon Session III 1810-1910 Room Name: Berlin/Brussels size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Using TLS in Applications Area Name: Applications and Real-Time Area Session Requester: Leif Johansson Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: tokbind tls Second Priority: oauth secevent People who must be present: Keith Moore Chris Newman Orit Levin Alexey Melnikov Leif Johansson Jim Fenton Resources Requested: Special Requests: please avoid mail or security related BoFs if possible please, schedule for Thu (or Wed) --------------------------------------------------------- From nobody Wed Jun 28 03:03: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 053801287A7 for ; Wed, 28 Jun 2017 03:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMWiNpOgNFWF for ; Wed, 28 Jun 2017 03:03:35 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id E9A0212EA96 for ; Wed, 28 Jun 2017 03:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1498644214; d=isode.com; s=june2016; i=@isode.com; bh=pS+CuWezrR8qxUsMplAhbPKCgJOJSGzbpK2mwQO4HVk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Fp6zqhyBiMkFF9fyolBOnuQ0NGOEEX1NGSQ88L3P/fFb2c8Xt3LE9kay7Wrhg4HxsRhMM7 lk1+6ju+TRGmhcfJz9NJss5mGzyuu8l13GrRI8eAGrN/uScBgddDAuOxivAyrfNWePAdl7 WfWCEK3xrJDJKGV2pAFO4LKk2TAcPoA=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 28 Jun 2017 11:03:34 +0100 To: "uta@ietf.org" From: Alexey Melnikov Message-ID: <5e55c938-01b2-2163-5984-3d24063b032c@isode.com> Date: Wed, 28 Jun 2017 11:03:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-06.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 10:03:37 -0000 You can treat these comments as WGLC comments: 4.4. JSON Report Schema The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf. Section 3) { "organization-name": organization-name, "date-range": { "start-datetime": date-time, "end-datetime": date-time }, "contact-info": email-address, "report-id": report-id, "policy": { "policy-type": policy-type, "policy-string": policy-string, "policy-domain": domain, "mx-host": mx-host-pattern }, "summary": { "success-aggregate": total-successful-session-count, "failure-aggregate:" total-failure-session-count } "failure-details": [ { "result-type": result-type, "sending-mta-ip": ip-address, "receiving-mx-hostname": receiving-mx-hostname, "receiving-mx-helo": receiving-mx-helo, "session-count": failed-session-count, "additional-information": additional-info-uri, "failure-reason-code": "Text body" I think you should replace "Text body" with failure-reason-code here. } ] } JSON Report Format o "organization-name": The name of the organization responsible for the report. It is provided as a string. o "date-time": The date-time indicates the start- and end-times for the report range. It is provided as a string formatted according to Section 5.6, "Internet Date/Time Format", of [RFC3339]. The report should be for a full UTC day, 0000-2400. o "email-address": The contact information for a responsible party of the report. It is provided as a string formatted according to Section 3.4.1, "Addr-Spec", of [RFC5322]. o "report-id": A unique identifier for the report. Report authors may use whatever scheme they prefer to generate a unique identifier. It is provided as a string. o "policy-type": The type of policy that was applied by the sending domain. Presently, the only three valid choices are "tlsa", "sts", and the literal string "no-policy-found". It is provided as a string. Is this set possibly extensible? If yes, you probably need a new IANA registry. If not, you should say so. o "policy-string": The JSON string serialization ([RFC7159] section 7) of the policy, whether TLSA record ([RFC6698] section 2.3) or MTA-STS policy. o "domain": The Policy Domain is the domain against which the MTA- STS or DANE policy is defined. Need to make it clear that U-labels are not used here (unless they are!). For example, add: In the case of Internationalized Domain Names ([RFC5891]), the domain is the Punycode-encoded A-label [RFC3492] and not the U-label. 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]. Similar comment about [non-]use of U-labels. o "result-type": A value from Section 4.3, "Result Types", above. o "ip-address": The IP address of the sending MTA that attempted the STARTTLS connection. It is provided as a string representation of an IPv4 or IPv6 address in dot-decimal or colon-hexadecimal notation. Need references: RFC 5952 for IPv6 notation and reference "IPv4address" ABNF non terminal for IPv4. o "receiving-mx-hostname": The hostname of the receiving MTA MX record with which the sending MTA attempted to negotiate a STARTTLS connection. o "receiving-mx-helo": (optional) The HELO or EHLO string from the banner announced during the reported session. o "success-aggregate": The aggregate number (integer) of successfully negotiated TLS-enabled connections to the receiving site. In all other cases you describe the right hand side (the data type). So should you use "total-successful-session-count" here? o "failure-aggregate": The aggregate number (integer) of failures to negotiate an TLS-enabled connection to the receiving site. In all other cases you describe the right hand side (the data type). So should you use "total-failure-session-count" here? o "session-count": The number of (attempted) sessions that match the relevant "result-type" for this section. In all other cases you describe the right hand side (the data type). So should you use "failed-session-count" here? o "additional-info-uri": An optional URI pointing to additional Add a reference. information around the relevant "result-type". For example, this URI might host the complete certificate chain presented during an attempted STARTTLS session. Are any specific URI types mandatory to implement? E.g. "http" and "https"? o "failure-reason-code": A text field to include an TLS-related error code or error message. In Section 5.3: 5.3. Email Transport The report MAY be delivered by email. To make the reports machine- parsable for the receivers, we define a top-level media type "multipart/report" with a new parameter "report-type="tlsrpt"". Inside it, there are two parts: The first part is human readable, typically "text/plain", and the second part is machine readable with a new media type defined called "application/tlsrpt+json". If compressed, the report should use the media type "application/ tlsrpt+gzip". In addition, the following two new top level message header fields are defined: TLS-Report-Domain: Receiver-Domain TLS-Report-Submitter: Sender-Domain I would like to see a statement that these fields MUST be included. These message headers would allow for easy searching for all reports submitted by a report domain or a particular submitter, for example in IMAP: Please add a reference to RFC 3501 for IMAP here. "s SEARCH HEADER "TLS-Report-Domain" "example.com"" 6.1. Message headers Below is the Internet Assigned Numbers Authority (IANA) Permanent Message Header Field registration information per [RFC3864]. Header field name: TLS-Report-Domain Applicable protocol: smtp Per this should be "mail" instead of "smtp". Status: standard Author/Change controller: IETF Specification document(s): this one Header field name: TLS-Report-Submitter Applicable protocol: smtp As above. Status: standard Author/Change controller: IETF Specification document(s): this one In Section 6.3: As you are registering 2 different MIME types, you need to have 2 registration templates, because considerations for JSON and GZIP are slightly different. In Section 6.4: You need to specify IANA registration policy from choices listed in RFC 5226. Most likely you want "Specification Required" or "Expert Review" (both imply expert review). So you need to replace the last sentence of this section: OLD: New result types can be added to this registry without the need to update this document. NEW: New result types can be added to this registry using "Expert Review" IANA registration policy. From nobody Wed Jun 28 04:56:38 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A503F12EC1A for ; Wed, 28 Jun 2017 04:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci7hP_kbwpbs for ; Wed, 28 Jun 2017 04:56:26 -0700 (PDT) Received: from copdcmhout01.cable.comcast.com (copdcmhout01.cable.comcast.com [162.150.44.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63C491205F0 for ; Wed, 28 Jun 2017 04:56:26 -0700 (PDT) X-AuditID: a2962c47-a23ff700000232c9-0b-59539968d171 Received: from COPDCEX21.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 97.A7.13001.86993595; Wed, 28 Jun 2017 05:56:25 -0600 (MDT) Received: from COPDCEX17.cable.comcast.com (147.191.124.148) by COPDCEX21.cable.comcast.com (147.191.124.152) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 28 Jun 2017 05:56:23 -0600 Received: from COPDCEX17.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b20]) by COPDCEX17.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b20%19]) with mapi id 15.00.1263.000; Wed, 28 Jun 2017 05:56:23 -0600 From: "Brotman, Alexander" To: Alexey Melnikov , "uta@ietf.org" Thread-Topic: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-06.txt Thread-Index: AQHS7/XT4EgKDjzAdUGaCyU6l2wT5aI6KKFg Date: Wed, 28 Jun 2017 11:56:22 +0000 Message-ID: References: <5e55c938-01b2-2163-5984-3d24063b032c@isode.com> In-Reply-To: <5e55c938-01b2-2163-5984-3d24063b032c@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKKcWRmVeSWpSXmKPExsWSUDRnsm7mzOBIg439yhYzVhdZnDrazOjA 5LFkyU8mj1PNhgFMUVw2Kak5mWWpRfp2CVwZf2dtZi944l7xdtJr1gbGs8ZdjJwcEgImEts7 ZzN2MXJxCAmsYJL4NnkaG4RziFGi7dIqRpAqIYGTjBInPoiB2GwCVhJv/7czg9giAn4S3Ye2 sYPYwgKOEhdff2OFiDtJXO2dAlVjJHFg1nkWEJtFQFXi4PkWsHpeAS+Jr/uOAy3jAJpvI3Hz ryGIySlgK/H1UBhIBaOAmMT3U2uYQGxmAXGJW0/mM0HcLCCxZM95ZghbVOLl43+sELaBxNal +1ggbDmJua/vsUD06kgs2P2JDcLWlli28DUzxAWCEidnPoGqF5c4fGQH6wRG8VlI1s1C0j4L SfssJO0LGFlWMcol5xekJOdm5JeWGBjqJScm5aTqJefnJicWl4DoTYzAGFs0Tcd9B+OH87GH GAU4GJV4eO0agiOFWBPLiitzDzFmczApifLu/RIUKcSXlJ9SmZFYnBFfVJqTWqwkwts9AaiS Fy6cVJqTrSTFWzANKCoMF81LLS/OSS0BJhElOd7TXkA5cbhccWlxQWZyZn5pcXxpUQ4wajmY gcZemgEyNiWxsiq1KB9i2SFGaQ4WJXHepaeADhFITyxJzU5NLUgtgsmWc3AoSfCWgjQKFqWm p1akZeaUwKSB+phBbhJAlgE7Vpb3RXVgpJAYsgSSexV5ez4ApaWQpdGdzMTBeYgxnYMHFBx1 IHcXFyTmFmemQ60W5j2aBRTlgYmCrZXk9ZsOFBSCCSJZKcsr6g2UEoNJoVp3irGVkWPD6vVf mIRY8vLzUqXEeQtAfhYAKc8ozYN7WUqMN/a5Z6QQP5IEyGopGd5Ldw0ihUSRxBG2SynwloJ0 SSLJojoAlsVfMSYD04owbwbIdh5gAYDwsRBvPMhz3FBBsIcleINBYoJQMST/yvAqgPwrCpVB te0VMGCZgAHLMi8AFLAliSXIAasIEuWBiUIDVgkkKAQTRAlYeZCUGEwK1SapBsYU55hmt7e2 zHKy+xarnbUL/rj80qEvdXMXCroW3fJlveBXqZIy8bZvh7GGM+eab3xB12RvOE/bek3aYtVl ft+E9+IJD9xvi/N3Pvqtun6BiP+59t5YZjaTErfYMM5rf3Ruh500TTd7+cMu+uvLXvFdF3cF KEeUsszuWn2H+UAFS3fdoSJNXSWW4oxEQy3mouJEAAXnmEVYBQAA Archived-At: Subject: Re: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-06.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 11:56:29 -0000 Most of these seem reasonable, and we'll get to work sorting them out. The= only question I have is relating to: -------------- o "policy-type": The type of policy that was applied by the sending domain. Presently, the only three valid choices are "tlsa", "sts", and the literal string "no-policy-found". It is provided as a string. Is this set possibly extensible? If yes, you probably need a new IANA registry. If not, you should say so. ----------------- Sure, this set could be extended at some point in the future, but couldn't = it be addressed by a minor edit to the draft? I wouldn't think the number = of possible values would be largely expanded, if ever.=20 -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast x5364 -----Original Message----- From: Uta [mailto:uta-bounces@ietf.org] On Behalf Of Alexey Melnikov Sent: Wednesday, June 28, 2017 6:03 AM To: uta@ietf.org Subject: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-06.txt You can treat these comments as WGLC comments: 4.4. JSON Report Schema The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf. Section 3) { "organization-name": organization-name, "date-range": { "start-datetime": date-time, "end-datetime": date-time }, "contact-info": email-address, "report-id": report-id, "policy": { "policy-type": policy-type, "policy-string": policy-string, "policy-domain": domain, "mx-host": mx-host-pattern }, "summary": { "success-aggregate": total-successful-session-count, "failure-aggregate:" total-failure-session-count } "failure-details": [ { "result-type": result-type, "sending-mta-ip": ip-address, "receiving-mx-hostname": receiving-mx-hostname, "receiving-mx-helo": receiving-mx-helo, "session-count": failed-session-count, "additional-information": additional-info-uri, "failure-reason-code": "Text body" I think you should replace "Text body" with failure-reason-code here. } ] } JSON Report Format o "organization-name": The name of the organization responsible for the report. It is provided as a string. o "date-time": The date-time indicates the start- and end-times for the report range. It is provided as a string formatted according to Section 5.6, "Internet Date/Time Format", of [RFC3339]. The report should be for a full UTC day, 0000-2400. o "email-address": The contact information for a responsible party of the report. It is provided as a string formatted according to Section 3.4.1, "Addr-Spec", of [RFC5322]. o "report-id": A unique identifier for the report. Report authors may use whatever scheme they prefer to generate a unique identifier. It is provided as a string. o "policy-type": The type of policy that was applied by the sending domain. Presently, the only three valid choices are "tlsa", "sts", and the literal string "no-policy-found". It is provided as a string. Is this set possibly extensible? If yes, you probably need a new IANA registry. If not, you should say so. o "policy-string": The JSON string serialization ([RFC7159] section 7) of the policy, whether TLSA record ([RFC6698] section 2.3) or MTA-STS policy. o "domain": The Policy Domain is the domain against which the MTA- STS or DANE policy is defined. Need to make it clear that U-labels are not used here (unless they are!). For example, add: In the case of Internationalized Domain Names ([RFC5891]), the domain is the Punycode-encoded A-label [RFC3492] and not the U-label. 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]. Similar comment about [non-]use of U-labels. o "result-type": A value from Section 4.3, "Result Types", above. o "ip-address": The IP address of the sending MTA that attempted the STARTTLS connection. It is provided as a string representation of an IPv4 or IPv6 address in dot-decimal or colon-hexadecimal notation. Need references: RFC 5952 for IPv6 notation and reference "IPv4address"=20 ABNF non terminal for IPv4. o "receiving-mx-hostname": The hostname of the receiving MTA MX record with which the sending MTA attempted to negotiate a STARTTLS connection. o "receiving-mx-helo": (optional) The HELO or EHLO string from the banner announced during the reported session. o "success-aggregate": The aggregate number (integer) of successfully negotiated TLS-enabled connections to the receiving site. In all other cases you describe the right hand side (the data type). So should you use "total-successful-session-count" here? o "failure-aggregate": The aggregate number (integer) of failures to negotiate an TLS-enabled connection to the receiving site. In all other cases you describe the right hand side (the data type). So should you use "total-failure-session-count" here? o "session-count": The number of (attempted) sessions that match the relevant "result-type" for this section. In all other cases you describe the right hand side (the data type). So should you use "failed-session-count" here? o "additional-info-uri": An optional URI pointing to additional Add a reference. information around the relevant "result-type". For example, this URI might host the complete certificate chain presented during an attempted STARTTLS session. Are any specific URI types mandatory to implement? E.g. "http" and "https"? o "failure-reason-code": A text field to include an TLS-related error code or error message. In Section 5.3: 5.3. Email Transport The report MAY be delivered by email. To make the reports machine- parsable for the receivers, we define a top-level media type "multipart/report" with a new parameter "report-type=3D"tlsrpt"". Inside it, there are two parts: The first part is human readable, typically "text/plain", and the second part is machine readable with a new media type defined called "application/tlsrpt+json". If compressed, the report should use the media type "application/ tlsrpt+gzip". In addition, the following two new top level message header fields are defined: TLS-Report-Domain: Receiver-Domain TLS-Report-Submitter: Sender-Domain I would like to see a statement that these fields MUST be included. These message headers would allow for easy searching for all reports submitted by a report domain or a particular submitter, for example in IMAP: Please add a reference to RFC 3501 for IMAP here. "s SEARCH HEADER "TLS-Report-Domain" "example.com"" 6.1. Message headers Below is the Internet Assigned Numbers Authority (IANA) Permanent Message Header Field registration information per [RFC3864]. Header field name: TLS-Report-Domain Applicable protocol: smtp Per this should be "mail" instead of "smtp". Status: standard Author/Change controller: IETF Specification document(s): this one Header field name: TLS-Report-Submitter Applicable protocol: smtp As above. Status: standard Author/Change controller: IETF Specification document(s): this one In Section 6.3: As you are registering 2 different MIME types, you need to have 2 registrat= ion templates, because considerations for JSON and GZIP are slightly differ= ent. In Section 6.4: You need to specify IANA registration policy from choices listed in RFC 522= 6. Most likely you want "Specification Required" or "Expert Review"=20 (both imply expert review). So you need to replace the last sentence of this section: OLD: New result types can be added to this registry without the need to update this document. NEW: New result types can be added to this registry using "Expert Review" IANA registration policy. _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta From nobody Wed Jun 28 05:04: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 A97C11286D6 for ; Wed, 28 Jun 2017 05:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsZkbLPAebM1 for ; Wed, 28 Jun 2017 05:04:42 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 65C7A1267BB for ; Wed, 28 Jun 2017 05:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1498651481; d=isode.com; s=june2016; i=@isode.com; bh=01h/hjaU6dmMBkajkFxqYn194tWUZiMwJEl33hth6mQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=rf89CEYpbu1mctlZGlTHoBDjpPVWHz6bTMxw87dvdxAdlubZS4pR/anRzhsrIKiRnWfdyN QmXUQrl9KAiByf1eS2DfJv/R7uLHQCcUP9pWdyNqDFgNI8gFpcqhTLJ9Fbg1cKpoxz5b1o SDGoY7kp5Prr2tvBZ0iaBdF2pE7pbaQ=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 28 Jun 2017 13:04:41 +0100 To: "Brotman, Alexander" , "uta@ietf.org" References: <5e55c938-01b2-2163-5984-3d24063b032c@isode.com> From: Alexey Melnikov Message-ID: <72ef8d10-b28d-3f5c-ec19-3d630b93479e@isode.com> Date: Wed, 28 Jun 2017 13:04:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-06.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 12:04:45 -0000 Hi Alex, On 28/06/2017 12:56, Brotman, Alexander wrote: > Most of these seem reasonable, and we'll get to work sorting them out. The only question I have is relating to: > > -------------- > o "policy-type": The type of policy that was applied by the sending > domain. Presently, the only three valid choices are "tlsa", > "sts", and the literal string "no-policy-found". It is provided > as a string. > > Is this set possibly extensible? > If yes, you probably need a new IANA registry. > If not, you should say so. > ----------------- > > Sure, this set could be extended at some point in the future, but couldn't it be addressed by a minor edit to the draft? Once this document is published as an RFC, you will need to do that in another draft. But yes, this would be fine. > I wouldn't think the number of possible values would be largely expanded, if ever. > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse > Comcast > x5364 > > -----Original Message----- > From: Uta [mailto:uta-bounces@ietf.org] On Behalf Of Alexey Melnikov > Sent: Wednesday, June 28, 2017 6:03 AM > To: uta@ietf.org > Subject: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-06.txt > > You can treat these comments as WGLC comments: > > 4.4. JSON Report Schema > > The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf. > Section 3) > > { > "organization-name": organization-name, > "date-range": { > "start-datetime": date-time, > "end-datetime": date-time > }, > "contact-info": email-address, > "report-id": report-id, > "policy": { > "policy-type": policy-type, > "policy-string": policy-string, > "policy-domain": domain, > "mx-host": mx-host-pattern > }, > "summary": { > "success-aggregate": total-successful-session-count, > "failure-aggregate:" total-failure-session-count > } > "failure-details": [ > { > "result-type": result-type, > "sending-mta-ip": ip-address, > "receiving-mx-hostname": receiving-mx-hostname, > "receiving-mx-helo": receiving-mx-helo, > "session-count": failed-session-count, > "additional-information": additional-info-uri, > "failure-reason-code": "Text body" > > I think you should replace "Text body" with failure-reason-code here. > > } > ] > } > > JSON Report Format > > o "organization-name": The name of the organization responsible for > the report. It is provided as a string. > > o "date-time": The date-time indicates the start- and end-times for > the report range. It is provided as a string formatted according > to Section 5.6, "Internet Date/Time Format", of [RFC3339]. The > report should be for a full UTC day, 0000-2400. > > o "email-address": The contact information for a responsible party > of the report. It is provided as a string formatted according to > Section 3.4.1, "Addr-Spec", of [RFC5322]. > > o "report-id": A unique identifier for the report. Report authors > may use whatever scheme they prefer to generate a unique > identifier. It is provided as a string. > > o "policy-type": The type of policy that was applied by the sending > domain. Presently, the only three valid choices are "tlsa", > "sts", and the literal string "no-policy-found". It is provided > as a string. > > Is this set possibly extensible? > If yes, you probably need a new IANA registry. > If not, you should say so. > > > o "policy-string": The JSON string serialization ([RFC7159] section > 7) of the policy, whether TLSA record ([RFC6698] section 2.3) or > MTA-STS policy. > > o "domain": The Policy Domain is the domain against which the MTA- > STS or DANE policy is defined. > > Need to make it clear that U-labels are not used here (unless they are!). > For example, add: > > In the case of Internationalized Domain Names > ([RFC5891]), the domain is the Punycode-encoded A-label > [RFC3492] and not the U-label. > > > 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]. > > Similar comment about [non-]use of U-labels. > > o "result-type": A value from Section 4.3, "Result Types", above. > > o "ip-address": The IP address of the sending MTA that attempted the > STARTTLS connection. It is provided as a string representation of > an IPv4 or IPv6 address in dot-decimal or colon-hexadecimal > notation. > > Need references: RFC 5952 for IPv6 notation and reference "IPv4address" > ABNF non terminal for IPv4. > > o "receiving-mx-hostname": The hostname of the receiving MTA MX > record with which the sending MTA attempted to negotiate a > STARTTLS connection. > > o "receiving-mx-helo": (optional) The HELO or EHLO string from the > banner announced during the reported session. > > o "success-aggregate": The aggregate number (integer) of > successfully negotiated TLS-enabled connections to the receiving > site. > > In all other cases you describe the right hand side (the data type). > So should you use "total-successful-session-count" here? > > o "failure-aggregate": The aggregate number (integer) of failures to > negotiate an TLS-enabled connection to the receiving site. > > In all other cases you describe the right hand side (the data type). > So should you use "total-failure-session-count" here? > > o "session-count": The number of (attempted) sessions that match the > relevant "result-type" for this section. > > In all other cases you describe the right hand side (the data type). > So should you use "failed-session-count" here? > > o "additional-info-uri": An optional URI pointing to additional > > Add a reference. > > information around the relevant "result-type". For example, this > URI might host the complete certificate chain presented during an > attempted STARTTLS session. > > Are any specific URI types mandatory to implement? E.g. "http" and "https"? > > o "failure-reason-code": A text field to include an TLS-related > error code or error message. > > > In Section 5.3: > > 5.3. Email Transport > > The report MAY be delivered by email. To make the reports machine- > parsable for the receivers, we define a top-level media type > "multipart/report" with a new parameter "report-type="tlsrpt"". > Inside it, there are two parts: The first part is human readable, > typically "text/plain", and the second part is machine readable with > a new media type defined called "application/tlsrpt+json". If > compressed, the report should use the media type "application/ > tlsrpt+gzip". > > In addition, the following two new top level message header fields > are defined: > > TLS-Report-Domain: Receiver-Domain > TLS-Report-Submitter: Sender-Domain > > I would like to see a statement that these fields MUST be included. > > These message headers would allow for easy searching for all reports > submitted by a report domain or a particular submitter, for example > in IMAP: > > Please add a reference to RFC 3501 for IMAP here. > > "s SEARCH HEADER "TLS-Report-Domain" "example.com"" > > > 6.1. Message headers > > Below is the Internet Assigned Numbers Authority (IANA) Permanent > Message Header Field registration information per [RFC3864]. > > Header field name: TLS-Report-Domain > Applicable protocol: smtp > > Per > > this should be "mail" instead of "smtp". > > Status: standard > Author/Change controller: IETF > Specification document(s): this one > > > Header field name: TLS-Report-Submitter > Applicable protocol: smtp > > As above. > > Status: standard > Author/Change controller: IETF > Specification document(s): this one > > > In Section 6.3: > > As you are registering 2 different MIME types, you need to have 2 registration templates, because considerations for JSON and GZIP are slightly different. > > In Section 6.4: > > You need to specify IANA registration policy from choices listed in RFC 5226. Most likely you want "Specification Required" or "Expert Review" > (both imply expert review). > > So you need to replace the last sentence of this section: > > OLD: > > New result types can be added to this registry without the > need to update this document. > > NEW: > > New result types can be added to this registry using > "Expert Review" IANA registration policy. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > From nobody Wed Jun 28 06:12:37 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA46127868 for ; Wed, 28 Jun 2017 06:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBkC_Rtxn55J for ; Wed, 28 Jun 2017 06:12:34 -0700 (PDT) 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 344C1126CD8 for ; Wed, 28 Jun 2017 06:12:34 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id h22so34636989lfk.3 for ; Wed, 28 Jun 2017 06:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=v713sfE4rcNmcBVsBWk/nrllcriIXnGqlAIOZLLJp6U=; b=YBf7zW5HnNL0z19Xg1roefiKXjn6wTJp3ftnOTK3O3rPjo8nvAhmu3d7Srn1htAurP k0umx4QcozfT7URu1UQ3QqiB4z0m/Fb97zoN4ksVf4PTlpLlDroAH/wkRq7Y/1oUCUQA skFJRRhaFnTt+MQdRH4EYPTy5rEtO7Wlsa0ak1FCwELVN5ZkpjDtak1URRyIHqA02nQq dd3WAA5zdAcqpt60dkhEoZxBZ/tGWJOSatYWyas35tC2K4NbIFfDYOpHrQCdcRFHYUeg va9UBbnSLMU0TUAg1sk/dT9UhLcZoADRoV/NvE8ou2YZpqQii953Sx6QcUhXtGqUAx5W J5ag== 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=v713sfE4rcNmcBVsBWk/nrllcriIXnGqlAIOZLLJp6U=; b=uXtFWjPesenYAAauVoqAL62fEVxekEs67TPZwgmON0/2VGzNr4oa6WVnRoTfivRrkR 8JSVrVGm5f26Cp492f/DVHVHbzoaX1+geOaKSOqKntYnxGn/DDVBXoe70bmgoSLZ63gA ereLMvdl5s4T/Qxw6vtKuY0wRhkzA6Xa1zspAWadmEG2iAr/iFvvar4XoBlW9WWu050C kxiD0re8o6cQSSuMVNDhUDGEFBuD+SYevTlhTZalKCo6ah1JINtBqLd2OnzdEljBsN0P R2Jn0jHHwoslkpoynBNzsaBwZJLjDvZDhoUH7UpzTb0SHUBVpbCU2msiIXXKszTiHsrd htRA== X-Gm-Message-State: AKS2vOz1WxntINwic9rEG4QQsa1NERc31OLwNQOKefQ3TX4E5EKvvYpN 1iSGcT1KPqsahTEmMVZiqg== X-Received: by 10.25.218.9 with SMTP id r9mr3549429lfg.149.1498655552279; Wed, 28 Jun 2017 06:12:32 -0700 (PDT) Received: from [10.0.0.129] (h-155-4-129-189.NA.cust.bahnhof.se. [155.4.129.189]) by smtp.gmail.com with ESMTPSA id i68sm69103lfg.30.2017.06.28.06.12.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 06:12:31 -0700 (PDT) To: uta@ietf.org References: <5e55c938-01b2-2163-5984-3d24063b032c@isode.com> <72ef8d10-b28d-3f5c-ec19-3d630b93479e@isode.com> From: Leif Johansson Message-ID: Date: Wed, 28 Jun 2017 15:12:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <72ef8d10-b28d-3f5c-ec19-3d630b93479e@isode.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-06.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 13:12:36 -0000 Does the authors feel this version is ready for WGLC? Cheers Leif From nobody Wed Jun 28 11:17:59 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473AE129C34 for ; Wed, 28 Jun 2017 11:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-rmsFzW-RSb for ; Wed, 28 Jun 2017 11:17:56 -0700 (PDT) Received: from copdcmhout01.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99EAF129B48 for ; Wed, 28 Jun 2017 11:17:56 -0700 (PDT) X-AuditID: 60729ed4-507789a0000051a7-99-5953f2d37500 Received: from COPDCEX21.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 2B.81.20903.3D2F3595; Wed, 28 Jun 2017 12:17:55 -0600 (MDT) Received: from COPDCEX17.cable.comcast.com (147.191.124.148) by COPDCEX21.cable.comcast.com (147.191.124.152) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 28 Jun 2017 12:17:53 -0600 Received: from COPDCEX17.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b20]) by COPDCEX17.cable.comcast.com ([fe80::3aea:a7ff:fe36:8b20%19]) with mapi id 15.00.1263.000; Wed, 28 Jun 2017 12:17:53 -0600 From: "Brotman, Alexander" To: Leif Johansson , "uta@ietf.org" Thread-Topic: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-06.txt Thread-Index: AQHS7/XT4EgKDjzAdUGaCyU6l2wT5aI6KKFggABpaYCAABMEAP//8HwA Date: Wed, 28 Jun 2017 18:17:52 +0000 Message-ID: References: <5e55c938-01b2-2163-5984-3d24063b032c@isode.com> <72ef8d10-b28d-3f5c-ec19-3d630b93479e@isode.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA11Ub2wTZRzOe3ddrmMvHjfavju3yS4hISJjEj+gCFay4MQvM/tASkR2a4+2 6a2tdz3YJCYDNzCNEtxQoQpsMmDqNGZSGEqW2OGHzRgigwSIICCxc0PdyHCiCfi+92dc/dTf Pc/v9z7P83uvx9L8iFtgo/GUrMYlRSwqZhrVj7qWjd1pCNQceX/Vyh179tMrR797E/iput7e e1TdwHG5ntpY/GxIVqJbZXX5msbiyJH8dVdyhmkZ6hmi2kAHkwZuFnFPoYvTN1xpUMzyXB+F 7o7+bT3kAMq2fQvMhxGAdl95zxgp4p5Bvz/YTZN6IedHlwazBl7KPY9+nPzLZeJr0cV39lk9 69BkftioGW4xyne+ZfRAbj3a+/F9S+06QJ0TfbiJZd1Y4Nq7HOkBnBfNjvZTpKY5H7py6zBl 2uZQ75lztFl70G+/3HeZdQ3KHh2yolWig5PXGHP2CdT9zZ0is16KjvVM0qaHBWjkwC2r34eG zw669gJfxiGXcYxnHOMZx3g3YD4FlcFEMhRsjiT0VM2K6qDUpMjVwURzUNJS5HcAGLd26MIg GPugLgc4FoglsDPfEOBd0lattTkHYiwleuDZPzE0vykRao1IWmSzqiuyJi6Euc8xDOfgJl2J iQIcmsZo6Rwal7dpipzCr4lYCb9fjznfHKfpWjIajCZ0bbOuKvh2WRof2/IDOTYktb4uqwlT LAceZRnRB8EfmOLCUkqOyXJSVm12G8uKCO4iygtUOSy3bIkqKZvGc+dIAM7JGGYr4Pj2lwO8 10k4/FbBt6cwLTjp/1umWHcOhNkS7HsdMQe1pNSsRcOWdClsvInREhs1ZMvgHuKUt0GHZAX0 vIQpr00Vyo2CDsDunDoxQ/FMPBGXBR9cQU7iSHtEj89FFrxwU/7FAP+IgyDSQjk8f7UmwHsc +EN1YRHUyVSZgy00YP/NJ0AQvyul8PYUCYc/Ag8T87CbWJpngUZgBPcbV2NhjrzlcBHJ67GY QrUJvFgKL5Y5VE8Wm5JSzsVWEbTERq3FigTkbbBgsY8RymtThUpCG4h9MfXK+drF5S667I3P LsyGvzyWHvCefq365OWNHVVnMv1jnvH257TeDR8uTR/vQ+33Qj+9oCyr7EcnaTW9U/dvD8+r 8L862+VfK/DzT/361dUtt+svl++brl3974F/Lq35ZFft6p+zS7oOzmT7G9qFnLtj+dc942rR MOqMTYycfjqiiYwWkZ58nFY16T9WqtWnXAUAAA== Archived-At: Subject: Re: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-06.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 18:17:58 -0000 We believe so. We'd like to gather as many comments as possible to go with= Alexey's and bundle those up, and hopefully finalize this. -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast x5364 -----Original Message----- From: Uta [mailto:uta-bounces@ietf.org] On Behalf Of Leif Johansson Sent: Wednesday, June 28, 2017 9:13 AM To: uta@ietf.org Subject: Re: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-06.txt Does the authors feel this version is ready for WGLC? Cheers Leif _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta From nobody Wed Jun 28 14:31:18 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E445F12EB2B for ; Wed, 28 Jun 2017 14:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_JE-9hhNsCC for ; Wed, 28 Jun 2017 14:31:15 -0700 (PDT) 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 0B5F212EAE9 for ; Wed, 28 Jun 2017 14:31:14 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id l13so42389025lfl.1 for ; Wed, 28 Jun 2017 14:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=rDhzlkM67jU4PCQTs7AjXzWvpligMMsmKdVbGmBrCc0=; b=XXIRCcItTGDSGcE24OilOu2rP4RgcoMImVi+A6TdaqMoRk6/IaWJcyyxXe5lldxLa3 kXNcVx1rFhKWT/R9ATGNMJbNFWjNaBrHCEyaaFUC5PAr3OBjyMHe/C89+4DSXeORNRbe MRtmNwN/AAAu+BeAsG6yhla56k7lnFBjs9V6RxqQEW8YVrXSkkGS0YjJ6VSDCywy198T EthYVRXzOSIxq/Ym4yay6igsd3mucMNCQ12M7AQwLRPVhMI7vMt0OVjaIUc3ofPITEYG zlGgerSWNYl2x1vXMQzcnKS+HwEA+5FJ+T/BEa54kvPHGwLOCqsWTX0FeYV2NbHHpHVF PkOw== 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=rDhzlkM67jU4PCQTs7AjXzWvpligMMsmKdVbGmBrCc0=; b=HlRbq8j0U5y7J42FFQqrAgrZf43VCqwraHllS6yldXVOANbXSre5TPhTdL1sTNHeqg nVnn8Qw2K7Am8GKDHhJmkqL2kffdipjbT4UORX6eKNAvwmkVKASDb7U5gHTpAdHC6LKn xIXz5Jt6fsnIQDOckARlV6uaIKNulzzlVpz+T/XCgX3xgCyfhRyubYWiFuaR0Uw1SSRv v59UFBK24TMV5aGbOqyRRDW7s752R6X1qvy4FXfe2PkXgiyC/e7sdiSs7PTOdiB9JczQ +qcgvyosZpNnBIHAZ2Wla0MAoyQ4cd5jOTpmUYgGUFv3xGlEWDdJjtBjHmzdbRN9fsCS 944w== X-Gm-Message-State: AKS2vOz9cmR0QggzpC+0MxoqdAC/4IxbeSjKjzHDsPwCX1aS411QFEZQ Pdc8QvcSO9dXlVFx7w176g== X-Received: by 10.25.218.25 with SMTP id r25mr4214544lfg.173.1498685472758; Wed, 28 Jun 2017 14:31:12 -0700 (PDT) Received: from [10.0.0.129] (h-155-4-129-189.NA.cust.bahnhof.se. [155.4.129.189]) by smtp.gmail.com with ESMTPSA id t1sm792013lfd.23.2017.06.28.14.31.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 14:31:12 -0700 (PDT) To: uta@ietf.org References: <5e55c938-01b2-2163-5984-3d24063b032c@isode.com> <72ef8d10-b28d-3f5c-ec19-3d630b93479e@isode.com> From: Leif Johansson Message-ID: <7847a844-81fb-7cb9-a2c0-23cdabf75401@sunet.se> Date: Wed, 28 Jun 2017 23:31:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-06.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 21:31:17 -0000 On 2017-06-28 20:17, Brotman, Alexander wrote: > We believe so. We'd like to gather as many comments as possible to go with Alexey's and bundle those up, and hopefully finalize this. If you have more outstanding issues than Alexeis it might be worth while to do another version and WGLC that one... if its just Alexeis stuff right now we can deal with that in WGLC. From nobody Wed Jun 28 15:45:17 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6C812EC2A for ; Wed, 28 Jun 2017 15:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMtA5LKL_z6b for ; Wed, 28 Jun 2017 15:45:14 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601C5129413 for ; Wed, 28 Jun 2017 15:45:14 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id l13so43130675lfl.1 for ; Wed, 28 Jun 2017 15:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=4YxAE5tBn0NqDgwso406PC192MW9lRhTR8EFCvw/9CA=; b=suJR5VZ5fOmrDVa7Glkap+ElW6jMaZ4DJ1GRvthQEC69lXafLrV/slHo7yqInC5whE Gqwqln68dZElXndBNDul17LS9hxCTR/a10JCxIYlHYLK9oAhayIqTStVDlC3wcm685al xHMXBcdAVh1cZ1My7Dpz0mvse7mltSTW+YXbgdfFFFuj/1zJxdWJBP/0ZsokZ2mkWzDc ucIIIwBZ9lW/CQhpnlWNfHLeAa8SxLLSRtXDibDHtpFD7Y6ZImxJXgrH33Lm91CJI8Hh Jd6uCoAldY8ghV4uwYWDru79KnD7Bcq4llvDgA2VhtJpu99ysaUZDFdl0N9CrQaCmz6g sGkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=4YxAE5tBn0NqDgwso406PC192MW9lRhTR8EFCvw/9CA=; b=FlBPHuqKp+x/RZQasVagCKC/AKYaT2LFw5XtpU4SIPDGuAGMSXECtey8GNmPCjAb0Q EX0vvsiT3T0iamHXi1RULf2JLJxIHif5r9Ijz9n/jjIlProRypYB0PcTQ7qWdVS4h2JD 86VASq3+Uk6y1Z0oor8Grmbt7oikQU2NGT4m7/37y3c7qRllmDlSHijead4XlKixF8q5 lcTivDSlb9FcwHsGLHDPoW8nXpkWE0f5MHjaHNg5uIvi0KwhoaeEgq2HuTCPVrkuAx8O xT3n+INTM7YXw/NAg7Xo4BHWorpIBc52KqqFG+15Ly7NDUBRfnRadUSs249Wjjx16V4H Qw1A== X-Gm-Message-State: AKS2vOxt/FCEQVsrU/EszKJZOppFGLpLE2eh0d32/FZ7HFvlu2M5oHU2 Iwb0mEcJGVipuvBPlRpeqg== X-Received: by 10.25.228.212 with SMTP id x81mr4702349lfi.175.1498689911977; Wed, 28 Jun 2017 15:45:11 -0700 (PDT) Received: from [10.0.0.129] (h-155-4-129-189.NA.cust.bahnhof.se. [155.4.129.189]) by smtp.gmail.com with ESMTPSA id j200sm812611lfe.68.2017.06.28.15.45.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 15:45:11 -0700 (PDT) To: uta@ietf.org From: Leif Johansson Message-ID: Date: Thu, 29 Jun 2017 00:45:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Uta] json vs kv in draft-ietf-uta-mta-sts X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 22:45:16 -0000 This issue has been dragging out for too long and I'm party to blame for that. In Chicago there was a discussion about the relative merits of json vs key-value (kv) format in draft-ietf-uta-mta-sts. The current draft specifies json and since this is a WG draft we require WG consensus to change it to something else. In Chicago the room was roughly split on the issue. This however means there is currently /no/ consensus for changing json to kv (or anything else for that matter). There is also no clear alternative text on the table. In order to get to a conclusion on this draft we'll do the following: If anyone wants to argue for kv (or anything else) please present either a draft or a PR in github against the current draft so we have something to discuss. If the chairs don't see either of those two materialize before Prague we'll do a WGLC by Prague on draft-ietf-uta-mta-sts-06 as is which means sticking with json. Cheers Leif From nobody Wed Jun 28 15:54:32 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FE212EC2A for ; Wed, 28 Jun 2017 15:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 w8J2GWDj9ic1 for ; Wed, 28 Jun 2017 15:54:28 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7241298BA for ; Wed, 28 Jun 2017 15:54:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 71DDABE4D; Wed, 28 Jun 2017 23:54:26 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3_zIFj5Jqyk; Wed, 28 Jun 2017 23:54:24 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 545CCBE4C; Wed, 28 Jun 2017 23:54:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1498690464; bh=3kmT6y0MtrTRnPY3TSeT/sTU5Fh4A6spH/MOYtjJNYc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=aKmwQ+WZrR0U7eSIYocLn4I7u46iA581IrCna5zDE2NjFNehLsX3oYRWqw3//ENRH 2xQ98XiId7AvO8KdJZXkntA0mQx8A23hVWgGviExvO/FFcGR3dqjBsBB9lga4iaA4l lnKwjRbRmeiGp7RRvIFIDv6NqmjojaMhEAZCpZac= To: Leif Johansson , uta@ietf.org References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 28 Jun 2017 23:54:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="c0pW2Xm6wIIKbPljIUe6pQvcfn0RNEJRp" Archived-At: Subject: Re: [Uta] json vs kv in draft-ietf-uta-mta-sts X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 22:54:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --c0pW2Xm6wIIKbPljIUe6pQvcfn0RNEJRp Content-Type: multipart/mixed; boundary="kskshbvp3fiCwPJVX1WNknDtQ70ejiHOD"; protected-headers="v1" From: Stephen Farrell To: Leif Johansson , uta@ietf.org Message-ID: Subject: Re: [Uta] json vs kv in draft-ietf-uta-mta-sts References: In-Reply-To: --kskshbvp3fiCwPJVX1WNknDtQ70ejiHOD Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 28/06/17 23:45, Leif Johansson wrote: > sticking with json FWIW, as a non-implementer who has chatted with folks currently implementing sts, I think json is good enough. While I understand and sympathise with Viktor's argument for kv, I don't think that argument ought be blocking as the differences seem to me to mostly relate to the sets of libraries already linked to mta implementations, which doesn't seem to me like a winning argument, as ymmv. Which is maybe just a long-winded way of agreeing with you WG chairs :-) Cheers, S. --kskshbvp3fiCwPJVX1WNknDtQ70ejiHOD-- --c0pW2Xm6wIIKbPljIUe6pQvcfn0RNEJRp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZVDOfAAoJEC88hzaAX42iO54H/jAkq0r5UfrCjCuL7v2L5qiJ bifcqNkpNyCIxkcd16mhHgEcQCC6XxO3PYCewK8C1PhQ8AqjF/iIWYGSlG2DQT4L OBc6spRQuPZfmkWlnHgouRw5gfGr61jOz/Jj4ooU90lwTHiDNlMqCAy/2LQEaQwY gHlPW7pdvy8SqzoWEW9uVtCZXy2ktAwBAVkYDN0yiuFR6CRpJppj9D7N8r1FCcji Qjky4570MUJKaSFTP0qlx88V7TuSqvkMENTOn3VvbA3OT5P69uNpG7F6WDeuN56I qwA3XMbpEs3UMABTQFKmQVAlafPfd96a3C3JYXb5TmwZFOeqaeKS9vDE/y19wY8= =tzKW -----END PGP SIGNATURE----- --c0pW2Xm6wIIKbPljIUe6pQvcfn0RNEJRp-- From nobody Thu Jun 29 00:26:54 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3848129B29 for ; Thu, 29 Jun 2017 00:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxDA8eNCVXUP for ; Thu, 29 Jun 2017 00:26:51 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A713B129C0B for ; Thu, 29 Jun 2017 00:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1498721209; d=isode.com; s=june2016; i=@isode.com; bh=SGvYyYRaTu0B+eaHmglGVc/VLwqxjnD48fyfsj5Y4FM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=P/08b81nT8YWScd6gKhpBIvmDmjylVqLXSZZ8OA5qHGs/UTwI98dCDtSfc2PwQu/XXq0Pq CoUW7mAm1XRR6UJJAXI+o9RETEWeViFEpMXPbFfmtdT+EPnc67kXxUkVfclqjiGYWPsGyD jxcW9zogmwshZGdIhr0QG3zuPE4mtlI=; Received: from [192.168.0.6] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 29 Jun 2017 08:26:49 +0100 From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: <7847a844-81fb-7cb9-a2c0-23cdabf75401@sunet.se> Date: Thu, 29 Jun 2017 08:50:38 +0100 Cc: uta@ietf.org Message-Id: References: <5e55c938-01b2-2163-5984-3d24063b032c@isode.com> <72ef8d10-b28d-3f5c-ec19-3d630b93479e@isode.com> <7847a844-81fb-7cb9-a2c0-23cdabf75401@sunet.se> To: Leif Johansson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-06.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 07:26:53 -0000 > On 28 Jun 2017, at 22:31, Leif Johansson wrote: >=20 >> On 2017-06-28 20:17, Brotman, Alexander wrote: >> We believe so. We'd like to gather as many comments as possible to go wi= th Alexey's and bundle those up, and hopefully finalize this. >=20 > If you have more outstanding issues than Alexeis it might be worth while > to do another version and WGLC that one... if its just Alexeis stuff > right now we can deal with that in WGLC. I am Ok with treating my input as WGLC. Most of the things I reported are mi= ssing references or nits. From nobody Thu Jun 29 06:02:58 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D939129B7F for ; Thu, 29 Jun 2017 06:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emeUQmz-9ZM9 for ; Thu, 29 Jun 2017 06:02:55 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07BE129AC6 for ; Thu, 29 Jun 2017 06:02:55 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 5D9DE7A32F1 for ; Thu, 29 Jun 2017 13:02:54 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 29 Jun 2017 09:02:53 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: uta@ietf.org Message-Id: References: To: uta@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Uta] json vs kv in draft-ietf-uta-mta-sts X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 13:02:58 -0000 > On Jun 28, 2017, at 6:54 PM, Stephen Farrell = wrote: >=20 > While I understand and sympathise with Viktor's argument > for kv, I don't think that argument ought be blocking as > the differences seem to me to mostly relate to the sets > of libraries already linked to mta implementations, which > doesn't seem to me like a winning argument, as ymmv. The point is not so much about this or that library, but about needless complexity and bloat. JSON, XML, ASN.1, ... are much too general and complex for the task at hand. Good engineering is about making things as simple as possible (and no simpler), and JSON fails the test. It is, and remains, entirely unnecessary for STS. BTW, I did suggest a few candidate KV encodings upthread. --=20 Viktor.= From nobody Thu Jun 29 06:18:02 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 82D5512EC14; Thu, 29 Jun 2017 06:18:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: uta@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149874228049.6468.6647983832951662733@ietfa.amsl.com> Date: Thu, 29 Jun 2017 06:18:00 -0700 Archived-At: Subject: [Uta] I-D Action: draft-ietf-uta-mta-sts-07.txt X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 13:18:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications of the IETF. Title : SMTP MTA Strict Transport Security (MTA-STS) Authors : Daniel Margolis Mark Risher Binu Ramakrishnan Alexander Brotman Janet Jones Filename : draft-ietf-uta-mta-sts-07.txt Pages : 19 Date : 2017-06-29 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-07 https://datatracker.ietf.org/doc/html/draft-ietf-uta-mta-sts-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-mta-sts-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 29 06:24:07 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94BC129789 for ; Thu, 29 Jun 2017 06:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 MLg_ulvMbHNq for ; Thu, 29 Jun 2017 06:24:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9224012714F for ; Thu, 29 Jun 2017 06:24:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3BB26BE5B; Thu, 29 Jun 2017 14:24:01 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okKp6hS3bH2j; Thu, 29 Jun 2017 14:23:59 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5F5B5BE4D; Thu, 29 Jun 2017 14:23:59 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1498742639; bh=/f8tNybaVZjRSaNRBK0JwGQ75wPnamR1MlSdgZBe9tk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=zmeiAX9JuwujPWe/hYANO1tqucSzVj9MHmrgQH16YKK1sC/vxVvJHmmkjEE7Ug+RI dl7PaEDSItD82V2kn8T0zhHCElGrOZa3xcK+BeGsMucre8TsAkTvj/+FB+K1iQymRh YSJuInjI3QCkzykysjXv4VWfYKaumKlSj5MRMmXU= To: uta@ietf.org, Viktor Dukhovni References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <6a908497-a342-322a-e0eb-ce8d4a7244f6@cs.tcd.ie> Date: Thu, 29 Jun 2017 14:23:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="m5lMm7p29LAEplnoNGQO0g8oJjrOcfHHS" Archived-At: Subject: Re: [Uta] json vs kv in draft-ietf-uta-mta-sts X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 13:24:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --m5lMm7p29LAEplnoNGQO0g8oJjrOcfHHS Content-Type: multipart/mixed; boundary="ehNKwgqUmILnkJeT5Wf6wN0otgB6eCHOh"; protected-headers="v1" From: Stephen Farrell To: uta@ietf.org, Viktor Dukhovni Message-ID: <6a908497-a342-322a-e0eb-ce8d4a7244f6@cs.tcd.ie> Subject: Re: [Uta] json vs kv in draft-ietf-uta-mta-sts References: In-Reply-To: --ehNKwgqUmILnkJeT5Wf6wN0otgB6eCHOh Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 29/06/17 14:02, Viktor Dukhovni wrote: >=20 >> On Jun 28, 2017, at 6:54 PM, Stephen Farrell wrote: >> >> While I understand and sympathise with Viktor's argument >> for kv, I don't think that argument ought be blocking as >> the differences seem to me to mostly relate to the sets >> of libraries already linked to mta implementations, which >> doesn't seem to me like a winning argument, as ymmv. >=20 > The point is not so much about this or that library, but about > needless complexity and bloat. JSON, XML, ASN.1, ... are much > too general and complex for the task at hand. The library point is relevant because some people will already have json support, at which point there is no additional complexity, for them. (That said, I've always been neutral in religious debates about data definition language fashions, but do realise that a lot of people have much stronger feelings. In any case, the use of terms like "bloat" etc doesn't convince me of anything:-) > Good engineering is about making things as simple as possible > (and no simpler), and JSON fails the test. It is, and remains, > entirely unnecessary for STS. I don't see any new argument there. In fact, it seems like a pretty old, worn out and overly generic argument to me;-) >=20 > BTW, I did suggest a few candidate KV encodings upthread. Given that it seems nobody else is jumping on board with that, maybe now it's time to just move on? Having spoken with the folks behind this spec, I am very sure that above all else they want to get done and are finding the lack of closure on this particular aspect very very frustrating. And all the moreso as they would've happily used kv if that were the clear consensus. As-is, they have come and some deployment with the json stuff (IIUC), so ISTM that in the absence of any spec'd out alternative the right thing for the WG to do is clear. (Even if it's a pity that that right thing is not what you'd chose for postfix.) Cheers, S. --ehNKwgqUmILnkJeT5Wf6wN0otgB6eCHOh-- --m5lMm7p29LAEplnoNGQO0g8oJjrOcfHHS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZVP9uAAoJEC88hzaAX42i7+cH/1DmwdAMoP+GgQ5iNQEipIp4 2+XuukJ+JOozhwGraPUT4vttVSwntiEwZvlEe4Jmhi84XZ2DWUmQ/GldYVUtZ6S/ 72zQQEOojc0yqhf0pLt0CFUvbk4ZtXb3MQuIBQhzTpPoUWAiH6bxIf3ydyCJEvJF 5LqBBRATu3azaA6DmUddXMyRXOa10HOrHoMVaX/KShsFZmO0enhvwJUIL6lSI+km HZcQfDmiV/g+vNb5J8+HzXusp81tL+74w+/L1pN0wsLiqf4tG0SqJ0rdAnGQNsbB Jb52K863YraTmeUfa1U7NwG+LXla2OAEwcLRb5uVC6mB/Abi8YaqA7EJcvz8ukA= =pEBU -----END PGP SIGNATURE----- --m5lMm7p29LAEplnoNGQO0g8oJjrOcfHHS-- From nobody Thu Jun 29 07:07:35 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48508127ABE for ; Thu, 29 Jun 2017 07:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8R_6v_8eC8l for ; Thu, 29 Jun 2017 07:07:33 -0700 (PDT) Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D0E1129B10 for ; Thu, 29 Jun 2017 07:07:29 -0700 (PDT) X-AuditID: 44571fa7-cb9ff7000001febd-81-5955099f65e3 Received: from PACDCEX23.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 6E.5E.65213.F9905595; Thu, 29 Jun 2017 10:07:28 -0400 (EDT) Received: from PACDCEX19.cable.comcast.com (24.40.1.142) by PACDCEX23.cable.comcast.com (24.40.1.146) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 29 Jun 2017 10:07:26 -0400 Received: from PACDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8304]) by PACDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8304%19]) with mapi id 15.00.1263.000; Thu, 29 Jun 2017 10:07:26 -0400 From: "Brotman, Alexander" To: "uta@ietf.org" Thread-Topic: Updated MTA-STS Draft Thread-Index: AdLw4J6wY10IZZE5QLGwl9BYuF7urw== Date: Thu, 29 Jun 2017 14:07:26 +0000 Message-ID: <766981d8628442feb452f234a7982144@PACDCEX19.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA11Tf2wTZRjOd72Nr7PfuF3X9qOWbhySKOLsIn8MQog/o4ImGEUohoxbe7bN bm29H8DAkAJGzCA6Eg1bg26QIVBmJjAiurGErkI2kkGI2YyIiYJMphMGIwsMht9dr+PqP+17 z/M97/O+z3cHLexxqxtGooogRXmRKyyiX17FeZ5pta70+5JjqKr/x+3gefBaW9tdagVYU7Qk KIiR9YL07NJ1ReHzfefo+Di18fLEIUsCHKQagBViZiHeOnmHbgBFkGV+oHDH7muU8QDw5MfD BtMH8Kffp3RJIbMYjz7cYdHqUmYO/uv+jRlabWe8eCDVZOBz8e3u4YJsXYE/650iZyCkmXn4 cO9mDUbMMnz4UqN+HDBOPNHfrre3MC78y9UWYzoGt3Wft2RrB75+ZaogW/vwiQM9dLYuw5nG KTqrXYBbu24VZuun8df7/rZkvUpwX/NV47wL92ZOFjQCR9JklzTJkyZ50iRvBXQKeON8IBio C8dUxVdZEeBrRKEiEKsL8LKi/R8D+p2UHTwJTu1ZmwYMBJwNDd55x88W8Ovl+ro0qIUU50CV wwQqrokF68O8HK6WVFGQuVKUmSQwmoZrVLGWcyMXuV/WPo1GhQ2yKCjkJeC86Nyyt/2sa5qT VTkeCURiqlytSmIaYGghbU/NIA1QkK/fJEixrFkaPA5pzoU+UIgjE+IVoVYQ4oKUYzdAyGEU hERYIgkhYeP7EVHJ0US3U2MYM6MPOxu9UkoaOs2Ead45aNfNt/ys20z/f2QKWtMgBG1k7t+1 4JAc5+vkSMiwtqPv7hHUlkN121kooa3I5kCT5WzkWE4icuaofLt+sBvAbTc7xynYmTxBfts7 uscplo7GooLbhe5pXRlNGlaj0+u7nWjt8Ot+dqaJ0MZwe9DFyz4/6zDhjyZxlyNVU80ysfnD 5D7oERAg740d9WoZ28jn/mh7Fl3QwMcMUF8eo5R+TQZm2t2DyrXdHQaT7zZCQqZIyPYmPWSF V8whX2rSQzZQI+QvNZDNgXkhD2mUM0flO7kToJm27j/jfaJs7NWB62NSy8ozb174Y/mf1/aG PR/9U1qiDhV3feKZ+e/On7ecjh7d7BMOfeW4vebz0MSNXYl13iWLBjLPDXJHE1sSR1JfXPzp G6bkpXdfZEa/nX/lt9HM6rMNO0aeurWnu2rwBdxy+slFQw+GisunIh8+eGNel/+9ql/Fzh5b M0fLYb5yvkWS+f8AAbwLmUYFAAA= Archived-At: Subject: [Uta] Updated MTA-STS Draft X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 14:07:34 -0000 All, A new draft for MTA-STS has been submitted. The changes include some wordi= ng relating to Certificate Validation, and IANA Registry sections. There i= s also some discussion on the list about the JSON/KV subject. We are looki= ng forward to feedback regarding the previous items. Thank you. -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast x5364 From nobody Thu Jun 29 13:27:31 2017 Return-Path: X-Original-To: uta@ietfa.amsl.com Delivered-To: uta@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66CE12EACC for ; Thu, 29 Jun 2017 13:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1kqmPejKb68 for ; Thu, 29 Jun 2017 13:27:29 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6CBC126DC2 for ; Thu, 29 Jun 2017 13:27:28 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id z78so17703634lff.0 for ; Thu, 29 Jun 2017 13:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=p24Am43+GXmo0xZUAPBRbuUWXTl5QKDKfy37kAdqmKY=; b=p6bmXBjNi81NzXftxq+ueoeHAfibWz6gSRRGjXAWF7hbnhIqbZr89yhPk8Wj/wjppj 0RmJ4tyytpFLBZpbyGj7Uq1/EmS84o5yiM7vQPZtyrK/MG/g3beLFAURuhH2XRXf1RCZ CbXQ0ayvhVDakZLnDB27GUdezsG/8TrsfuY2nCGKrRY63jmu2L3OFetoZQWlfzmeNwBv YPeaRvAJb9X6jd0xJFmeX8BvNprSQda7BIlOEa3ijWSbGK7m2A+lsUvfdlvMSwOOzJxp vfkPmQFYAdoduK0Dk2ZgfGn9UMlkURH/dQIpSRTdqbyZoOFkFCxDzHoKMWxGGG6/8+1h /JmQ== 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=p24Am43+GXmo0xZUAPBRbuUWXTl5QKDKfy37kAdqmKY=; b=H7+74ynicjejRvkKimIDCKuN8kfxNtGoNSBu+lmhzaupx03A/C+gisSkeMhNjLxU+a uWNFY0G+bMfhar4sowAt3XZknMPj1JO1x3TZdKtQGo0sCA91n/Etz0bVrIBf43JKidoA Kv6tHhZ5mDROTR568b/rq+zsTSj/JYwtYSCDmmI4rOiIprNQoA7wppeeTt5ZgRG71tYr IqVReBWU9/5ctm29bZash7iCp15EB4ptL4Bt8kVe4yHQgod79Nur6y+kaM7lLpyDBDpl sbXTofOlrWpekhsYxjriLniI6SBGGlfuux/RXCa/bSIhcRFAl65rbqddPalYPI+kKyZZ A6Qg== X-Gm-Message-State: AKS2vOx8bUBYk8tY+zqnmNXHxWJySmhUbJKWfHtr64eKdQbv60BEGYSe V6oFOzZTYTrckLYgU9RvjA== X-Received: by 10.46.9.140 with SMTP id 134mr2126020ljj.42.1498768046638; Thu, 29 Jun 2017 13:27:26 -0700 (PDT) Received: from [10.0.0.129] (h-155-4-129-189.NA.cust.bahnhof.se. [155.4.129.189]) by smtp.gmail.com with ESMTPSA id o9sm1500667lfo.48.2017.06.29.13.27.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 13:27:25 -0700 (PDT) To: uta@ietf.org References: From: Leif Johansson Message-ID: <22cc43e4-fe7f-36b3-462b-6f3e99073c55@mnt.se> Date: Thu, 29 Jun 2017 22:27:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Uta] json vs kv in draft-ietf-uta-mta-sts X-BeenThere: uta@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: UTA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 20:27:31 -0000 > BTW, I did suggest a few candidate KV encodings upthread. > Please format one of them as a PR against the current draft so we have something concrete to evaluate.