On 04/12/2017 10:04 PM, Alice Wonder wrote:
*snip*
Meant to type "third party *signed* DS records"
Okay this is how I would do it. I'm new to list and kind of a nobody but...
DANE is used to secure the long-term private key as an alternate to
commercial DV certificates.
For OV and EV level of confidence - a company can get an x.509
certificate using their zone as the CN and extensions specifying the DS
records that is signed by a trusted third party commercial CA.
This x.509 is only used as verification that the DNSSEC validated DS
records are genuine and to give the consumer confidence the zone has
been validated using OV or EV standards. It does not replace DS records
secured by DNSSEC, only adds a second validation in addition to DNSSEC.
Only OV and EV make sense for this type of x.509.
To compromise a zone protected by this second x.509 a bad actor would
need to both obtain a fraudulently signed x.509 from a trusted authority
*and* get fraudulent DS records into the zone's parent zone.
I'm not an expert on TLS but I think this would even work with existing
TLS, just send this x.509 along with the DANE protected x.509 as part of
the TLS handshake.
Would that work and solve the problem?
_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane
