Re: [Uta] MTA-STS-03 review

[Daniel Margolis <[e-mail]>]

re MXs:

Right, I think a nonstandard MX list is actually worse than the disease it
cures. ;) But you are right to point out that there are multiple approaches
that confer similar security advantages.

To the matching point, I share the concern about people having to write
their own cert matching code, but I think there are a few arguments for it:

1. I believe if we restrict wildcards to the "full" leftmost label (i.e. *.
example.com is valid, but mail*.example.com or mail.*.example.com are not)
and we do the same in the certs (which RFC6125 seems to allow us to
define), wildcard matching is a simple "x ends with y or y ends with x"
comparison, so is in fact trivial to implement.

2. It seems (and I suspect this was part of Viktor's motivation) to match
nicely with https://tools.ietf.org/html/rfc7672#section-3.2.2, which if I
read it correctly leaves the door open to a certificate matching the
nexthop domain rather than the MX hostname; by requiring MX hostname
matches in STS we would break that behavior.

I think #2 is a pretty compelling point.

(FWIW, the more I think of it, Viktor, the less compelling I find the other
point about MX candidate traversal being unchanged, since I'm not sure it's
really a huge difference to say "this host doesn't match the MX pattern;
try the next candidate" as opposed to "this host's certificate doesn't
match the MX pattern..." It seems like both cases are quite similar, though
maybe in some implementations the code structure implies one to be easier
than the other?)

re JSON:

I think when you've reached the point that JSON-vs-key-value-pairs is the
main point of contention it's probably not a *bad* sign. ;)

I had the same feeling as Albert about using something with pre-existing
library support, which was really the main argument for JSON--and I think
since we've already implied a dependency on some HTTPS lib an additional
JSON lib seems not *too* serious. At the same time, it's true that
Postfix's typical deployments may often be likely to be concerned about
each additional library dependency, which is less on my mind here at Google.

This seems mostly like an issue of aesthetics (which is not to say it's
unimportant, but it seems less fundamental than the design questions we've
discussed in the past). If there aren't really strong objections I'd
probably keep JSON since we already have both code and published policies
in that format, but if there are strong objections, I think it's a trivial
matter for the early adopters to change.

On Mon, Mar 27, 2017 at 3:01 AM, Viktor Dukhovni <[e-mail]>
wrote:

>
> > On Mar 26, 2017, at 4:52 PM, Alberto Bertogli <[e-mail]>
> wrote:
> >
> > There are lots of advantages of using JSON for this. It is well defined,
> > standard and there are lots of well tested and widely used
> > implementations.
> >
> > It is used widely, it's familiar to many people, and its shortcomings
> > (which are not few, admittedly) are well understood and documented.
>
> Sure JSON is used widely in all kinds of software, but NOT in MTAs,
> and STS is for MTAs.
>
> > It support rich types (such as lists), and common libraries already
> > handle difficult situations like non-ascii content, long integers,
> > multi-line strings, malformed/malicious input, etc.
>
> Sure in Perl, Python, Go, ... but Sendmail, Qmail, Postfix and Exim
> are in C, and already have code to handle ESMTP attr=value lists, and
> don't currently use JSON.  The extra features of JSON you mention are
> not needed for this specification, and over-engineering to use JSON
> is IMHO not useful.
>
> --
>         Viktor.
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>