Re: dnssec-trigger + GNOME + NetworkManager integration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 10 Jul 2015, at 15:40, Björn Persson wrote:

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.


[snip]

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.



I generally agree, except that I see the CAs eventually becoming a legacy artifact, with DANE enabling domains to take control of their own security directly without the mediation of third parties. So I see C+D+ as a transitional step between our current largely C+D0 state and a future C0D+ state.

--
Mike

--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux