Re: [Uta] MTA-STS-03 review

[Daniel Margolis <[e-mail]>]

To be clear, I didn't reply to comments I thought were minor or needed no
response. So I do agree on fixing the typo. ;)

On Wed, Mar 22, 2017 at 8:18 PM, Viktor Dukhovni <[e-mail]>
wrote:

>
> Thus, my point is that there are two type of names with potential
> wildcards in this context.  There are DNS SAN entries in certificates
> (presented identifiers) whose semantics are (partly) defined in RFC6125.
> RFC6125 leaves room for application-specific behaviour with respect to
> CN-ID
> and exactly which kinds of wild-cards, if any, are supported.  Then
> there are also "reference identifiers" which RFC6125 does not envision
> as anything other than plain literals.
>
> This draft casually treats "mx" constraints as though they were presented
> identifiers from the certificate certificate, and I think this could lead
> to user confusion, but this could be explained by noting that both kinds
> of patterns are compared against the MX hostname, and are then subject
> to similar interpretation.
>

Right. I think it's _fairly_ simple as-is, since you're only ever matching
against a hostname. More on this below.

This is not critical, I'd likely have the transformation from
> JSON to something more natural happen in the software that imports
> data into the policy cache, so that the cache is more MTA friendly.
> Even if policy processing is out of the main MTA executable (Postfix
> is not monolithic like Sendmail or Exim) there is still a new JSON
> library dependency on the MTA package as a whole, and MTAs are part
> of base-system images for various operating system distributions
> (Postfix is part of "base" in NetBSD for example).  So I really
> do think that JSON should be reconsidered.
>

Point taken. In our implementation it's all rapidly converted to
protobuffers, anyway.

But I'd appreciate feedback from the wider peanut gallery here, too.
Parsing key/value pairs isn't hard, but do people prefer that (is there a
standard parser?) versus taking a dependency on an existing JSON lib? Beats
me--happy to hear from n>1 on it, though of course your voice is heavily
weighted, Viktor. ;)


> > If this field is used to validate the server certificate (and not
> > the MX hostnames) as you suggested above, that would entail validating
> > the presented identifier, which I think resolves your comment.
>
> So this draft should probably align with RFC7672 in permitting only
> full-label wildcards (*.example.com) and not partial-label wildcards
> (such as mail*.example.com) in presented identifiers of servers that
> publish STS policy.  Separately, you should define the allowed wildcard
> forms for ("mx" or "san") and perhaps even consider allowing multi-label
> matches for those (another policy field?).  Some domains have MX hosts
> like:
>
>         mx01.<site1>.example.com
>         mx02.<site1>.example.com
>         mx01.<site2>.example.com
>         ...
>
> and might not want to "freeze" all the sites in the policy.  They
> may be content with ".example.com" covering more than one label.
>

Right, as-is we did in fact specify only full-label and only left-most. I
am unconvinced there are many cases where someone has "mx$n.$
siten.example.com" and cannot be content with "*.example.com"--if that's
insufficient for them (because the example.com zone contains untrusted
hosts), perhaps the MXs should be at  "mail.example.com"; at risk of
inducing necessary DNS changes, it seems worth it to preserve simplicity in
the tricky matching rules.


> >> Here, if the proposal to switch from "mx" to "san" is taken up, the
> >> peer certificate is no longer restricted to authenticate the MX
> hostname,
> >> rather, one its presented identifiers needs to match one of the
> reference
> >> identifiers fro the "san" policy attribute.  Either way some discussion
> >> is appropriate of how to perform matching when both the reference and
> >> the presented identifiers are "wildcards".
> >
> > Ah, good point--this is a bit of additional complexity implied by your
> > suggested change.
>
> As explained above, if there's a switch to "san", the comparison of "san"
> values is directly against the certificate, which introduces the
> possibility
> of wildcard-to-wildcard comparison.
>
> > One option would be to merely disallow wildcards in the "mx" (or "san")
> > field.
>
> That's probably too restrictive.  If anything, I'd be more supportive
> in disallowing wildcards in the certificate!  Certificate wildcards
> encourage poor practices (all eggs in one basket when the shared
> certificate fails, all the MX hosts fail, and wildcard certs
> enable redirection attacks between services that share the same
> certificate and application protocol, say HTTP).


> > Another: Specify our own matching rules for wildcards on both
> > identifiers. It's not really that complicated, but I don't favor
> > making people write this and possibly make mistakes.
>
> [ FWIW, already implemented in Postfix,
>   http://www.postfix.org/postconf.5.html#smtp_tls_secure_cert_match ]
>

Yes, so you effectively limit it to wildcards in the leftmost label (if
any). Which seems likely to work for anyone, and the matching is fairly
easy.

Yet it still means that instead of being able to merely validate against a
hostname as in the Go API I linked to, implementors have to write _some_
heretofore nonexistent matching logic. If we restrict it to RFC 7672's
section 3.2.3 logic, it's equivalent to the per-MX logic we already
specified (I think), so no harder for implementors (as long as their TLS
library exposes that, which it ought to). Anything more complex seems like
it could lead to bugs.


> >>>     When a message fails to deliver due to an "enforce" policy, a
> >>>     compliant MTA MUST check for the presence of an updated policy at
> the
> >>>     Policy Domain before permanently failing to deliver the message.
> >>>     This allows implementing domains to update long-lived policies on
> the
> >>>     fly.
> >>
> >> This seems to suggest the contrary, i.e. that it might be appropriate
> >> to bounce on policy failure when a more fresh policy still fails.
> >> However certificate problems (expiration most typically) are transient,
> >> and a receiving system operator should/may notice the problem before
> >> outstanding messages expire and bounce.  So I would urge implementors
> >> to queue, rather than bounce, on authentication failure.
> >
> > Rather, the point of this was to encourage implemenors to _not_ bounce
> > until at least updating the policy once, not to encourage them to bounce
> > _after_ such an update. So I think we agree, but the wording may be
> > suboptimal.
>
> Yes, please clarify.
>
> Note that DANE has one, perhaps non-obvious, "feature" in this space.
> When TLSA records are present, but are all "unusable", authentication
> is not enforced, but STARTTLS is still required.  Thus, while the STS
> "report" mode also tolerates cleartext transmission, DANE TLSA with
> "unusable" TLSA records does not.  Here too, I would not like to see
> STS "report" downgrade DANE to cleartext when both are published.
>

I think that would be a buggy implementation! It doesn't make sense to me
that someone who implements both would treat it as an OR, especially if STS
is in "report" mode. So it's fair to call this out, certainly, but I think
the concern is (hopefully) unwarranted--the point of STS is most decidedly
not to override any existing TLSA records, nor would that make any sense.


> Perhaps this draft need not be fully prescriptive about how the
> two mechanisms interact, but raising the issue is warranted, so
> that implementors make sensible decisions, and/or provide users
> with appropriate controls.
>

I'm happy to suggest people not allow STS to override DANE.