The YURL

This note addresses the plan for public YURLs. Secret YURLs provide solutions to a class of security problems seldom addressed on the web. More later.

I attempt here to describe the working of the YURL with minimal SSL cert jargon but assuming common notions of the URL and public key crypto. I also rely on classic ideas of symmetric crypto (secret key crypto). httpsy is a protocol proposed for YURLs which shares many of the https mechanisms. Here are some ramifications of broad-spread availability of this technology.

The problem that we address is to make a string of characters, like an URL, reliably designate a unique computer, the ‘site’, on Internet despite mischief in the network between the browser and the site. In particular we do not rely on certificate authorities, nor do we rely on the user verifying that the domain name that appears in the browser address bar is as expected. We call the string a YURL and hope that it will often serve where URLs serve without changes to the code written to deal with URLs. The YURL is like the URL except for including a fingerprint for the public key of the intended site. (dig)
When the browser interprets a YURL it uses the domain name in the YURL to get an IP address as usual.

It then consults a local cache which maps fingerprints to public keys. If the finger print of the key found in the cache matches that in the YURL then we have the the public key of the intended site. A security alarm is sounded on mismatch. This extra check removes cache integrity from the security kernel.
If the cache fails the browser contacts the computer with http soliciting that site’s public key. The site returns its public key, perhaps enclosed in a cert, and the browser fingerprints that public key. If the fingerprint matches that from the YURL then the local cache is updated.

At this point the browser reliably knows the intended site’s public key. The browser chooses a random symmetric crypto key for the session and encrypts that key to the site’s public key and returns that encrypted key to the site. Only the authentic site is able to decrypt that message whereafter at most the browser and the legitimate site know that symmetric key.

Note that no cert like functionality beyond carrying the public key is involved. There is no cert signing and certainly no PKI. Yet we establish a firm connection between the YURL and the site. We do rely in this scenario on the domain name service to provide an accurate IP address. If the service delivers a wrong IP address, or IP routing is compromised, the bogus site will be unable to deliver a public key whose fingerprint matches that in the YURL, unless it delivers the good site’s cert. If the bogus site responds with the real site’s public key then it will be unable the decipher the symmetric key proposed by the browser. If DNS fails to deliver a good IP address then the style of URL with real IP addresses in them will serve for many uses.

Some will be shocked to note that the domain name in a YURL conveys no ‘authenticated’ information about who operates the indicated site. What they achieve instead is that when X accurately transmits a YURL to Y, that YURL accesses the same site for both X and Y. When one opens a bank account it would be wise in this plan to pick up a card at the bank with the bank’s YURL printed on it. This does not seem onerous.

A new sort of site might arise that provides YURLs to well known institutions. I call such a site a register here. A register might include an entry such as:

Here

The register indexes these entries by fingerprint among other indexes. The register might even curate a black list of bad guys.

Unlike certificate authorities this site has no legislated authority; it must maintain its own reputation and is chosen by the user of the browser. The user may be vulnerable to the site he chooses, but is not vulnerable to all CAs as in PKI.

New Browser Function

SSL and TLS now require the browser to solicit the site’s cert and compute its secure hash. With the YURL the browser need not consider a certificate chain via signatures, nor to consult a collection public keys for trusted CAs. It must instead compute the fingerprint and compare that with the version in the YURL. Negotiating the session key is as before. This seems to be a net simplification for the browser.

Perhaps the following is safe and solves the ‘CitiBank problem’. The site normally responds with a chain of certificates, each signing the next. If the browser is validating a YURL, and an allocated bit in the YURL is 1, then it follows the chain comparing the fingerprint of each cert with that found in the YURL. If one of them matches the YURL is OK. Logic much like this is already found in the browser.

A more complex browser function would consult your favorite register. For each new fingerprint the browser consults a local register cache to report in the browser address bar if the current site was one of your commonly destinations. A site pretending to be BofA would not be and the address bar would make this plain.

New Site Function

There seems to be no new site logic except perhaps to promulgate new YURLs via secure channels. Conventional X.509 certs may be used simultaneously for https and httpsy. If the site does not rely on conventional CAs then there is no need to sign the cert, even to self sign. As before, it is vital to guard the private key and the deciphering capability thereto.

Attacks

The platforms upon which the browser logic and site logic run must be sufficient to provide integrity and secrecy for both browser and web server in the site. (That’s a tall order but no different from current SSL.)

The fingerprint in the key must be long enough to protect against an offline search for a public-private key pair with the same fingerprint. Using a subset of the public key’s bits for the fingerprint invites a class of attack using elementary number theory and so I advocate using however many bits security demands, of a secure hash of the public key. It is not necessary for the fingerprint length of all YURLs for a particular site to agree.

The proposed httpsy format specifies the full SHA-1 form of fingerprint and of the whole 509 cert. The ‘hints’ mechanisms there provides a strong mechanism to survive DNS attacks. It requires a bit more browser function related to DNS lookup. In that context corrupted IP routing can deny service but cannot breach security.

A YURL, like an URL, may contain an IP address in place of a domain name. To achieve the host authentication provided by TLS, the URL must contain the domain name which is compared by the client with that found in the cert. YURL authentication does not depend on this comparison.

Bogus Cert; Now a intermediate CA run by French Intelligence (ANSSI) can vouch only for TLDs of France and territories.
Google’s proposed solution; good description; bad solution.
Bill Frantz reminds me that this protocol does not provide forward secrecy. I think that it can be modified to do so and I plan to do this.
SEIF