Michael Catanzaro wrote: > On Fri, 2015-07-03 at 11:21 -0400, Mike Pinkerton wrote: > > Isn't the whole point to eliminate the need for third party > > certificate authorities entirely? > > Well I think you could choose to do that, or you could choose to use > it as an additional security measure on top of traditional certificate > authorities. > > > Just to clarify what you are saying -- if there is a third party > > certificate chain which fails, then you would distrust the site. > > But > > if there is no third party certificate authority chain, and DANE > > succeeds, then you would accept the DANE-provided certificate and > > trust the site. > > I was thinking to require both to work, instead of just one or the > other. Seems like that would make life hardest for the attacker. I've been hoping that DANE could get us closer to the goal of encrypting everything by lowering the barrier to using HTTPS. If anyone who has a domain can manage their own crypto keys, then they can enable HTTPS on all of their virtual hosts, test servers, temporary websites and whatnot both cheaper and easier than if they have to buy certificates from a CA. These advantages disappear if browsers will require CA signatures even in the presence of valid TLSA records. Before DANE there were three possible cases: C0: self-signed, that is not signed by a CA C-: presents a CA signature but verification fails C+: signed by a CA and verification succeeds DANE adds a second dimension and we get a matrix of nine possible cases: C0D0: not signed by a CA; has no TLSA records C0D-: not signed by a CA; has TLSA records but verification fails C0D+: not signed by a CA; has TLSA records and verification succeeds C-D0: presents a CA signature but verification fails; has no TLSA records C-D-: presents a CA signature but verification fails; has TLSA records but verification fails C-D+: presents a CA signature but verification fails; has TLSA records and verification succeeds C+D0: signed by a CA and verification succeeds; has no TLSA records C+D-: signed by a CA and verification succeeds; has TLSA records but verification fails C+D+: signed by a CA and verification succeeds; has TLSA records and verification succeeds When you write "require both to work" it sounds like you would accept only case C+D+. That would mean that you would start rejecting C+D0, denying your users access to all current HTTPS sites that don't use DANE yet, so that's probably not what you mean. All of the C- and D- cases are of course highly suspect and should be rejected, but both C0D+ and C+D0 should be accepted in my opinion. C0D+ is the case that removes people's excuses for not using HTTPS, and seems to be what certificate usage 3 in RFC 6698 is intended for. CAs would still serve a purpose. They could continue to provide big websites with "extended validation" certificates that allow browsers to assure the user that the website belongs to a particular company or other entity, whereas DANE only ties the public key to the domain name. Maybe some time in the distant future, when DNSsec is nearly ubiquitous, browsers can start rejecting case C+D0 to give the last few stragglers the push they need to start using DANE. Björn Persson
Attachment:
pgpFiNmRe_0HX.pgp
Description: OpenPGP digital signatur
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
