Subject: [Uta] STS and SAN (vs Host) matching

From: Daniel Margolis <[email-masked]>
Date: Wed, 01 Nov 2017 10:59:20 +0000

The decision to use policy-to-SAN matching instead of policy-to-hostname
matching was discussed here (
https://www.ietf.org/mail-archive/web/uta/current/msg01938.html). I think
the WG was at the time largely in consensus (or we misread the consensus).
I thought we also discussed this at IETF95, but at this point my memory is
hazy.

To be clear, I think you are right that this affects a small number of
users. RFC 7672 also allows this "nexthop" matching, but I think it's OK
for STS to enforce a "must match the hostname" policy. On the flip side, I
believe SAN matching is also fairly easy to implement (~10 lines of
pseudocode in the Appendix--hopefully correct!--and Viktor says OpenSSL
already exposes such a function).

My understanding is that while you and Jim would prefer hostname matching
and Viktor (and others?) would prefer SAN matching, nobody has said that if
their non-preferred option is chosen this is a blocker for implementation.
Am I right?

If that's correct, process-wise, should we treat this as resolved
previously (in draft 03), or should we try to revisit the consensus and
close it out quickly?

On Fri, Oct 27, 2017 at 6:39 PM Alberto Bertogli <[email-masked]>
wrote:

> On Thu, Oct 26, 2017 at 09:35:34PM -0400, Viktor Dukhovni wrote:
> > > On Oct 26, 2017, at 9:21 PM, Jim Fenton <[email-masked]>
> wrote:
> > >
> > > The question I have is: Why are we matching the certificate against the
> > > policy rather than against the hostname, and is that done in any other
> > > context? Does that offer any additional flexibility?
> >
> > This was discussed when the change was made, and again in response
> > to Ivan's questions just in the past week or so.  The flexibility
> > in question allows the policy to specify that the certificate will
> > match (say) the recipient domain and not the MX hostname, or either,
> > or some unspecified hostname in a domain, leaving the match somewhat
> > fuzzy, which you describe as "wildcard to wildcard".
>
> Note that according to the analysis linked by Daniel [1], "only
> 0.6% of domains present trusted certificates that match their domain
> name, while 34.2% present trusted certificates that match their MX
> server".
>
> So to me you are arguing to add a non trivial amount of complexity to
> certificate validation, and make it differ significantly from widely
> used and tested logic; in exchange for making it easier for <1% of the
> hosts to potentially adopt STS.
>
> I think that is a terrible tradeoff: the implementation complexity and
> security risks are not worth the marginal benefit.
>
> Thanks,
>                 Alberto
>
>
> [1]: http://conferences.sigcomm.org/imc/2015/papers/p27.pdf
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Leif Johansson <[email-masked]>
Date: Wed, 1 Nov 2017 16:24:14 +0100

On 2017-11-01 11:59, Daniel Margolis wrote:
> matching was discussed here
> (https://www.ietf.org/mail-archive/web/uta/current/msg01938.html). I
> think the WG was at the time largely in consensus (or we misread the
> consensus). I thought we also discussed this at IETF95, but at this
> point my memory is hazy. 
> 
> for STS to enforce a "must match the hostname" policy. On the flip side,
> I believe SAN matching is also fairly easy to implement (~10 lines of
> My understanding is that while you and Jim would prefer hostname
> matching and Viktor (and others?) would prefer SAN matching, nobody has
> said that if their non-preferred option is chosen this is a blocker for
> implementation. Am I right?
> 

I have to agree. Given that few people are speaking up in explicit
support for this change, existing consensus hold.

	Cheers Leif

---

From: Jim Fenton <[email-masked]>
Date: Wed, 1 Nov 2017 10:26:37 -0700

On 11/1/17 3:59 AM, Daniel Margolis wrote:
> The decision to use policy-to-SAN matching instead of
> policy-to-hostname matching was discussed here
> users. RFC 7672 also allows this "nexthop" matching, but I think it's
> OK for STS to enforce a "must match the hostname" policy. On the flip
> side, I believe SAN matching is also fairly easy to implement (~10
> lines of pseudocode in the Appendix--hopefully correct!--and Viktor
> says OpenSSL already exposes such a function).
>
> matching and Viktor (and others?) would prefer SAN matching, nobody
> has said that if their non-preferred option is chosen this is a
> blocker for implementation. Am I right?
It looks like this is conflating a couple of different things: (1)
matching CN vs. SAN on the certificate, and (2) matching whatever on the
certificate against hostname vs. STS policy.

For (1) I favor doing whatever browsers do, which I thought was to match
against either CN or any of the names listed in the SAN.

(2) I favor matching the certificate against hostname rather than
policy, because MTAs that already verify TLS certificates (even if it's
only advisory info for log files and Received header fields) do it this
way currently. Otherwise, certificates are matched against different
things depending on whether there's an STS policy or not, and I don't
see a reason to change current behavior. What's the advantage of
matching against policy?

If this is already decided, it's already decided, but I wanted to at
least frame the issue correctly.

-Jim

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 01 Nov 2017 18:02:54 +0000

Sorry, I was referring only to the second issue. I don't think the CN vs
SAN matching is in contention, but you're right to clarify; thanks for that.

The issue was discussed in more detail in the linked thread (
https://www.ietf.org/mail-archive/web/uta/current/msg01938.html). The main
point made in favor of SAN matching, I think, is that there may be some
(empirically rare, as Alberto pointed out) cases where people have existing
certificates that match the nexthop domain and not the MX hostname; RFC7672
explicitly supports this, as I recall. There was also a concern (discussed
previously) that hostname matching lends itself to modifying the MX
traversal algorithm in potentially broken ways--this is avoidable, but it
is a bit of an implementation gotcha.

These are solvable issues, and valid options very much exist in the
hostname matching direction, but I'm trying to distinguish between a
compromise and a decision that would impede implementation or result in a
seriously broken design going forward. I read this as the former and not
the latter.

To answer your point specifically about existing matching logic, *certificates
*which already match the hostname will continue to work perfectly in this
model, and in fact admins who are unaware that we match SANs and think we
match hostnames will nonetheless always craft working policies. *MTAs* who
match certificates against hostnames can, of course, continue to do so, but *in
addition* will have to match certificates against policies. The policy and
hostname checks may result in different outcomes, and an MTA who is
implementing some other certificate validation will have to figure out what
to do then, but this is beyond the scope of the spec here.

Anyway, I am still not hearing strong objections, but I'm happy to hold out
a bit longer. I hope to have a new draft with fixes for the other
discussions on this list shortly.