[Twisted-Python] AutobahnPython 0.6.3 - WebSocket compression and more

Glyph glyph at twistedmatrix.com
Tue Oct 8 14:49:06 MDT 2013


On Oct 7, 2013, at 4:10 PM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:

> On 07/10/2013 18:58, Glyph wrote:
> 
>> If you have a disagreement, please say /what the disagreement is/ (not
>> just "disagree") and then link to resources instead of abstractly
>> claiming people may find them themselves somehow.  You don't have to get
>> into a big back-and-forth, but I believe DNSSEC implementation work is
>> proceeding in Twisted so it would be good for the community to be aware
>> of these issues.
> 
> Ok. Don't say I didn't warn you. Apologies to anyone who forces themselves to read all this, and please note I DO NOT claim authority on any of this - I'm just a random guy. People should decide for themselves.
> 
> Donald wrote:
> 
> """
> DNSSEC solves none of the problems with the CA system. It just moves the problem around.
> """
> 
> I believe I understand why he said this, but I think it's incorrect to say that DNSSEC solves "none" of the problems. I think it solves many (though not all) of them, and that supplementary systems - which are desirable in and of themselves - can take us the rest of the way.

I think I basically agree with this sentiment.  A lot of security measures are based on threat-neutralization, whereas DNSSEC is based on threat-reduction.  It mitigates intrusions by certain classes of bad actor while still enabling others.

An important thing is that the average user isn't going to perceive any difference in security when using DNSSEC; so they're not going to get a false sense of security from DNSSEC.

> Here's my reasoning:
> 
> I think it's fair to say that the PKIX trust model is known to have some serious flaws. They basically stem from the existence of far, far too many CAs, and the lack of constraint on what a CA can issue for.

One minor quibble I have here is that trust is always between two parties.  The presence of a "trusted third party" is _always_ a problem.  So it's not that there are too many CAs, but rather, that you *always* need a cartel CA to sign your stuff in order to be able to trust someone, and once you have an established trust relationship, you can't base things off of that relationship rather than off of software-distributor (i.e. browser-vendor) granted authority.

> There are various proposed solutions to this problem. DNSSEC-signed TLSA records (DANE; RFC 6698) offer one solution to the problem - to put hashes of certs/keys or issuer/chain certs/keys in DNS, and sign then with DNSSEC. This accomplishes two things:
> 
> 1. Reduction in the number of trusted CAs. To what degree depends on what deployment model you use - you can put a specific key/cert into DNS, or one or more traditional X.509 issuers that allowed to sign for you. The latter in particular seems likely to be common - reduce the CAs that can sign for "blah.example.com" from ~1500 by putting the hashes of the 1/2/N "good" CA certs (most specific parent!) into the "blah.example.com" TLSA records.
> 
> 2. Constraint - a DNS zone-signing key can only sign records below it, terminating at secure child delegations (DS keys).
> 
> The obvious objection to this solution is the necessary trust in the DNS root / parent zones. There are, it seems, people who are not willing to grant this trust. I understand that - particularly in light of recent revelations.

It's worth noting, however, that you are already accepting a certain degree of trust in the DNS root.  Even if your traffic is totally cryptographically secure, if you're talking to a compromised DNS they can still reliably tell (A) who you are talking to and (B) when you are talking to them.

So if the option is "trust the DNS and a bunch of CAs" or "trust the DNS", just trusting the DNS is safer (even if not, in an absolute sense, "safe").

> However: government agencies are not the only people who might want to get certs in the name of a 3rd party. Crime syndicates attacking the latest race-to-the-bottom CA to get "e<some unicode glyph like x>ample.com" certs are a real issue, and DANE can handle these just fine.

Another way to look at it is that governments are the largest, most established crime syndicates, with the most rules governing their use of violence (I won't say they're the "least violent"); so again, the question is "do you want to be vulnerable to SOME crime syndicates or to ALL crime syndicates", the answer is clearly the former :).

> There are arguments that DANE moves the trust problem from CAs to registrars and registries. I must admit, I don't understand the threat model here - it's asserted that registrars are cheap&cheerful (true) but they only handle public key material, and don't run the DNS; the registry is a more fruitful target, but validation of the public key material they publish for you is trivial (whereas proving that a CA somewhere hasn't signed a cert for your domain is not).

This is the sort of thing OCSP and CRLs are for, though, right?

> In short, I think it's a significant net win, and as a side benefit offers greatly reduced key management burden. The ability to publish and revoke TLSA records at significantly lower cost than X.509 cert issuance, and without need to interact with a 3rd party, would be valuable even without the above. It could in theory help decouple TLS from X.509 - useful if you want to move to PGP, for example.
> 
> However, some people don't agree. Moxie Marlinspike discusses the general issues and makes an argument against DANE - see:
> 
> http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/
> 
> ...and the video of the talk here:
> 
> http://www.youtube.com/watch?v=Z7Wl2FW2TcA

Interesting reading.  Thanks for presenting the opposing view as well :).

> He essentially suggests a trusted notary system - a working implementation of which you can see here:
> 
> http://convergence.io/
> 
> I agree that this approach is promising. I am not super-confident that it will take off - end-users literally DO NOT CARE about these issues until it's too late - but if someone (Chrome, Firefox) starts bundling notary functionality and prompting users to trust one or more of a (randomly shuffled) set of notaries on startup, it might... However, I'm not sure how likely that is - see:
> 
> https://www.imperialviolet.org/2011/09/07/convergence.html
> 
> [Note Adam Langley is "Google TLS person"]
> 
> For an alternative take on the problem, see:
> 
> http://www.certificate-transparency.org/
> 
> People interested in reading a pro-DNSSEC PoV should look here (warning - sequence of posts):
> 
> http://dankaminsky.com/2010/12/13/dnssec-ch1/
> 
> ...and here:
> 
> http://www.slideshare.net/dakami/black-opspki-2
> 
> So - not as short as I'd like, but as short as I could make it. I hope that makes my position clear.

Yes, tremendously enlightening.  And I thought I already understood these issues fairly well!

> Finally a note on why I was reluctant to respond...
> 
> In my experience, "discussions" on TLS, X.509, DNS and DNSSEC can become very emotive, very quickly. There are people who care very, very deeply about the minutae of these issues because they directly impact the politics of privacy and symmetry of access to the internet.

I understand.  But that's out there on The Internet, and not here on the eminently civil and thoughtful Twisted mailing list, where we can count on the discourse to be at a higher level :-).  As you can see, no fallout has occurred!

> To be honest, I lack the mental drive to engage in those discussions over the internet. Face to face might be another matter, but I have better things to do with my time than argue with strangers.
> 
> So - if anyone is sitting there bouncing up and down in their seat excited about how wrong I am - forgive me if I don't reply, I'm just not as excited about it. Look me up in real life sometime and we'll chat about it over beer!
> 
> Cheers,
> Phil


Thanks for taking the time to write all this up.

-glyph




More information about the Twisted-Python mailing list