> On Oct 11, 2016, at 10:45 AM, Martin Rex <m...@sap.com> wrote:
>
> Viktor Dukhovni wrote:
>>
>> Well, the UKS issue is rather narrowly applicable to special TLS
>> applications in which cross-origin concerns apply. That's
>> basically just browsers, and browsers are not doing DANE, and
>> certainly not DANE-EE(3).
>
> I believe your concept is much to narrow.
>
> The issue affects *EVERY* TLS client that will in at least one usage
> scenario perform rfc2818 section 3.1 endpoint identification for
> a TLS server certificate issued from a public CA.
I am not going to quibble over which HTTPS use-case are in scope.
The relevant application-specific decisions can and will be made.
> Every such client, when adopting an alternative TLS server certificate
> validation through DANE, probably ought to check the end-entity certificate
> for appearance of the Certificate Policy with the OID 2.23.140.1.2.2
> and for any TLS server certificate that carries this OID, enforce
> the rfc2818 section 3.1 endpoint identification for the hostname,
> no matter what kind of TLSA record/usage exists for that server.
Likely not all HTTPS use-cases are beholden to the policies of the CA/B
Forum.
One thing I should point out, that the authors of the UKS draft may
not have noticed, is that RFC7671 not only says that name checks are
optional for DANE-EE(3), but also specifies that DANE clients accept
certificate hostnames derived from DNSSEC-validated CNAME records,
when the TLSA records are associated with the target of the CNAME.
Thus, given DNSSEC-validated records as below:
www.impostor.example. IN CNAME www.victim.example.
www.victim.example. IN A 192.0.2.1
_443._tcp.www.victim.example. IN TLSA ...
a client would accept a certificate for "www.victim.example" when
establishing a DANE-authenticated connection to www.impostor.example".
This is probably an issue for browsers in the same way as
directly binding the EE key of "www.victim.example" at
"_443._tcp.impostor.example. IN TLSA ?".
So likely the same applications that SHOULD perform name checks
for all certificate usages, SHOULD also not include expanded
CNAMEs in the set of reference identifiers acceptable from the
server or use such expansions in SNI. By which point, in
such applications, it probably makes no sense to look for TLSA
records at the CNAME target.
--
--
Viktor.
_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane
