dnssec-trigger + GNOME + NetworkManager integration

[Björn Persson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signatur
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150710/bbd0ec4d/attachment-0001.sig>