NNSquad - Network Neutrality Squad
[ NNSquad ] Re: Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL
Seth David Schoen writes:
> [...]
> assertions. On the other hand, the entities in the DNSSEC delegation
> chain are still in a position to sign delegations that are false.
> Has anybody implemented any automated mechanism for clients to try to
> notify someone when DNSSEC delegations change?
https://addons.mozilla.org/pl/firefox/addon/6415/
This addon too watch x509 cert changes.
Its not as sophisticated as Perspective, but it
works well for power user. Or even less than power user,
just aware one.
>
> If we built a "Perspectives for DNSSEC", would it avoid the concerns
> that Andy Steingruebl raises about Perspectives at
>
> http://www.thesecuritypractice.com/the_security_practice/2010/04/perspectives-on-perspectives.html
>
> ? Because that would be pretty great, actually.
IMO no, we would not. Not to mention that 'voluntary notary network'
does not sound scallable. Nor that voluntary notary network should
do work for CAs who cash hundreds of $ for a couple of mails.
Thats why I preffer SSH and then Certificate Patrol approach:
notify user that something has changed and she need to pay attention,
check carefuly and so on.
Andy (and Global Symposium on DNS Security, Stability and Resiliency
attendees) came up with very good definition of what should be deemed
as right answer to client query: "Client gets the answer to the query
that the zone owner intended.".
The point of our future trust roots is at that:
_the_zone_owner_intended_.
It can be extended to x509 certs (and other means of proving identity).
The key or certificate should be one that zone / site owner intended.
What we need is to know _what_ zone/site owner intended.
Ideally out of band. In my vision, we can know it by checking
up dns node that keeps txt type record with a piece of text:
--------------------------------------------------------
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha1; boundary="boundary"
--boundary
Content-Type: text/plain; format=flowed; charset=utf8
I, Name Surname of Town in Country, hereby certify that
I am owner of subdomain.domain.tld and that my site
uses DNSSEC KEY ..........
uses X509 CERTIFICATE ...........
[...]
undersigned (digitally)
Name Surname
--boundary
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Signature itself
--------------------------------------------------------
No. I am not kidding.
Why is it plain smime signed text?
plain - because judges do like readable documents.
signed - because in all but openly oppresive regimes it is
one thing to get judical approval to intercept communication
(impersonate abstract servers) and another one is to get,
even narrow and one time only, permission to _impersonate_
_real_person_ and issue false statement in her name.
In many jurisdictions later one is not an option, is plain
crime regardless of letters in agency name.
How does it work?
1. Client goes to new site of site.somewhere.tld
2. Client (um, client's resolver) checks if it has zone signed
3. Client retrieves owner's declaration of ownership with key hashes.
4. Client retrieves all elements (certchain ie) it needs to check
owners' signature.
5. If signature is good and keys / certs fingerprints are too
6. Client lights green bulb and stores 3.4. data for future checks.
7. Otherwise warns user that something's rotten.
8. If something will change next time user wants connection to
site.somewhere.tld (ie signature/cert expires), repeat from 2.
>
> --
> Seth Schoen
Regards, Ohir.
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE