+1 for a separate draft on in-band reporting. Neil
> On 10 May 2016, at 16:14, Daniel Margolis <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/uta > <https://www.ietf.org/mailman/listinfo/uta> > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
