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

Phil Mayers p.mayers at imperial.ac.uk
Mon Oct 7 17:10:51 MDT 2013


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.

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.

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.

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.

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).

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

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.

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.

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



More information about the Twisted-Python mailing list