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
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
