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

Webid assumes that the market requirements for information assurance will
mature over time. The initiative enables the deploying community to the use
the web as it exists today - accepting that there are vulnerabilities due to
the open nature of web caching and internet naming schemes for servers. With
the rollout of national critical infrastructure element such as IPsec for
routing, secure DNS for names, and national identity cards for individuals,
the assurance webid should rise to meet changing social expectations - since
it is intended to be a part of and also use the public infrastructure. 

 

From: Henry Story [mailto:henry.story@bblfish.net] 
Sent: Thursday, April 21, 2011 6:09 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 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/