From nobody Sun Jan 10 17:37:08 2016 Return-Path: X-Original-To: shutup@ietfa.amsl.com Delivered-To: shutup@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBAA1A21B5 for ; Sun, 10 Jan 2016 17:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=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 46ERGtsxjIeq for ; Sun, 10 Jan 2016 17:36:48 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E9F1A21B1 for ; Sun, 10 Jan 2016 17:36:47 -0800 (PST) Received: (qmail 3922 invoked from network); 11 Jan 2016 01:36:45 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 11 Jan 2016 01:36:45 -0000 Date: 11 Jan 2016 01:36:23 -0000 Message-ID: <20160111013623.43568.qmail@ary.lan> From: "John Levine" To: ietf-smtp@ietf.org, shutup@ietf.org In-Reply-To: <5692DAE2.2050107@bluepopcorn.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: fenton@bluepopcorn.net Subject: Re: [Shutup] [ietf-smtp] Fwd: New Version Notification for draft-fenton-smtp-require-tls-00.txt X-BeenThere: shutup@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMTP Headers Unhealthy To User Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 01:36:50 -0000 In article <5692DAE2.2050107@bluepopcorn.net> you write: >-=-=-=-=-=- >-=-=-=-=-=- > >Below is the announcement of a draft I just submitted that may be of >interest to this list. The approach here is complementary to the other >proposals I have seen along these lines (e.g., smtp-sts). > >Thoughts, reviews, etc. welcomed. Interesting idea. I implemented it on my server mail1.iecc.com. R's, John PS: Of course, there's no way you can tell whether it'll actually do anything different if you set requiretls. The inability to detect, much less penalize, lying strikes me as a problem. From nobody Sun Jan 10 19:15:58 2016 Return-Path: X-Original-To: shutup@ietfa.amsl.com Delivered-To: shutup@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6281A6F99; Sun, 10 Jan 2016 19:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 gVCwjY8Rn-r8; Sun, 10 Jan 2016 19:15:56 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202461A6F8E; Sun, 10 Jan 2016 19:15:55 -0800 (PST) Received: from [IPv6:2001:470:1f05:bfe::3] ([IPv6:2001:470:1f05:bfe::3]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id u0B3FqOx022628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 10 Jan 2016 19:15:54 -0800 To: John Levine , ietf-smtp@ietf.org, shutup@ietf.org References: <20160111013623.43568.qmail@ary.lan> From: Jim Fenton X-Enigmail-Draft-Status: N1110 Message-ID: <56931E68.5040707@bluepopcorn.net> Date: Sun, 10 Jan 2016 19:15:52 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20160111013623.43568.qmail@ary.lan> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1452482155; bh=pKIGsMiH4jhxFwyrx0aJNH/uw4Des+74c57dPBEjWns=; h=Subject:To:References:From:Date:In-Reply-To; b=R11jEngg9im3gAe7rGOVIWJgl+GXSZmUIFcSF2E4pADA8Pyj2sOYIgCgt1XBGV+Ir MvE8WgfulmKxUnMcLIYN4OMzoDAkyrL/b/xH48cFMwAKiAPfEWAF0Qn+xVQcQkUdin p1BQrv9RjGDKBWfP5Ms+iHiLqv6WcpGMbOX4Ovq0= Archived-At: Subject: Re: [Shutup] [ietf-smtp] Fwd: New Version Notification for draft-fenton-smtp-require-tls-00.txt X-BeenThere: shutup@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMTP Headers Unhealthy To User Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 03:15:57 -0000 [not sure if this is germane to the shutup list if I understand the charter there correctly, but I'll go along with it for now] On 01/10/2016 05:36 PM, John Levine wrote: > In article <5692DAE2.2050107@bluepopcorn.net> you write: >> -=3D-=3D-=3D-=3D-=3D- >> -=3D-=3D-=3D-=3D-=3D- >> >> Below is the announcement of a draft I just submitted that may be of >> interest to this list. The approach here is complementary to the other= >> proposals I have seen along these lines (e.g., smtp-sts). >> >> Thoughts, reviews, etc. welcomed. > Interesting idea. I implemented it on my server mail1.iecc.com. That was quick :) > PS: Of course, there's no way you can tell whether it'll actually do > anything different if you set requiretls. The inability to detect, > much less penalize, lying strikes me as a problem. You're describing a mail server that not just hasn't deployed TLS and REQUIRETLS, but one that is being actively deceptive. There are more fundamental undetected issues even without REQUIRETLS. As a mail originator sending messages I consider sensitive, my biggest concern would be that my outgoing mail operator isn't lying about REQUIRETLS. There could easily be test reflectors that fail REQUIRETLS in various ways, i.e., not supporting TLS at all, not supporting REQUIRETLS, and offering certificates that don't meet various verification requirements. If the messages go through, the user knows that someone is lying. The more general cases of REQUIRETLS deception, particularly within an administrative management domain, may be hard to test, but those probably aren't the biggest areas of concern for TLS deployment either. -Jim From nobody Mon Jan 11 08:34:27 2016 Return-Path: X-Original-To: shutup@ietfa.amsl.com Delivered-To: shutup@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B0C1A8767 for ; Mon, 11 Jan 2016 08:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=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 eoab-YcZgz8S for ; Mon, 11 Jan 2016 08:34:25 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADAC91A883E for ; Mon, 11 Jan 2016 08:34:24 -0800 (PST) Received: (qmail 11504 invoked from network); 11 Jan 2016 16:34:23 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 11 Jan 2016 16:34:23 -0000 Date: 11 Jan 2016 16:34:01 -0000 Message-ID: <20160111163401.48404.qmail@ary.lan> From: "John Levine" To: ietf-smtp@ietf.org, shutup@ietf.org In-Reply-To: <5693D70F.7040503@bluepopcorn.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: fenton@bluepopcorn.net Subject: Re: [Shutup] [ietf-smtp] Fwd: New Version Notification for draft-fenton-smtp-require-tls-00.txt X-BeenThere: shutup@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMTP Headers Unhealthy To User Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 16:34:26 -0000 >> Only sort of. In this case, the downgrade path is obvious, you >> ignore the TLS flag and send the message along. > >That's the opposite of the goal here. SMTP makes tries to delivery >messages, even if that results in a downgrade in security. The goal here >is to fail the transmission of REQUIRETLS tagged messages that can't be >sent in accordance with the originator's security requirements. Of course, but there's no reason for recipient MTAs to pay any attention to the tag if they don't want to. There is no penalty to them for doing so. With EAI there's at least the penalty of messages getting smashed. >But you make a good point about the fake MX problem: if you're concerned >about DNS attacks, you need to make sure that the recipient domain, and >not just the domain of the MX server, is DNSSEC protected. That's an >oversight in the specification I will correct. RFC 7672 which has already addressed that issue in great detail. R's, John From nobody Mon Jan 11 11:26:04 2016 Return-Path: X-Original-To: shutup@ietfa.amsl.com Delivered-To: shutup@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996891A908C; Mon, 11 Jan 2016 11:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 2fgU4zhPIzlg; Mon, 11 Jan 2016 11:25:59 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548991A908A; Mon, 11 Jan 2016 11:25:53 -0800 (PST) Received: from splunge.local ([12.130.117.99]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id u0BJPlg6030786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 11 Jan 2016 11:25:50 -0800 To: John Levine , ietf-smtp@ietf.org, shutup@ietf.org References: <20160111163401.48404.qmail@ary.lan> From: Jim Fenton X-Enigmail-Draft-Status: N1110 Message-ID: <569401A8.70507@bluepopcorn.net> Date: Mon, 11 Jan 2016 11:25:28 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160111163401.48404.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1452540352; bh=TK0sT0Cs8o/awp0OPkzv26iszJpvM1N3NHSY5ts/Qfo=; h=Subject:To:References:From:Date:In-Reply-To; b=m7qn1468kso1BwsiY8gu5Zxnei4d+6sYA4JVQPwcvn8QptwF6JYbGiDSEKpzNAWUG W22Su2cHn7pzfkZQ/H9ttsWbAy8PI+D7viGLa6w4xMQo1bRjYN1IcONjHGUGanKbes wzi7dleg9aqhA72qRfdVxpvbEmPO0HcOlneUvSm8= Archived-At: Subject: Re: [Shutup] [ietf-smtp] Fwd: New Version Notification for draft-fenton-smtp-require-tls-00.txt X-BeenThere: shutup@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMTP Headers Unhealthy To User Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 19:26:01 -0000 On 1/11/16 8:34 AM, John Levine wrote: >>> Only sort of. In this case, the downgrade path is obvious, you >>> ignore the TLS flag and send the message along. >> That's the opposite of the goal here. SMTP makes tries to delivery >> messages, even if that results in a downgrade in security. The goal he= re >> is to fail the transmission of REQUIRETLS tagged messages that can't b= e >> sent in accordance with the originator's security requirements. > Of course, but there's no reason for recipient MTAs to pay any > attention to the tag if they don't want to. There is no penalty to > them for doing so. With EAI there's at least the penalty of messages > getting smashed. Misbehavior by MTAs is outside the scope of the threat model for SMTP TLS. I have already described how such behavior could be detected; the erosion of trust resulting from that is likely to be harmful to the mail provider's business model. -Jim From nobody Mon Jan 11 18:01:18 2016 Return-Path: X-Original-To: shutup@ietfa.amsl.com Delivered-To: shutup@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCC21ACD17 for ; Mon, 11 Jan 2016 18:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=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 hF7qKXzvqKlh for ; Mon, 11 Jan 2016 18:01:08 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D2B1ACD1C for ; Mon, 11 Jan 2016 18:01:05 -0800 (PST) Received: (qmail 6194 invoked from network); 12 Jan 2016 02:01:04 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 12 Jan 2016 02:01:04 -0000 Date: 12 Jan 2016 02:00:41 -0000 Message-ID: <20160112020041.49761.qmail@ary.lan> From: "John Levine" To: ietf-smtp@ietf.org, shutup@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: mrsam@courier-mta.com Subject: Re: [Shutup] [ietf-smtp] DNSSEC, was New Version Notification for draft-fenton-smtp-require-tls-00.txt X-BeenThere: shutup@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMTP Headers Unhealthy To User Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 02:01:11 -0000 >Last time I checked, setting up DNSSEC is still a bit painful. Few >registrars, TMK, support DNSSEC directly. Maybe this has changed. https://www.icann.org/resources/pages/deployment-2012-02-25-en It's changed somewhat. Some large registrars like Godaddy, Gandi, and Tucows support it, some like NetSol don't. I have about 300 zones on my DNS server, all signed locally, but I've only been able to upload the DS records for half of them. For DANE, application software that supports TLSA and DNSSEC based TLS verification is still pretty thin. Versions of opsnssl with DANE support only became available within the past month. Having said all that, it's still far from clear to me that something other than DANE would work any better, particularly considering how cruddy the CA world is turning out to be. From nobody Tue Jan 12 00:56:24 2016 Return-Path: X-Original-To: shutup@ietfa.amsl.com Delivered-To: shutup@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064881A1B43; Tue, 12 Jan 2016 00:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 nSQa9rYGirFU; Tue, 12 Jan 2016 00:56:19 -0800 (PST) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id D77BE1A1B7C; Tue, 12 Jan 2016 00:56:17 -0800 (PST) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3pfm3N1WzSz1L8rt; Tue, 12 Jan 2016 09:56:16 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3pfm3N020sz5Mgg9; Tue, 12 Jan 2016 09:56:16 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id B90C912358C; Tue, 12 Jan 2016 09:56:15 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sVxx6ScftJCp; Tue, 12 Jan 2016 09:56:12 +0100 (CET) Received: from jaguar.sonnection.nl (jaguar.sonnection.nl [192.168.1.21]) by jaguar.sonnection.nl (Postfix) with ESMTP id A1F7F123577; Tue, 12 Jan 2016 09:56:12 +0100 (CET) Date: Tue, 12 Jan 2016 09:56:11 +0100 (CET) From: "Rolf E. Sonneveld" To: John Levine Message-ID: <1116616617.55894.1452588971191.JavaMail.root@sonnection.nl> In-Reply-To: <20160112020041.49761.qmail@ary.lan> References: <20160112020041.49761.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.0_GA_5434 (ZimbraWebClient - FF43 (Linux)/8.0.0_GA_5434) Thread-Topic: DNSSEC, was New Version Notification for draft-fenton-smtp-require-tls-00.txt Thread-Index: LR6ctqFrCYKojf8YMRQnguinaXoyFw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1452588976; bh=lWXti7F4mjw12bdtIvV0GwgzO5opRB8x99NTCIXMjwE=; h=Date:From:To:Message-ID:Subject:From; b=fIwG5/TelN7Bqd7KG9644RcJNEuh6kemDhbXaFB51EJY6ddyVWaQ6ZuYeVBIamBt1 F27iPKDf0i48393lpycEi1RCEa76xNCZ6dh/MHGIRv2rthD8VY3TnL9D0O6dlgLs8Q 4a48xKL1DZlNd7l/ItmC1XrTjVLyubfEEeoQbW1A= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3pfm3N1WzSz1L8rt Archived-At: Cc: mrsam@courier-mta.com, shutup@ietf.org, ietf-smtp@ietf.org Subject: Re: [Shutup] [ietf-smtp] DNSSEC, was New Version Notification for draft-fenton-smtp-require-tls-00.txt X-BeenThere: shutup@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMTP Headers Unhealthy To User Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 08:56:21 -0000 > >Last time I checked, setting up DNSSEC is still a bit painful. Few > >registrars, TMK, support DNSSEC directly. Maybe this has changed. > > https://www.icann.org/resources/pages/deployment-2012-02-25-en > > It's changed somewhat. Some large registrars like Godaddy, Gandi, > and > Tucows support it, some like NetSol don't. I have about 300 zones on > my DNS server, all signed locally, but I've only been able to upload > the DS records for half of them. > > For DANE, application software that supports TLSA and DNSSEC based > TLS > verification is still pretty thin. Versions of opsnssl with DANE > support only became available within the past month. > > Having said all that, it's still far from clear to me that something > other than DANE would work any better, particularly considering how > cruddy the CA world is turning out to be. As with IPv6 it considerably varies per country/region/TLD. Statistics for the ccTLD .nl can be found here: http://stats.sidnlabs.nl/#dnssec It appears some 43.9 percent of the 5.5 million domainnames under .nl are signed (2.4 million domainnames). The page shows also some information about DANE queries. This however doesn't say anything about the registrars... /rolf From nobody Fri Jan 29 10:07:40 2016 Return-Path: X-Original-To: shutup@ietfa.amsl.com Delivered-To: shutup@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3C11A8AFB for ; Fri, 29 Jan 2016 10:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.264 X-Spam-Level: ** X-Spam-Status: No, score=2.264 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_27=0.6, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=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 3n6T5P8jx7De for ; Fri, 29 Jan 2016 10:07:37 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E951A906A for ; Fri, 29 Jan 2016 10:07:36 -0800 (PST) Received: (qmail 94779 invoked from network); 29 Jan 2016 18:07:35 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 29 Jan 2016 18:07:35 -0000 Date: 29 Jan 2016 18:07:13 -0000 Message-ID: <20160129180713.51570.qmail@ary.lan> From: "John Levine" To: ietf-smtp@ietf.org, shutup@ietf.org In-Reply-To: <56AB9AE4.7020503@alameth.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: csg@alameth.org Subject: Re: [Shutup] [ietf-smtp] Compressing SMTP streams X-BeenThere: shutup@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMTP Headers Unhealthy To User Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 18:07:38 -0000 >Compression has been removed completely from TLS v1.3, the outcome of >the room consensus at IETF-89. Bummer. Well, in that case, here's a straw man proposal. The extension name is COMPRESS, the EHLO keyword is COMPRESS and is followed by a space-separated list of compression schemes, currently consisting only of DEFLATE (RFC 1951.) There's one new command, COMPRESS which takes as an argument the type of compression to be used. If you want to do both STARTTLS and COMPRESS, the results of doing COMPRESS before STARTTLS are aggessively undefined. The responses to COMPRESS are: 500 compress not supported 501 compression scheme unknown 220 go ahead After a 220 response, subsequent traffic is compressed. It's up to each end to ensure that there's a compression block boundary every time the transmission direction changes, i.e., after each command or response, or if pipelining after each pipelined group. If the compress command fails, the client can at its option continue an uncompressed session or give up. Example S: 220 mx.example smail2 ESMTP C: EHLO client.example S: 250-mx.example S: 250-STARTTLS S: 250-8BITMIME S: 250 COMPRESS DEFLATE C: STARTTLS S: 220 go ahead C: EHLO client.example S: 250-mx.example S: 250-8BITMIME S: 250 COMPRESS DEFLATE C: COMPRESS DEFLATE S: 220 go ahead ... blah blah ... C: QUIT S: 221 sayonara R's, John From nobody Fri Jan 29 11:31:37 2016 Return-Path: X-Original-To: shutup@ietfa.amsl.com Delivered-To: shutup@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663F11B3250 for ; Fri, 29 Jan 2016 11:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 IfH2jISVJVEu for ; Fri, 29 Jan 2016 11:31:29 -0800 (PST) Received: from mail.zash.se (ip66.hethane.riksnet.nu [85.11.25.66]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF8C1B324A for ; Fri, 29 Jan 2016 11:31:28 -0800 (PST) Received: from localhost (localhost [::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.zash.se (Postfix) with ESMTPSA id 23DAD60168; Fri, 29 Jan 2016 20:31:25 +0100 (CET) To: John Levine , shutup@ietf.org References: <20160129180713.51570.qmail@ary.lan> From: Kim Alvefur Openpgp: id=3E52119EF853C59678DBBF6BADED9A77B67AD329; url=http://zash.se/~zash/pubkey.asc X-Enigmail-Draft-Status: N1110 Message-ID: <56ABBE0C.7060701@zash.se> Date: Fri, 29 Jan 2016 20:31:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160129180713.51570.qmail@ary.lan> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="N8HCciFxheaDR1s24njorXD0H5TxwBEF0" Archived-At: Subject: Re: [Shutup] [ietf-smtp] Compressing SMTP streams X-BeenThere: shutup@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMTP Headers Unhealthy To User Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 19:31:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --N8HCciFxheaDR1s24njorXD0H5TxwBEF0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, On 01/29/2016 07:07 PM, John Levine wrote: >> Compression has been removed completely from TLS v1.3, the outcome of = >> the room consensus at IETF-89. >=20 > Bummer. >=20 > Well, in that case, here's a straw man proposal. >=20 > The extension name is COMPRESS, the EHLO keyword is COMPRESS and is > followed by a space-separated list of compression schemes, currently > consisting only of DEFLATE (RFC 1951.) The XMPP community having an application layer compression extension protocol already, , it is pretty much like your proposal. While CRIME may be less applicable to non-HTTP-protocols, such attacks are not impossible, as demonstrated by Thijs Alkemade a few years back: https://blog.thijsalkema.de/blog/2014/08/07/https-attacks-and-xmpp-2-crim= e-and-breach/ http://mail.jabber.org/pipermail/standards/2014-October/029215.html The takeaway here is to 1) not allow compression until after any authentication has been done and 2) flush the compression state between messages (if the sever supports sending multiple messages over the same SMTP session). --=20 Kim "Zash" Alvefur --N8HCciFxheaDR1s24njorXD0H5TxwBEF0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWq74MAAoJEK3tmne2etMpZ4AP/ROaC9RRIbOEZL+/ktqHG6ag CQr3KMBkPXz9X64nXmVE8ocuw9pQT3cW4wZQnUSoPu3lK9KY8BYV6Ry0wS68hJpK Nlg5JugsxhKci4qGWDcx/h8WypIo77TQej/aGig4BjZUYerl9m4jt51NZucYtEXI vALJqEyVCFALXSusMJBlGPa/NgyXKPtOl7O0yy28HYwDD+TMD4l9bkThOXMnAuDX CJDwzse0FZdNKeM0s5sZv8Lwva0PqSX37sXQLiF2a9rjxATbnwFNugTdZiV0cwE6 fUNU2TxL6PsSsBNRRnavL6hYSUjEVIiYhAx2KklcRMM6BwDw1rbllLFWAQo/xoKx 1aI4pO8IoBYAABPpWlrMyRUUGCqgvdSk2yIEEbZHrwAbNTWFqC68XjAcwGT+nrEO Tbf/GLX1ZLZMe2PeXYVwoJzO/SdUb3JMGLl2ia5AqoQMOEVlFPo3z3aiQJFKmZvE LxXEsUGM9ORiz0Rn2+3C2C1uSOL9xpTjKbZX/o/EcWvbvYSN1UDSymerrcDMc5ru /tbtCf4UKunucoFpSO7HBLOWpwM1/93fCdYfMgTLX9r6juOBCOwBNxE7pweKPOhX tZTeVPbr+9wgda3ybXi5/pkRngQf7FaR0/eNdVOFkYM0IcxhN6Jv3J8PxUhTYFIA cWPmz/FjHOeYUrUwgHQq =Rjjk -----END PGP SIGNATURE----- --N8HCciFxheaDR1s24njorXD0H5TxwBEF0-- From nobody Fri Jan 29 12:11:28 2016 Return-Path: X-Original-To: shutup@ietfa.amsl.com Delivered-To: shutup@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFBB1B32E5 for ; Fri, 29 Jan 2016 12:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 pj3_c0Lxa4vq for ; Fri, 29 Jan 2016 12:11:25 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 F0A7D1B32E1 for ; Fri, 29 Jan 2016 12:11:24 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id 9so21667327iom.1 for ; Fri, 29 Jan 2016 12:11:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yTnm5vYoRycvBNNA5DBaO5Ee73W1WvuxqF8aemBDGnY=; b=c1KgfIl9vi3bygk2rRZe1gQFQ/9AyE53bcjY/XzBjZXVccxqTEreiFysmlAB0JoOfS MDnuIC3xUoIrKIcGA2STYgNryQIF00Xd+leQC6qgnltp505v/ealdhDj41Jz3KYHLHwd Y3yAXO0yssAqpgLKHJQQBSf6k/7jadBF48KYLVEi0vb97p/U7l5XXrG8/29909PFkRR+ cARHb0wHHhT1vqi1B6bB+6C4jUDv3cZ2JQQj0q0RvFfUYAciplfOfP/P4uaiMAaLaDe/ 1eJq54ydi/Xbg3ISLwN7/87e0bzZEw/iOoXhPwSF+uAK85XiWBeC3Z7jsqMRcF2q0FHQ BvNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yTnm5vYoRycvBNNA5DBaO5Ee73W1WvuxqF8aemBDGnY=; b=FHK6ecJqkYsShUDFl2qKVnXgNCm1Oyx8r3Pl6DQvZGT0UIeRBHpe9VMoVyNEF3u3Hw TfzDbjHhpy95PqCHvLI17opeavcyq3aBlA2oIEFJ7xomLIkBJ3SH4T9Wr3yILLpWis0p LN7hXqa9aY3i8QO8T6RJqEdXfajSwBCgpaKWos7eYrijsuwtjqrORsr9ix4ZdaVZ0as3 aRPH/GieUER/psALftUH3YfOXmm3lkkT9N51waad6pTZwJgwUr8uO8yMcye2ZkUR1Sxi 1tdsN2PqFO73y8bHhYxrQ4ZpDhYI8+bSK2GZGIT1OXfTCIYjdsL9a47nt2PIds1Njmhr KQ+A== X-Gm-Message-State: AG10YOS1xa1avs5yvivG9hwrqHVzCdvRAIV1dahKSScfS4uw9cnEr2YJp3DzSg+TemRsYNlSgrz+OEbvrF8DRIVL MIME-Version: 1.0 X-Received: by 10.107.153.140 with SMTP id b134mr12271590ioe.113.1454098284232; Fri, 29 Jan 2016 12:11:24 -0800 (PST) Received: by 10.64.62.194 with HTTP; Fri, 29 Jan 2016 12:11:23 -0800 (PST) In-Reply-To: <20160129180713.51570.qmail@ary.lan> References: <56AB9AE4.7020503@alameth.org> <20160129180713.51570.qmail@ary.lan> Date: Fri, 29 Jan 2016 12:11:23 -0800 Message-ID: From: Brandon Long To: John Levine Content-Type: multipart/alternative; boundary=001a1140fbb0b3a955052a7ea3b6 Archived-At: Cc: "Carl S. Gutekunst" , shutup@ietf.org, ietf-smtp Subject: Re: [Shutup] [ietf-smtp] Compressing SMTP streams X-BeenThere: shutup@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMTP Headers Unhealthy To User Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 20:11:26 -0000 --001a1140fbb0b3a955052a7ea3b6 Content-Type: text/plain; charset=UTF-8 That's about exactly what I was thinking. Brandon On Fri, Jan 29, 2016 at 10:07 AM, John Levine wrote: > >Compression has been removed completely from TLS v1.3, the outcome of > >the room consensus at IETF-89. > > Bummer. > > Well, in that case, here's a straw man proposal. > > The extension name is COMPRESS, the EHLO keyword is COMPRESS and is > followed by a space-separated list of compression schemes, currently > consisting only of DEFLATE (RFC 1951.) > > There's one new command, COMPRESS which takes as an argument the type > of compression to be used. If you want to do both STARTTLS and > COMPRESS, the results of doing COMPRESS before STARTTLS are > aggessively undefined. > > The responses to COMPRESS are: > > 500 compress not supported > 501 compression scheme unknown > 220 go ahead > > After a 220 response, subsequent traffic is compressed. It's up to > each end to ensure that there's a compression block boundary every > time the transmission direction changes, i.e., after each command or > response, or if pipelining after each pipelined group. If the > compress command fails, the client can at its option continue an > uncompressed session or give up. > > Example > > S: 220 mx.example smail2 ESMTP > > C: EHLO client.example > > S: 250-mx.example > S: 250-STARTTLS > S: 250-8BITMIME > S: 250 COMPRESS DEFLATE > > C: STARTTLS > > S: 220 go ahead > > > > C: EHLO client.example > > S: 250-mx.example > S: 250-8BITMIME > S: 250 COMPRESS DEFLATE > > C: COMPRESS DEFLATE > S: 220 go ahead > > > ... blah blah ... > > C: QUIT > > S: 221 sayonara > > R's, > John > > _______________________________________________ > Shutup mailing list > Shutup@ietf.org > https://www.ietf.org/mailman/listinfo/shutup > --001a1140fbb0b3a955052a7ea3b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's about exactly what I was thinking.

Brandon

On Fri, Jan 29, 2016 at 10:07 AM, John Levine &l= t;johnl@taugh.com&= gt; wrote:
>Co= mpression has been removed completely from TLS v1.3, the outcome of
>the room consensus at IETF-89.

Bummer.

Well, in that case, here's a straw man proposal.

The extension name is COMPRESS, the EHLO keyword is COMPRESS and is
followed by a space-separated list of compression schemes, currently
consisting only of DEFLATE (RFC 1951.)

There's one new command, COMPRESS which takes as an argument the type of compression to be used.=C2=A0 If you want to do both STARTTLS and
COMPRESS, the results of doing COMPRESS before STARTTLS are
aggessively undefined.

The responses to COMPRESS are:

500 compress not supported
501 compression scheme unknown
220 go ahead

After a 220 response, subsequent traffic is compressed.=C2=A0 It's up t= o
each end to ensure that there's a compression block boundary every
time the transmission direction changes, i.e., after each command or
response, or if pipelining after each pipelined group.=C2=A0 If the
compress command fails, the client can at its option continue an
uncompressed session or give up.

Example

S: 220 mx.example smail2 ESMTP

C: EHLO client.example

S: 250-mx.example
S: 250-STARTTLS
S: 250-8BITMIME
S: 250 COMPRESS DEFLATE

C: STARTTLS

S: 220 go ahead

<TLS negotiation>

C: EHLO client.example

S: 250-mx.example
S: 250-8BITMIME
S: 250 COMPRESS DEFLATE

C: COMPRESS DEFLATE
S: 220 go ahead

<subsequent traffic is compressed>
=C2=A0... blah blah ...

C: QUIT

S: 221 sayonara

R's,
John

_______________________________________________
Shutup mailing list
Shutup@ietf.org
https://www.ietf.org/mailman/listinfo/shutup

--001a1140fbb0b3a955052a7ea3b6-- From nobody Fri Jan 29 13:14:11 2016 Return-Path: X-Original-To: shutup@ietfa.amsl.com Delivered-To: shutup@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212501B344A for ; Fri, 29 Jan 2016 13:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 pxFYsQZkbgTD for ; Fri, 29 Jan 2016 13:14:08 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F056F1B3438 for ; Fri, 29 Jan 2016 13:14:07 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id d63so85238702ioj.2 for ; Fri, 29 Jan 2016 13:14:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C7Dsrb8DnlWk/qMqM3lSztMVppFjxPl/uSJryC0MZ1E=; b=pqLWUNmGmsPFTnABE6dGTJ0p7tL7U5ULPg6+mGR7dQOYYHqhW6FCU1QKj4O6HFCqHK wAumGZwuk07el1k2vqh8Xr84lAtSjAjbxPtmI9rYlmklb1ucA5+aTw5qwhsZDPBVUx1h N/oFuWu1F9OyANvpYJUul5DH7qM7gbAtG9wbY1NRrJvXNLTIv+7BKOXFbP8NQ7BtmOkT hoj1y8AuBsIRL9ZlanBRx4+S1bE2FvigLe+jYRER6AlVv5ObRRMsEzvuJ7WJc0RdCtPA TrP+q/Jb9J6YYtTDc66dLl/DWZM5Clg/+8Y1yWwnocaQme59VACViQoSFhRW7DloI5A5 Basg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=C7Dsrb8DnlWk/qMqM3lSztMVppFjxPl/uSJryC0MZ1E=; b=A4X6zPxCG1M6R3sZq4sby+K+w6gyJgE3/Rbz/Ov2x5gclrUXeOWd8Eng97/3oKQbdr +Lt0hFvYExa22k9mU8i1d42mGrcwIVlXBr36qeGXHLYS5SRudiyRdN0kp9UbnoafqvdC AWsJr06gSKyjtMM2xq0oFk2cnbr0tMjL+dTP6nD+HvjxGNpZsDGFlvHwO8qJ9Bfa/K0l MjhC6tro+V0GAcKvHI5Jx9P/U4QV2ux0vikzBBrKKY8hh3ABtE6IdEiioi01l3JMx2rv 7QXtr6fCmAzeSLV++rnjQ9heslfxy3pz7VhA52YGRQjceWO9LF55Mx2YAGhPfM8IfWvE 4ECQ== X-Gm-Message-State: AG10YOQasKqv+F2qZQ+Bic2o0WlvMb0tUNda93fYzXNa1uZD2dljaD4gBKkwC0gyoc59CNzrlUTTPv4rQUficceZ MIME-Version: 1.0 X-Received: by 10.107.159.7 with SMTP id i7mr11408867ioe.29.1454102047175; Fri, 29 Jan 2016 13:14:07 -0800 (PST) Received: by 10.64.62.194 with HTTP; Fri, 29 Jan 2016 13:14:06 -0800 (PST) In-Reply-To: <56ABD3DA.70203@alameth.org> References: <20160129180713.51570.qmail@ary.lan> <56ABD3DA.70203@alameth.org> Date: Fri, 29 Jan 2016 13:14:06 -0800 Message-ID: From: Brandon Long To: "Carl S. Gutekunst" Content-Type: multipart/alternative; boundary=001a1141bf06fdc0dd052a7f8371 Archived-At: Cc: shutup@ietf.org, John Levine , ietf-smtp Subject: Re: [Shutup] [ietf-smtp] Compressing SMTP streams X-BeenThere: shutup@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMTP Headers Unhealthy To User Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 21:14:09 -0000 --001a1141bf06fdc0dd052a7f8371 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 29, 2016 at 1:04 PM, Carl S. Gutekunst wrote: > Well, in that case, here's a straw man proposal. >> >> The extension name is COMPRESS, the EHLO keyword is COMPRESS and is >> followed by a space-separated list of compression schemes, currently >> consisting only of DEFLATE (RFC 1951.) >> >> There's one new command, COMPRESS which takes as an argument the type >> of compression to be used. If you want to do both STARTTLS and >> COMPRESS, the results of doing COMPRESS before STARTTLS are >> aggessively undefined. >> >> The responses to COMPRESS are: >> >> 500 compress not supported >> 501 compression scheme unknown >> 220 go ahead >> >> After a 220 response, subsequent traffic is compressed. >> > > Yes, order must be STARTTLS, then AUTH, then COMPRESS. > > We assume that binary MIME (ala RFC 3030) is dead. > > Alternative: Is there any benefit to compressing the envelope? With > pipelining, probably; otherwise no. If we don't compress the envelope, then > we could make compression an option on the DATA command. Now we have > something that starts to look like RFC 3030, but without the assumption > that the sender should not use Base64 (with its attendant and DKIM-breaking > content transfer encoding conversion at each hop). 1000 recipients at ~30 bytes each with each domain likely the same... maybe sometimes. If you're only compressing the data, what's the interaction with RFC 1870? Do you use the compressed size or the original, and if you use the compressed size, does that mean the server will accept larger uncompressed messages? And I'd think it's an alternative to BDAT, same thing, but compressed? Unless we extend the BDAT syntax for compression... Brandon --001a1141bf06fdc0dd052a7f8371 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 29, 2016 at 1:04 PM, Carl S. Gutekunst &l= t;csg@alameth.org&= gt; wrote:
Well, in that case, here's a straw man proposal.

The extension name is COMPRESS, the EHLO keyword is COMPRESS and is
followed by a space-separated list of compression schemes, currently
consisting only of DEFLATE (RFC 1951.)

There's one new command, COMPRESS which takes as an argument the type of compression to be used.=C2=A0 If you want to do both STARTTLS and
COMPRESS, the results of doing COMPRESS before STARTTLS are
aggessively undefined.

The responses to COMPRESS are:

500 compress not supported
501 compression scheme unknown
220 go ahead

After a 220 response, subsequent traffic is compressed.

Yes, order must be STARTTLS, then AUTH, then COMPRESS.

We assume that binary MIME (ala RFC 3030) is dead.

Alternative: Is there any benefit to compressing the envelope? With pipelin= ing, probably; otherwise no. If we don't compress the envelope, then we= could make compression an option on the DATA command. Now we have somethin= g that starts to look like RFC 3030, but without the assumption that the se= nder should not use Base64 (with its attendant and DKIM-breaking content tr= ansfer encoding conversion at each hop).

10= 00 recipients at ~30 bytes each with each domain likely the same... maybe s= ometimes.

If you're only compressing the data,= what's the interaction with RFC 1870?=C2=A0 Do you use the compressed = size or the original, and if you use the compressed size, does that mean th= e server will accept larger uncompressed messages?

And I'd think it's an alternative to BDAT, same thing, but compres= sed?=C2=A0 Unless we extend the BDAT syntax for compression...
Brandon
--001a1141bf06fdc0dd052a7f8371-- From nobody Sat Jan 30 02:15:16 2016 Return-Path: X-Original-To: shutup@ietfa.amsl.com Delivered-To: shutup@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778821B342B; Fri, 29 Jan 2016 13:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 FuAmlUUrleoY; Fri, 29 Jan 2016 13:04:28 -0800 (PST) Received: from articuno.alameth.org (articuno.alameth.org [45.79.107.253]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031CF1B342A; Fri, 29 Jan 2016 13:04:28 -0800 (PST) Received: from rapidash.eng.sonicwall.com (rapidash.eng.sonicwall.com [IPv6:2620:9f:12:cc51::2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by articuno.alameth.org (Postfix) with ESMTPS id 5AE5014FFD; Fri, 29 Jan 2016 21:04:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alameth.org; s=n01; t=1454101467; bh=AJXk21667OUHEbvKBTW+yh6/7jazLDYK1e0M0lnfiSk=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Fyy3iLVX2itmG6tl8RmfWYpUcExL6jV9H1RokmggQmNsla493t2utADNmM7k0Y2+7 kz9QwMmAjguC1+1fyyGn9zAmwIljVWEIGWohDP8YA4vS48iYdzGNDHGxTnhnwMsE7K xZ64zxlXnFj2Nk1GPy+1UkCYW161o0bztomAS/4c= Message-ID: <56ABD3DA.70203@alameth.org> Date: Fri, 29 Jan 2016 13:04:26 -0800 From: "Carl S. Gutekunst" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John Levine , ietf-smtp@ietf.org, shutup@ietf.org References: <20160129180713.51570.qmail@ary.lan> In-Reply-To: <20160129180713.51570.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sat, 30 Jan 2016 02:15:14 -0800 Subject: Re: [Shutup] [ietf-smtp] Compressing SMTP streams X-BeenThere: shutup@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMTP Headers Unhealthy To User Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 21:04:29 -0000 > Well, in that case, here's a straw man proposal. > > The extension name is COMPRESS, the EHLO keyword is COMPRESS and is > followed by a space-separated list of compression schemes, currently > consisting only of DEFLATE (RFC 1951.) > > There's one new command, COMPRESS which takes as an argument the type > of compression to be used. If you want to do both STARTTLS and > COMPRESS, the results of doing COMPRESS before STARTTLS are > aggessively undefined. > > The responses to COMPRESS are: > > 500 compress not supported > 501 compression scheme unknown > 220 go ahead > > After a 220 response, subsequent traffic is compressed. Yes, order must be STARTTLS, then AUTH, then COMPRESS. We assume that binary MIME (ala RFC 3030) is dead. Alternative: Is there any benefit to compressing the envelope? With pipelining, probably; otherwise no. If we don't compress the envelope, then we could make compression an option on the DATA command. Now we have something that starts to look like RFC 3030, but without the assumption that the sender should not use Base64 (with its attendant and DKIM-breaking content transfer encoding conversion at each hop). From nobody Sat Jan 30 02:15:18 2016 Return-Path: X-Original-To: shutup@ietfa.amsl.com Delivered-To: shutup@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261FB1B3453; Fri, 29 Jan 2016 13:20:51 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 u8V-d868X45n; Fri, 29 Jan 2016 13:20:49 -0800 (PST) Received: from haven.eyrie.org (haven.eyrie.org [IPv6:2001:470:30:84:e276:63ff:fe62:3539]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8F31B3452; Fri, 29 Jan 2016 13:20:49 -0800 (PST) Received: from lothlorien.eyrie.org (unknown [96.90.234.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by haven.eyrie.org (Postfix) with ESMTPS id 85AE3118460; Fri, 29 Jan 2016 13:20:48 -0800 (PST) Received: by lothlorien.eyrie.org (Postfix, from userid 1000) id 709E7B414D1; Fri, 29 Jan 2016 13:19:38 -0800 (PST) From: Russ Allbery To: "John Levine" In-Reply-To: <20160129180713.51570.qmail@ary.lan> (John Levine's message of "29 Jan 2016 18:07:13 -0000") Organization: The Eyrie References: <20160129180713.51570.qmail@ary.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Date: Fri, 29 Jan 2016 13:19:38 -0800 Message-ID: <87si1gdqxh.fsf@hope.eyrie.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: X-Mailman-Approved-At: Sat, 30 Jan 2016 02:15:14 -0800 Cc: csg@alameth.org, shutup@ietf.org, ietf-smtp@ietf.org, ietf-nntp@lists.eyrie.org Subject: Re: [Shutup] [ietf-smtp] Compressing SMTP streams X-BeenThere: shutup@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMTP Headers Unhealthy To User Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 21:20:51 -0000 +ietf-nntp, who may be interested "John Levine" writes: > Well, in that case, here's a straw man proposal. [snip proposal for COMPRESS extension to smtp] BTW, in the NNTP world, we're currently testing: http://tools.ietf.org/id/draft-murchison-nntp-compress-01.html and will probably have a new version of that draft based on early interop results. -- Russ Allbery (eagle@eyrie.org) From nobody Sat Jan 30 02:15:19 2016 Return-Path: X-Original-To: shutup@ietfa.amsl.com Delivered-To: shutup@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D8C1A8A06; Fri, 29 Jan 2016 14:05:51 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 J5NBi_7Qilzj; Fri, 29 Jan 2016 14:05:50 -0800 (PST) Received: from haven.eyrie.org (haven.eyrie.org [IPv6:2001:470:30:84:e276:63ff:fe62:3539]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9DB1A8A04; Fri, 29 Jan 2016 14:05:50 -0800 (PST) Received: from lothlorien.eyrie.org (unknown [96.90.234.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by haven.eyrie.org (Postfix) with ESMTPS id 6525F1184BA; Fri, 29 Jan 2016 14:05:49 -0800 (PST) Received: by lothlorien.eyrie.org (Postfix, from userid 1000) id 65978B414D1; Fri, 29 Jan 2016 14:04:39 -0800 (PST) From: Russ Allbery To: "John Levine" In-Reply-To: <87si1gdqxh.fsf@hope.eyrie.org> (Russ Allbery's message of "Fri, 29 Jan 2016 13:19:38 -0800") Organization: The Eyrie References: <20160129180713.51570.qmail@ary.lan> <87si1gdqxh.fsf@hope.eyrie.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Date: Fri, 29 Jan 2016 14:04:39 -0800 Message-ID: <87egd0doug.fsf@hope.eyrie.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: X-Mailman-Approved-At: Sat, 30 Jan 2016 02:15:14 -0800 Cc: csg@alameth.org, shutup@ietf.org, ietf-smtp@ietf.org, ietf-nntp@lists.eyrie.org Subject: Re: [Shutup] [ietf-smtp] Compressing SMTP streams X-BeenThere: shutup@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMTP Headers Unhealthy To User Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 22:05:52 -0000 Russ Allbery writes: > BTW, in the NNTP world, we're currently testing: > http://tools.ietf.org/id/draft-murchison-nntp-compress-01.html > and will probably have a new version of that draft based on early interop > results. Apologies, there's a current version out already: http://tools.ietf.org/id/draft-murchison-nntp-compress-02.html -- Russ Allbery (eagle@eyrie.org)