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

[Philip Homburg <[e-mail]>]

>> There is something I don't understand about this draft.
>
>The main thing to understand is that complex applications like browsers
>allow data retrieved from one endpoint to script interaction with a
>*different* endpoint, and possibly see the retrieved content, subject to
>various CORS (Cross-origin resource sharing) controls.

Indeed this is subject to CORS. Nothing new here. Any browser needs to get
this right.

>If the client uses the same (client) certificate to identify itself to
>both the attacker and victim servers, then if it believes that the
>victim server is the same origin as the attacker's server, it may allow
>cross-origin requests between them.

This is broken. There is no reason why a client cerficate should lead the
browser to believe that two sites are the same.

As you describe above, we have CORS headers for that.

In particular, an attacker can always accept a client certificate. If
the mere acceptance of a client cert causes confusion, then the client is
already in deep trouble.

>> Suppose 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
>
>This does not achieve client cert authentication to victim server.

Indeed. The draft does not mention client certs at all.
Where does that come from?

>> 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.
>
>This does would achieve client cert authentication to victim server, if
>the client does not perform certificate name checks.

Which is fine, because this connection is still secure. 

Note that the server gets a request asking for attack3.example.com. So
this should immediately return a failure.

Of course, if the server ignore the host header and then sends private
information to client only based on the client cert, this will cause the
client to be confused.

>For applications other than browsers, sure.  Browsers go out of their to
>run code served by the remote server, and then try to make that somehow
>safe.  It's a miracle they sometimes succeed.

It seems that this is an attempt to solve an insecure server problem at
the client in the context of clients with certificates.

It is a pity that the draft doesn't spell that out at all.

The web security is already complex enough. Maybe we should not fix broken
servers in the client by adding obscure requirements to DANE certificate
processing.