The argument that security is a chain is a fallacy. Unfortunately Brice tends to push it a lot despite being dead wrong.
A chain breaks at its weakest link, that is why serious security schemes are not developed as chains. So for example, the KGB requirements for handling classified information was that it had to be protected by two separate technologies that each provided 100% protection. So they didn't just use encryption, they also used tempest shielding and put a radiation source and an e/m noise generator into the enclosures. As a result they killed more than a few cipher clerks. If you have a standard A-record resolution mechanism you have a chain openid.example.com A 10.1.2.3 But with an SRV record, you can specify a fault tolerant mesh: _openid.example.com SRV 1 100 80 openid1.example.com _openid.example.com SRV 1 100 80 openid2.example.com _openid.example.com SRV 1 50 80 openid3.example.com The three servers should get 40%, 40% and 20% of the load respectively. We can also specify back up servers to be tried if the first rank servers are unavailable. _openid.example.com SRV 1 100 80 openid1.example.com _openid.example.com SRV 1 100 80 openid2.example.com _openid.example.com SRV 1 50 80 openid3.example.com _openid.example.com SRV 2 1 80 openid_last.example.com The client should first try each of openid1, openid2, openid3 and if none of those work try openid_last. The DNS protocol itself has built in redundancy. DNS name holders are REQUIRED to have at least two name servers and may in practice have an unlimited number if they employ ANYCAST. There are at least five providers of DNS service that offer 99.999% uptime and one that commits to 99.9999% but has an infrastructure built out to deliver 99.999999% unless a war should intervene. If you have redundancy on redundancy on redundancy you can meet very high levels of uptime. What we do once we get to the server could be handled in either of two ways: 1) Have another DNS record to give the URI stem - this is what NAPTR was intended to do 2) Consider the openid over HTTP protocol to be a first rank protocol in its own rank and thus eligible to control the entire URI space for that server. The second makes for a lot cleaner implementation and administration. Remember that the objective of standards making is to eliminate choices that are not useful. If I am working in Apache or IIS (or I would guess any other major Web server) I can easily create as many virtual servers as I like where each server is only distinguished by the host name. URIs are a mechanism for identifying resources on a HTTP service that is supporting multiple resources. If we are using SRV for web service discovery we should have precisely one resource per host name. So we don't necessarily need an endpoint distinguisher. Unless we want to use HTTP caching (and we probably want to make sure we turn it off rather than want to use it), the URI field can simply be ignored. Or we can require it to be the subject uri of the query. My preference would be to specify the URI stem as the protocol name and version number for the Web service since that is what we would likely want to separate on. So imagine that I have three boxes that I am going to configure to support a set of six different Web Services using this discovery mechanism. Instead of naming by boxes openid1, openid2, openid3, I name the boxes ws1, ws2, w3 and set up the SRV records for all of my services. If the client is trying to connect to the openid service and is speaking version 3.2 on box3 it would use the following HTTP header: /openid/3/2 Host: box3.example.com On Fri, Apr 16, 2010 at 11:06 AM, SitG Admin <[email protected]> wrote: >> Let's look at the complete SRV record: >> >> _openid._tcp IN SRV 0 0 8080 openid.example.com. >> >> We have a machine name, but what is the URL to the endpoint for logging >> in? >> What is the user's OpenID URI? > > I think Phillip is proposing a discovery chain - more opportunities for > other parties to step in (at their layer) and take control, more points of > failure if vulnerabilities are discovered in each protocol - and to be fair, > DNS is *already* such a layer. OpenID relies on it. > > -Shade > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
