> On Oct 24, 2017, at 2:48 PM, Jim Fenton <fen...@bluepopcorn.net> wrote:
>
> Regarding a) above: I apparently missed this. Is there any other circumstance
> where the certificate presented is matched against anything other than the
> hostname?
>
> If we go forward with REQUIRETLS, this would require that it match against
> the STS
> policy if one is present, or against the hostname if one isn’t present.
No. If/when REQUIRETLS implies authenticated TLS and not just mandatory,
but possibly unauthenticated encryption, then the authentication mechanism
needs to be left to the sending MTA's choice, it might use DANE, STS, or
some future technology, and what exactly gets checked depends on the
mechanism. So REQUIRETLS must NOT specify how authentication is done.
> I haven’t
> yet fully thought through whether this has any security implications, but at
> first
> glance it seems like spoofing an STS policy where one isn’t present would be
> another
> way to cause REQUIRETLS to accept a certificate it shouldn’t.
It should not be easy to "spoof" STS policy. STS would be rather weak
if it were. STS, for better or worse, is basically as strong as DV
certificate issuance. Use DNSSEC and publish CAA records that only
allow CAs you trust to not issue certificates for your domain to
a rogue party. I have:
$ dig +noall +ans -t caa dukhovni.org | grep issue
dukhovni.org. 3600 IN CAA 0 issue "dukhovni.org"
as I don't presently use any of the public CAs.
--
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
