Re: [DNSOP] New Version Notification for draft-rebs-dnsop-svcb-dane-00.txt

[Philip Homburg <[e-mail]>]

> 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.