Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP STS Draft)
Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 06 May 2016 07:00 UTC
Return-Path: <ietf-dane@dukhovni.org>
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 566E412D158 for <uta@ietfa.amsl.com>; Fri, 6 May 2016 00:00:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 yYv2dZC2tXOV for <uta@ietfa.amsl.com>; Fri, 6 May 2016 00:00:44 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56CA412D0F2 for <uta@ietf.org>; Fri, 6 May 2016 00:00:44 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 22B3E284F26; Fri, 6 May 2016 07:00:43 +0000 (UTC)
Date: Fri, 06 May 2016 07:00:43 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: uta@ietf.org
Message-ID: <20160506070042.GX3300@mournblade.imrryr.org>
References: <alpine.OSX.2.11.1605051057310.39064@ary.lan> <5CAA2C26-D339-4BFE-8328-0B33E3652025@azet.org> <CANtKdUeU9FvR9TGWFRTaTWfr-6hBCYtYci=y857YbU-EUB0s7Q@mail.gmail.com> <D0F684BC-4824-4D0D-B286-7BCFADF6C639@azet.org> <20160505181009.GN3300@mournblade.imrryr.org> <177C95ED-B4CE-4306-B6ED-0CAD8C8D49A1@azet.org> <20160505192804.GO3300@mournblade.imrryr.org> <8B087C9C-EF27-43A9-81C1-5AD54B3FE14A@azet.org> <20160506044742.GV3300@mournblade.imrryr.org> <2E8F633E-BCC1-4FA8-8F90-F02C5D020B0C@azet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2E8F633E-BCC1-4FA8-8F90-F02C5D020B0C@azet.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/whWTxShdO1LJavq-tp_YnsfOuJI>
Subject: Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP STS Draft)
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: uta@ietf.org
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 May 2016 07:00:51 -0000
On Fri, May 06, 2016 at 12:57:15PM +0700, Aaron Zauner wrote: > > You need to keep in mind that in the vast majority of cases > > authentication errors will be operational errors (self-DoS) on > > receiving systems, and the task at hand is to minimize the frequency > > and duration of outages, so that security is used and not just > > disabled as unusable. Maximalist approaches are highly counter-productive > > here. > > This is not what I understood from the draft in it's current form: The current form is not the final form. To the expect that the draft emphasizes statistical reporting over problem alerting it needs to be corrected. > The last sentence explicitly mentions "detect potential attackers". That nice, but it's way down the priority list of what's actually relevant. First we need the protocols to be usable, which means sufficiently resilient to be deployed, which means timely error reporting. > So if there's a MITM you'd rather have him intercept (and possibly modify!) > the feedback reports as well? Yes! The vast majority of the failures will not be MiTM-related, and if there is an MiTM, well then you can't send the report to the right party anyway. > Confidentiality may be needed as detailed > information on MITM attacks can give indication as to which paths and > systems are affected (e.g. to 3rd party attackers, not the original MITM). There's little need for very detailed information. We just want to distinguish between a few classes of failures. * Lack of STARTTLS (this too is often self-inflicted!) * Lack of shared protocol protocol parameters (protocol version/ciphers) * Lack of shared trust anchors * Reference identifier mismatch * (Perhaps one or two others I'm forgetting right now) > There're many other attack vectors. Also see the IAB statement I referred > to before, I took it seriously. None of this matters if the protocol cannot be widely adopted, and wide adoption requires infrequent and short additional outages. The reporting feature needs to focus on this, and everything else is secondary. > > ... > > > > 20. Keep the receiving party appraised of possible MiTM attacks, > > via post-event statistical reporting. > > > > Yes, the above is deliberately provocative, to jolt folks out of > > their comfort zones and to think about the real goals and out of > > those relevant requirements. > > It's called "Strict Transport Security" not "How to deliver mail properly". This is an *email* security protocol. It certainly needs to deliver the mail properly, the result should an a working email protocol that is used and is more secure. An unusable email security protocol is pointless. > While I do agree on most points, we need to keep in mind that this is > supposed to be a security standard not merely an email delivery feedback > system. The primarily role of the reporting spec needs to be to maintain the operational stability of inter-organizational email transport. It needs to have as much or as little security as best fits that role. Reporting is NOT a security protocol, its job is to help keep the actual security protocol usable. > > The key requirement as I see is *timely* delivery of focused *alerts* > > to operators who can fix the problem, ideally before it affects > > the delivery of email, while the issue is still localized to just > > a proper subset of the MX hosts. > > I think that may be a reason for another draft in another working group. > This one is called "Utilizing TLS in Applications",.. There will first be non-IETF documents in this space, and perhaps ultimately some IETF BCPs once we have even more operational experience. > > Sites that don't have the operational discipline to do this right > > are best off staying with opportunistic TLS and publishing neither > > DANE nor STS policies. DoSing themselves periodically, and causing > > pain for senders trying to do the right thing helps no one. > > Yea, we'll try to help them out separately with Let's Encrypt automation anyway. That's still a bit shaky, the early adopters of LE for SMTP are where some of the most frequent DANE problems show up. This is because automated LE cert rotation ignores the necessity to update TLSA records from time to time. Survey says 424 MX hosts with stable "IN TLSA [23] 1 ?" records and 109 MX hosts with fragile, soon to break "IN TLSA [23] 0 ?" TLSA records. The ratio is improving, over time, but needs to be much better. There are things LE can do to make this better: * More prominent documentation of best-practice for combining DANE and LE certs, and monitoring their correctness: ; Keep server key fixed when doing automated rotation via "--csr" ; option option. Rotate server key manually, from time to time, ; and update "3 1 1" record accordingly. Do so only while the ; "2 1 1" LE key is not also changing. ; ; Ensure MX hostname matches the certificate SAN ; _25._tcp.smtp.example.org. IN TLSA 3 1 1 <sha256(server public key)> ; Track LE issuer public key, update TLSA RR promptly when it changes. ; Stable server key above makes it possible to tolerate brief mismatches ; if the LE issuer key changes unexpectedly. ; ; Ensure the issuer CA cert is part of server's chain file ; (i.e. is sent to peer in server TLS Certificate message). ; [ This is of course also necessary for STS, as the LE issuer ; CA is an intermediate CA, not a trust anchor. ] ; _25._tcp.smtp.example.org. IN TLSA 2 1 1 <sha256(LE issuer public key)> * Better advance notification of planned changes in the LE issuer public key, not just via the blogs, but also via email sent locally to the administrator by the key rotation scripts. * Provide tools to compute the new "3 1 1" and "2 1 1" records and compare them to what's in DNS. Avoid deploying new cert chain if neither match. If just one changes, deploy, but send alert to admin to update the TLSA RRs. * As explained a recent post to this list (NEWSFLASH thread), the "3 1 1" + "2 1 1" combination is quite resilient if sensibly monitored. * The "mail in a box" project has done a good job of integrating LE and DANE and DNSSEC for a complete turn-key system, and I see very few errors from those machines. They just routinely have correct working TLSA RRs across cert rollovers. Kudos to that project. <https://mailinabox.email/> I've for a long time been deeply involved in the day-to-day practice of MTA SMTP transport security. Designing and implementing the Postfix TLS interface, supporting Postfix TLS users on the mailing list, authoring DANE support in OpenSSL, monitoring DANE adoption. Monitoring and resolving DNSSEC interop issues at hosting providers, ... So yes, I don't just view this as a pure security protocol issue. All the pieces have to fit together to actually create something that gets used. Think systemically, optimization of the security of a small component of a large system can easily turn out to be at the expense of the security system as a whole. -- Viktor.
- Re: [Uta] draft-brotman-mta-sts/ Stephen Farrell
- Re: [Uta] draft-brotman-smtp-tlsrpt Viktor Dukhovni
- [Uta] Updated SMTP STS Draft Brotman, Alexander
- Re: [Uta] Updated SMTP STS Draft Leif Johansson
- Re: [Uta] Updated SMTP STS Draft Leif Johansson
- Re: [Uta] Updated SMTP STS Draft Mark Risher
- Re: [Uta] Updated SMTP STS Draft Aaron Zauner
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… John Levine
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… John Levine
- Re: [Uta] draft-brotman-smtp-tlsrpt Brotman, Alexander
- Re: [Uta] Updated SMTP STS Draft Aaron Zauner
- Re: [Uta] Updated SMTP STS Draft John Levine
- Re: [Uta] draft-brotman-mta-sts/ John Levine
- Re: [Uta] draft-brotman-mta-sts/ Viktor Dukhovni
- Re: [Uta] draft-brotman-mta-sts/ John Levine
- Re: [Uta] draft-brotman-mta-sts/ Viktor Dukhovni
- Re: [Uta] draft-brotman-mta-sts/ John Levine
- Re: [Uta] draft-brotman-mta-sts/ Daniel Margolis
- Re: [Uta] draft-brotman-mta-sts/ John Levine
- Re: [Uta] Updated SMTP STS Draft Jim Fenton
- Re: [Uta] Updated SMTP STS Draft John Levine
- Re: [Uta] draft-brotman-mta-sts/ Daniel Margolis
- Re: [Uta] draft-brotman-mta-sts/ Viktor Dukhovni
- Re: [Uta] Updated SMTP STS Draft Daniel Margolis
- Re: [Uta] draft-brotman-smtp-tlsrpt John Levine
- Re: [Uta] draft-brotman-mta-sts/ John R Levine
- Re: [Uta] draft-brotman-mta-sts/ John Levine
- Re: [Uta] draft-brotman-mta-sts/ Viktor Dukhovni
- Re: [Uta] draft-brotman-smtp-tlsrpt Viktor Dukhovni
- Re: [Uta] draft-brotman-smtp-tlsrpt John Levine
- Re: [Uta] draft-brotman-mta-sts/ Brotman, Alexander
- Re: [Uta] draft-brotman-mta-sts/ Daniel Margolis
- Re: [Uta] draft-brotman-mta-sts/ Neil Cook
- Re: [Uta] draft-brotman-mta-sts/ Viktor Dukhovni
- Re: [Uta] draft-brotman-mta-sts/ ned+uta
- Re: [Uta] Updated SMTP STS Draft Leif Johansson
- Re: [Uta] Updated SMTP STS Draft John Levine
- Re: [Uta] draft-brotman-mta-sts/ John Levine
- Re: [Uta] draft-brotman-mta-sts/ Mark Risher
- Re: [Uta] draft-brotman-mta-sts/ Viktor Dukhovni
- Re: [Uta] draft-brotman-mta-sts/ John R Levine
- Re: [Uta] draft-brotman-mta-sts/ John Levine
- Re: [Uta] draft-brotman-mta-sts/ Binu Ramakrishnan
- Re: [Uta] draft-brotman-mta-sts/ Viktor Dukhovni
- Re: [Uta] draft-brotman-mta-sts/ John Levine
- Re: [Uta] Updated SMTP STS Draft Mark Risher
- Re: [Uta] draft-brotman-mta-sts/ Daniel Margolis
- Re: [Uta] draft-brotman-mta-sts/ Viktor Dukhovni
- Re: [Uta] draft-brotman-mta-sts/ Daniel Margolis
- Re: [Uta] draft-brotman-mta-sts/ Viktor Dukhovni
- Re: [Uta] draft-brotman-mta-sts/ Daniel Margolis
- Re: [Uta] draft-brotman-mta-sts/ Viktor Dukhovni
- Re: [Uta] draft-brotman-mta-sts/ Mark Risher
- [Uta] CBOR, XML, JSON (was Re: Updated SMTP STS D… Chris Newman
- Re: [Uta] draft-brotman-mta-sts/ John Levine
- Re: [Uta] special hostnames, was draft-brotman-mt… John Levine
- Re: [Uta] special hostnames, was draft-brotman-mt… Viktor Dukhovni
- Re: [Uta] special hostnames, was draft-brotman-mt… John Levine
- Re: [Uta] special hostnames, was draft-brotman-mt… Viktor Dukhovni
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Aaron Zauner
- Re: [Uta] Updated SMTP STS Draft Alexey Melnikov
- Re: [Uta] draft-brotman-smtp-tlsrpt Leif Johansson
- Re: [Uta] draft-brotman-smtp-tlsrpt Daniel Margolis
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… John Levine
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Aaron Zauner
- Re: [Uta] draft-brotman-smtp-tlsrpt Kurt Andersen (b)
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… John R Levine
- Re: [Uta] draft-brotman-smtp-tlsrpt Orit Levin
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Aaron Zauner
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Daniel Margolis
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Binu Ramakrishnan
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Aaron Zauner
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Aaron Zauner
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Aaron Zauner
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Viktor Dukhovni
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Viktor Dukhovni
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Daniel Margolis
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… John Levine
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Aaron Zauner
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… John Levine
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Viktor Dukhovni
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Viktor Dukhovni
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Daniel Margolis
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… John R Levine
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Daniel Margolis
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… John R Levine
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Daniel Margolis
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Aaron Zauner
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Aaron Zauner
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Aaron Zauner
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Viktor Dukhovni
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Viktor Dukhovni
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Aaron Zauner
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Aaron Zauner
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Viktor Dukhovni
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Aaron Zauner
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Viktor Dukhovni
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… John R Levine
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… John Levine
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Viktor Dukhovni
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Orit Levin
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Viktor Dukhovni
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Orit Levin
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… John Levine
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… John Levine
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Viktor Dukhovni
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Viktor Dukhovni
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Daniel Margolis
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Viktor Dukhovni
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… John Levine
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Viktor Dukhovni
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… John Levine
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Viktor Dukhovni
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… John Levine
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Viktor Dukhovni
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Daniel Margolis
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Neil Cook
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Chris Newman
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Viktor Dukhovni
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Viktor Dukhovni
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Daniel Margolis
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Viktor Dukhovni
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Aaron Zauner
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Aaron Zauner
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… John R Levine
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Chris Newman
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Aaron Zauner
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Viktor Dukhovni
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Aaron Zauner
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Aaron Zauner
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Viktor Dukhovni
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Viktor Dukhovni
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Aaron Zauner
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Viktor Dukhovni
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… John R Levine
- Re: [Uta] DNSSEC or the lack thereof, was reporti… John Levine
- Re: [Uta] DNSSEC or the lack thereof, was reporti… Viktor Dukhovni
- Re: [Uta] DNSSEC or the lack thereof, was reporti… John Levine
- Re: [Uta] DNSSEC or the lack thereof, was reporti… Viktor Dukhovni
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Aaron Zauner
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… John R Levine
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Jim Fenton
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… John Levine
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Viktor Dukhovni
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Viktor Dukhovni
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Viktor Dukhovni
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Aaron Zauner
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… John R Levine
- Re: [Uta] reporting, was CBOR, XML, JSON (was Re:… Aaron Zauner
- Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP S… Sean Leonard