Alexander Gurvitz wrote:
>
> http://tools.ietf.org/html/rfc6394#section-3.1 :
>
> > Continuing to require PKIX validation also limits the degree to which
> > DNS operators (as distinct from the holders of domains) can interfere
> > with TLS authentication through this mechanism. As above, even if a
> > DNS operator falsifies DANE records, it cannot masquerade as the
> > target server unless it can also obtain a certificate for the target
> > domain.
>
>
> This seems like a mistake to me - DNS operator can always issue a
> fraudulent usage 2/3 record, and thus skip the CA validation.
Nope. The DNS operator can only indicate his intention.
The TLS client might not even look at DANE / TLSA records at all,
or the TLS client might be configure to warn for DANE TLSA 2/3 records
(although maybe with a less intimidating scary page than what
current browsers are showing for untrusted server certs today).
>
> The only advantage I can see in usage 0/1, is that it allows CA-based
> certificate revocation in case of the private key compromise.
The information that is stored in DNS really is not trustworthy,
and the desired continued low cost of adding/changing DNS records
ensures that DNS records will never become trustworthy.
DNSSEC may add data integrity protection and data origin authentication
for the DNS records that it protects, but it does exactly ZERO about
the lack of trustworthyness of most data in the DNS.
If you search google via HTTPS rather than HTTP, the result list
is not going to become any more trustworthy. It will only be harder
for attackers anywhere between google and you to modify your request
or google's response.
-Martin
PS: however, the entry-level "Domain validated" (DV) certs from public CAs
feed on DNS data (AFAIK minus typosquatting), so it is difficult
to conceive how DV-certs could be noticably more trustworthy
than information provided through DANE.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
