Thank you, guys, for the great discussion and great points on both 'sides' :-) It would be great if the authors could capture the requirements (and maybe even scenarios, as John suggested) in the draft. It seems that you are setting a high bar by discussing at depth the scenarios, the requirements, and the implementation in a single document cycle! We should probably arrange for a longer session in Berlin to go over the material and the discussion points to let the whole audience to judge :-). Orit.
> -----Original Message----- > From: Uta [mailto:[email protected]] On Behalf Of Viktor Dukhovni > Sent: Friday, May 06, 2016 1:52 AM > To: [email protected] > Subject: Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP STS Draft) > > On Fri, May 06, 2016 at 02:14:37PM +0700, Aaron Zauner wrote: > > > > 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. > > > > I'm aware of that, but if the draft turns out to be a delivery reporting > system, I'm not going to support it. > > The draft will likely move forward with at least one of us not > entirely in agreement with its content. I think the most productive > approach is to raise your issues as best you can. You can of course > walk away as or when you see fit. > > I think we should stop the deep dive and come back to prioritizing > goals. Rank and/or replace the below, and then we can figure out > how to address the right problem: > > * Near real-time forward-path alerting of (likely) receiver > misconfiguration? > > * Aggregate reporting of authentication success/failure > stats? > > * CT-like reporting to public "observatories"? > > * Other goals? > > We may also have to pin down some technical details: > > * Reliability of report delivery? (DMARC is not trying > to defend against MiTM attacks so is not concerned with > MiTM attacks on the reporting channel, here things are > different). > > Relevant issues for aggregate reporting might include: > > * How long should a sender keep on trying to deliver a report? > * How often to retry? > * How does one avoid DoSing a target site with reports? > > The above will require some care. > > The simplest thing to in the near term do is to just communicate > authentication failure inline, and either continue delivery (if > authentication is not yet in hard-fail mode) or move on to the next > MX host. This gets to the right party in near real-time. > > Sites that want real time reports of this sort would enable > a new ESMTP feature advertisement that makes it possible for > the client to send: > > TLSSTATUS DANE|STS NOSTARTTLS > TLSSTATUS DANE|STS UNTRUSTED > TLSSTATUS DANE|STS NOTMATCHED > TLSSTATUS DANE|STS SUCCESS > TLSSTATUS FALLBACK > > (handshake failures are communicated via TLS alerts) > (the FALLBACK status is for cleartext retries after > STARTTLS failure in opportunistic mode). > > The MTA on the receiving end can log these, and raise alarms under > appropriate conditions. This would need support in sending and > receiving MTAs and does not require either a "mailto:"; or "http" > reporting address. Just new inline signalling. > > If the status is signalled as part of an actual delivery it might > also be recorded in new message trace headers. Tony Finch some > time ago suggested "Transmitted:" as a sender-added trace header > to complement "Received:". It did not get traction at the time, > but still looks like a reasonable idea. > > > I understand this is what you consider relevant. I'd like to know why and > > how attacks happen as well, if possible. > > Reporting that conveys longer-term metrics is admittedly also of > some interest, but we rather strongly disagree on its relative > importance at this early stage of the evolution of authenticated > MTA-to-MTA transport. > > > > There will first be non-IETF documents in this space, and perhaps > > > ultimately some IETF BCPs once we have even more operational > > > experience. > > > > Which non-IETF documents? Where? > > Some folks are writing a DANE BCP for SMTP with Postfix, and we'll > try to include as material as possible that is MTA-neutral. I'll > let you known once we have something ready. > > > No it isn't shaky, it's non-existent. People that currently deploy LE > > certs on their mailservers do so on their own, without guidance and > without > > any support nor automation. > > Well some guidance is available in the LE community forum posts, > one of mine is even administratively pinned. But more is possible. > > > And I'm sorry to say: I don't care about DNSSEC > > [ This sounds needlessly dogmatic. ] > > > Again: there's currently neither incentive nor effort within LE to look > > at DANE. Nor enough man-power available. Nor is it really relevant in my > > opinion. > > At least one of the folks behind LE has been reasonably supportive, > though admittedly not yet to the extent of explicit support for > DANE in the tooling. > > > I'd rather consider every detail than rush a standard through the IETF > > process. > > I am also not in a hurry to skip important details. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
