> 1. While DANE certificate validation as described in RFCs 7671,7672 > and 7673 > is fine in SMTP, IMAP, XMPP, ... for HTTP (and perhaps some > other applications) skipping validation of the target name with > DANE-EE(3) records introduces a "UKS" (i.e. "Unknown Key Share") > issue, that would definitely be a concern for "h3". > > https://datatracker.ietf.org/doc/html/draft-barnes-dane-uks-00 > > Thus, unless "UKS" is known to not be a concern, applications > should also validate the target name against the server > certificate even with DANE-EE(3).
There is something I don't understand about this draft. Support an attacker creates attack[1-3].example.com with 3 different setups: 1) attack1.example.com has a regular PKI cert and the attacker runs a reverse proxy there that relays traffic to victim.example.com 2) attack2.example.com has a self signed cert and DANE with both attack2.example.com and victim.example.com in the DNS names of the cert. Again the attacker has a reverse proxy and relays to victim.example.com 3) attack3.example.com has a DANE record that refers to the cert of victim.example.com. There the attacker directly relays traffic to victim.example.com. >From the point of view of the victim client, how are these three setups different? What makes it that 1) and 2) are fine, but 3) is not. The only hint I can find in the draft is that when a client connects to both attack3.example.com and victim.example.com, finds that both use the same public key, that the client somehow merges them into a single security context. How does that work with CDNs? Does every CDN have a unique public key per hosted client site? In my experience, a hard part of PKI certs is to make sure that every name that can be used to reach the cert is infact listed in the certificate. It would be way better if for DANE, no name checks are done at all. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
