dnssec-trigger + GNOME + NetworkManager integration

Mike Pinkerton pselists at mindspring.com
Fri Jul 10 20:14:46 UTC 2015


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



More information about the devel mailing list