Re: wikileaks certs, ICANN, DNS, and DANE. using ldap to parallel a DANE zone

On 21 Apr 2011, at 14:49, peter williams wrote:

> I don’t know why you (and I say you, as I don’t know anyone else who argues for it) ties the brand of webid to DANE. Perhaps there are meetings I don’t know about?

No secret meetings I would be invited to, unemployed as I am :-) I just like the idea. It's similar to WebID.

> One should be aware of lots of political history here, as the telcos in the ENUM space vie for the same power – using DNS more intelligently for key management than simple signed RRs. One might want to understand ENUM, and the issue of private ENUM (the ability to run a walled garden DNS cache, walled off to assure it against poisoning). Comodo looks like a fun little company, but is not the heavy weight in the space.
>  
> Now, I understand the general motive: for a public identifier space, you want/need the authority field of the URI to be assured, as that underpins the denotational semantics of the class resolver (given a class name in the foaf card), and the de-referencing of the resource identifiers to and from the foaf card. If the endpoint providing the proof of identifier control can be spoofed, webid is useless.

yes, you have the motive right. Also the cheaper it is to set up secure https the better it is for us. And of course if DNS is not secure then everything falls apart (using current uri schemes, note I mention others too)

> If the resource server uses a cache of triples for the evidence binding the key to the identifier that is untrusted (or poisoned), webid is useless. (For useless, perhaps read “unassured”, professionally.) These issues don’t get any discussion in the paper (aside from implying the underlying issues with authority, by reference to DANE).

> Without giving the game away, state the assurance limits – as assumptions. Imply that there is a parallel assurance argument, in addition to the functional benefits based on the protocol.
>  
> For commodity systems, for low cost, folks will accept quite low assurance (think real estate) assuming that compensating control system apply to make up for lack of assurance in information systems (think real estate, where one *insures* against error in the title record, uses credit reference to uderping the financial note, and one bases public trust on the notary’s personal identifications…and affadavits). What most matters is resilience, that is. If the entire MLS web system in the US went down for a week there would be a lot of whining (before the manual system kicks back in, as designed, and the trillion dollar cash flow …keeps flowing!). We didn’t allow that economy/flow to become dependent on IT, the internet, or “being online”– by design. When you are running a system critical to a trillion dollar cash flow, you *have* to focus as a security engineer on the assurances – dependencies, resilience, survivability.
>  
> If we can speak a little to these topics, it will be say something to that crowd of American identity types (who are probably pre-selected to get them onboard with the US national id program, which will coordinate such assurance topics).

Do you have a one, two or three sentences that you think could be added somewhere to deal with this concern?

Henry

>  
>  
> From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org] On Behalf Of Henry Story
> Sent: Thursday, April 21, 2011 1:54 AM
> To: peter williams
> Cc: public-xg-webid@w3.org
> Subject: Re: wikileaks certs, ICANN, DNS, and DANE. using ldap to parallel a DANE zone
>  
>  
> On 21 Apr 2011, at 02:53, peter williams wrote:
> 
> 
> “Both of these technologies should help bring about  an increasingly secure Web, whilst avoiding the dystopia of excessive centralization” says the bard in the paper.
>  
> DANE centralizes – in DNS. Just like ICANN centralized naming authority (in some US commerce committee, which holds special power over ICANN), and the top level roots are centralized (in VeriSign/NetworkSolutions, on the territory of the USA).
>  
> It is not as centralised as it appears, as I argues a few weeks ago on this list in the thread "Certificate Authorities under increasing spotlight"
>  
> http://lists.w3.org/Archives/Public/public-xg-webid/2011Mar/0126.html
>  
> So on that view DNSsec is as (de)centralised as CAs.
>  
> But I'll add a twist to the paper.
> 
> 
> You cannot have it both ways. Stuffing a self-signed cert is de-centralized; but if you counter-sign it using a zone-delegation system that is hierarchical, its STILL centralized. No amount of spin will change this reality, to engineers interested in survivability and resilience, etc.
>  
> Remember, a huge amount of work went on to DECOUPLE certs from name servers (otherwise we could have had a signed directory response do what DANE does… about 25 years ago).
>  
> One of the nice things about DANE, though, is that it legitimizes ldaps. If the logic of DANE makes it fine for a DNS zone authority to counter-sign a self-signed cert for a “domain-cert_, its equally legitimate for an ldap authority under a self-appointed zone (dc=com, dc=us -  run by someone called “peter”) to also store a self-signed cert – named identically to the domain-name used by DANE for the same self-signed cert, in the public DNS tree. Then,  one lets the SSL cert(s) of the ldaps endpoint(s) speak as a counter-signature (just as does a DNSSec signature that chains up hierarchically to a top-level zone controlled CENTRALLY, by US vendors by and large).
>  
> Did I say wikileaks, yet , this week? How quickly we forget, how the tentacles of control work through the naming and DNS system – something that did NOT impact the wikileaks SSL certs (note).
>  
>  
>  
>  
>  
> Social Web Architect
> http://bblfish.net/
>  

Social Web Architect
http://bblfish.net/