11–20 of 81 posts
Like DNSSEC, whatever protocol comes next ought to support offline signing of k/v data, so that it can be served securely by organizations that can't afford HSMs. And it should be used in a similar way to DANE -- for bootstrapping other protocols in a general way.
DNSSEC got PKI wrong, but what it got right was building authentication (DANE, etc) on a standard protocol (DNS) for exchanging key/value data. Like DNSSEC, whatever protocol comes next ought to support offline signing of k/v data, so that it can be served securely by organizations that can't afford HSMs. And it should be used in a similar way to DANE -- for bootstrapping other protocols in a general way.
~~Huh? That is what a PKI consists of....~~
> Like DNSSEC, whatever protocol comes next ought to support offline signing of k/v data
~~DNSSEC was, from the outset, designed to support offline signing.~~
Update: Whoops, I misread what you wrote! : )
DNSSEC got PKI wrong, but what it got right was building authentication (DANE, etc) on a standard protocol (DNS) for exchanging key/value data. Like DNSSEC, whatever protocol comes next ought to support offline signing of k/v data, so that it can be served securely by organizations that can't afford HSMs. And it should be used in a similar way to DANE -- for bootstrapping other protocols in a general way.
> DNSSEC got PKI wrong, but what it got right was building authentication (DANE, etc) on a standard protocol (DNS) for exchanging key/value data. ~~Huh? That is what a PKI consists of....~~ > Like DNSSEC, whatever protocol comes next ought to support offline signing of k/v data ~~DNSSEC was, from the outset, designed to support offline signing.~~ Update: Whoops, I misread what you wrote! : )
How do you sign a key/value data set with a certificate from Verisign? Are there tools that can automatically follow this delegation?
In DNSSEC once your zone is signed, you can upload an entire signed tree of subdomains. With current CA's, you get one certificate signed for xxxxxxx.com, and have to go back to Verisign for any subdomains (keys) you decide to add later.
I can't add a signed value for __custom_protocol__._wellknown.me.com that uses the existing x509 infrastructure. If I add another server, I can't delegate to it.
> DNSSEC was, from the outset, designed to support offline signing.
Yes... that's what I said. The replacement should support it, too.
Earlier quoted context omitted.
But what do you mean by "online signing" ?
One of the problems is that it exposed DNS zone information, and one of the reason it did that was it was designed to require signing only once and after that the private key didn't have to be used again until the zone info changes.
Earlier quoted context omitted.
> DNSSEC got PKI wrong, but what it got right was building authentication (DANE, etc) on a standard protocol (DNS) for exchanging key/value data. ~~Huh? That is what a PKI consists of....~~ > Like DNSSEC, whatever protocol comes next ought to support offline signing of k/v data ~~DNSSEC was, from the outset, designed to support offline signing.~~ Update: Whoops, I misread what you wrote! : )
> Huh? That is what a PKI consists of.... How do you sign a key/value data set with a certificate from Verisign? Are there tools that can automatically follow this delegation? In DNSSEC once your zone is signed, you can upload an entire signed tree of subdomains. With current CA's, you get one certificate signed for xxxxxxx.com, and have to go back to Verisign for any subdomains (keys) you decide to add later. I can'…
If your domain root is signed by Verisign, you get your domain key signed through your register. The actual procedure varies with the register, from impossible to fully automated. DNS is exactly a key/value dataset.
I just don't understand the point of your other questions:
>Are there tools that can automatically follow this delegation?
Just list the domain. You'll see all delegations there.
> In DNSSEC once your zone is signed, you can upload an entire signed tree of subdomains. With current CA's, you get one certificate signed for xxxxxxx.com, and have to go back to Verisign for any subdomains (keys) you decide to add later.
> I can't add a signed value for __custom_protocol__._wellknown.me.com that uses the existing x509 infrastructure. If I add another server, I can't delegate to it.
Are you arguing that the specific certificates are better? Why?
An attacker just needs to MITM the connection between the target website and a CA of his choosing, and the CA will give the attacker domain-validated certificates for the target website.
So the current SSL in browsers can be compromised not just by the 600+ CAs, but also by anyone who can launch MITM attacks on the internet (e.g. the thousands of ISPs who can publish BGP routes).
For email-based domain validation, the attacker doesn't even need MITM capabilities -- catching the domain validation email in passive bulk data collection is sufficient. The NSA can trivially get valid certificates for arbitrary domains even without the cooperation of any CA! And if the attack on the target website is discovered, it would look like $RANDOM_CA is to blame, even when the CA did nothing wrong (unless you consider the whole idea of domain-validated certificates to be wrong).
DNSSEC+DANE has the potential to be much much more secure than the status quo. The problem is that no one wants to be the first to implement client-side DNSSEC validation and get blamed for failing to connect to incorrectly configured domains.
Personally I think a new DNSSEC2 based on for example online signing might be a good idea.
There is nothing stopping you from doing online signing with DNSSEC. FWIW, DNSSEC is on it's third major iteration, 2/3rds of the TLDs have deployed it, and major DNS service providers are getting into the act.
Earlier quoted context omitted.
> Huh? That is what a PKI consists of.... How do you sign a key/value data set with a certificate from Verisign? Are there tools that can automatically follow this delegation? In DNSSEC once your zone is signed, you can upload an entire signed tree of subdomains. With current CA's, you get one certificate signed for xxxxxxx.com, and have to go back to Verisign for any subdomains (keys) you decide to add later. I can'…
> How do you sign a key/value data set with a certificate from Verisign? If your domain root is signed by Verisign, you get your domain key signed through your register. The actual procedure varies with the register, from impossible to fully automated. DNS is exactly a key/value dataset. I just don't understand the point of your other questions: >Are there tools that can automatically follow this delegation? Just lis…
We seem to be having a communication issue.
From [1]: "Delegation problem: CAs cannot technically restrict subordinate CAs from issuing certificates outside a limited namespaces or attribute set; this feature of X.509 is not in use. Therefore a large number of CAs exist on the Internet, and classifying them and their policies is an insurmountable task. Delegation of authority within an organization cannot be handled at all, as in common business practice."
With DNSSEC this is not a problem. Once I have a DS key pointing to my zone, I can delegate as much as I want. This allows a great deal of flexibility, as I've already mentioned.
[1]: https://en.wikipedia.org/wiki/X.509#Problems_with_certificat...
It seems to me like they're brushing this issue aside, especially with their "but seriously, you don't really expect the NSA to spend tens of millions of dollars to crack a server's security, do you?" comment.
Um, if it's a site that serves millions of people I most certainly do! I'd also expect them to spend that much on any tens of thousand to hundreds of thousands of users Lavabit-like service, too.
With the current CA system, you have to worry about far more than just the CAs. An attacker just needs to MITM the connection between the target website and a CA of his choosing, and the CA will give the attacker domain-validated certificates for the target website. So the current SSL in browsers can be compromised not just by the 600+ CAs, but also by anyone who can launch MITM attacks on the internet (e.g. the thou…