Re: [Uta] reporting, was CBOR, XML, JSON (was Re: Updated SMTP STS Draft)

[Neil Cook <[e-mail]>]

+1 for a separate draft on in-band reporting.

Neil

> On 10 May 2016, at 16:14, Daniel Margolis <[e-mail]> wrote:
> 
> Yeah, I think we've spent more time on this discussion than we would on some simple implementations. ;)
> 
> I think Viktor is right that sending something other than "QUIT" is quite reasonable. Obviously some MTA operators may have trouble implementing it (like if their MTA doesn't support it and they don't want to write custom code), so for that reason and for the purposes of MITM transparency (as I noted up-thread) we should also support out-of-band reporting. (MTAs need not support STS in order to generate meaningful reports about, e.g., expired certs, so supporting reporting with no required MTA changes is a useful property.)
> 
> I think we all agree that we should do both, in an ideal world. And the discussion of priorities here strikes me as mostly misplaced, since it mostly depends on what's easy for a given developer or host to implement; some will implement only one or the other, I imagine.
> 
> So the only real question I have here is, should we include something about in-band reporting (the "QUIT" alternative) in the TLSRPT draft? I think not, as it seems a bit misplaced for the draft. But it seems like we could fairly easy write basically a one-pager describing this other verb.
> 
> Does that make sense? Basically something like STARTTLS, where you say "TLSQUIT [some parameters about failure]" and if you don't get back a 221 you then do a "QUIT."
> 
> (Viktor, if you want to draft something like this, I'm happy to proof read it...)
> 
> Dan
> 
> On Mon, May 9, 2016 at 10:36 PM, Viktor Dukhovni <[e-mail] <mailto:[e-mail]>> wrote:
> On Tue, May 10, 2016 at 01:15:34AM -0000, John Levine wrote:
> 
> > >Legacy MTAs also won't have STS support.  We won't get new security
> > >capabilitie ex nihilo.
> >
> > If you want to do the client stuff, you need new code in the MTA, but
> > for the server side part, publishing a statement saying here's the
> > names of my MXes and what their certificates should look like, you
> > don't.  Just stick the info on a web server, publish a DNS record or
> > two to point at it, and you're all set.
> 
> The proposal is exceedingly simple.  Instead of just sending "QUIT"
> when TLS peer authentication fails, (or STARTTLS is not offered),
> the SMTP client may be able to send a one line TLS status command.
> 
> Some MTAs would support this and some wouldn't.  Over time likely
> more would than won't.  Lack of day-one support is not a valid
> objection.
> 
> I'm proposing an *additional* notification channel for can be more
> timely, and does not require the use of any third parties to which
> one discloses one's traffic details, or publication of any email
> addresses for receiving reports that may get spammed, or require
> custom plumbing for report processing.
> 
> In Postfix, I can provide built-in support for the new verb in a
> a way that consolidates notices for reporting to the system
> administrator.
> 
> Nothing you've said in this thread makes the proposal impractical
> as an *additional* mechanism for notification.  I am done with this
> thread.  Over and out.
> 
> --
>         Viktor.
> 
> _______________________________________________
> Uta mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/uta <https://www.ietf.org/mailman/listinfo/uta>
> 
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta