- From: Henry Story <henry.story@bblfish.net>
- Date: Mon, 21 Feb 2011 16:29:30 +0100
- To: Paul Hoffman <paul.hoffman@vpnc.org>
- Cc: keyassure@ietf.org, WebID Incubator Group WG <public-xg-webid@w3.org>
(Just a summary of what I understood of this thread, and a few new ideas)
On 20 Feb 2011, at 23:58, Paul Hoffman wrote:
> On 2/20/11 2:51 PM, Paul Wouters wrote:
>> The whole point is we do not want to identify a cert. We want to identify a key.
>
> That's not the case currently, at least for many of us. Given that the only thing that can be used in TLS to identify the server is a certificate, most of us want to identify that certificate (or a trust anchor that the certificate chains to).
One needs to go beyond appearances a little here. My argument is that what identifies a server in TLS is a public key. That this comes in a certificate is a distraction, which ends up creating a lot of mail on formats and makes it difficult to concentrate on the key point. I will put forward the argument why this is so in a semi formal way, and then look at the pros and cons I noticed that came up on this thread
1. A connection by a client C to a TLS service domain:port enables the service to prove to C that it has access to the private key privK of the corresponding public key pubK.
2. After the client C has stepped through the protocol it knows that the service it is connected to, which it hopes is domain:port knows the private key of pubK . Call the handle it has on the service _connSrvc, in order to distinguish it from the real referent of domain:port . So C knows
_connSrvc knowsPrivateKeyOf pubK . [0]
But what it wants to know is
_connSrvc == domain:port . [1]
If knowsPrivateKeyOf is an identifying description - which it is - then what C wants to know is
domain:port knowsPrivateKeyOf pubK . [2]
From [2] and [0] it can deduce [1]. The advantage of [2] is that it contains no local variable such as _connSrvc, ie it can be published globally.
2.1 CAs
Currently that is what a certificate signed by a CA does. It essentially says
CAx saysAndSigns "domain:port knowsPrivateKeyOf pubK. "
Because C trusts CAx it ends up concluding [2] and then [1] above.
2.2 DNSsec lookup
DNSSec lookup works in a similar way, with a twist. The owner of a DNS domain can define the meaning of terms in his namespace. So he can say of any services under his domain what properties they have. The client asking the domain will know, because of the hierarchy of DNSsec signatures that
domainOwner saysAndSigns "domain:port knowsPrivateKeyOf pubK" .
This is definitional. The domain owner is the one who is allowed to specify the meaning of the namespace. He can even specify what the ip addresses of the domain is. To use those DNS names is to agree to that: each player is the definer of the meaning of the names under his domain, which he can the delegate subdomains to other players.
Pros and Cons
-------------
1. Verification of possession of private key
Writing the above out made me understand Paul Hoffman's point
"In specific, certification authorities do many things that are unimportant to most users but are definitely not done by zone operators. For example, zone operators probably do not do proof-of-possession checks for the the private key paired to the public key in the certificate, whereas most CAs do."
http://www.ietf.org/mail-archive/web/keyassure/current/msg01881.html
Yes, so when I sent my CA a certificate they asked me to send them a self signed certificate containing a Domain Name. They then made a DNS lookup to find the Administrator's e-mail listed there, where they sent the CA signed certificate with that domain name. As I was the administrator and the e-mail was correct, I ended up correctly receiving the cert for which I had the matching private key.
In the situation described in 2.2 it would be possible for me to get the public key from the Amazon.com certificate, and put it into my bblfish.com DNSsec entry where I would also enter Amazon.com's ip addresses (if I entered other IP addresses, then connections to port 443 of bblfish.com would of course fail). So then it may be thought that people coming to bblfish.com would end up on Amazon.com's site. Their browser would do the DNSsec verification described in 2.2 and be satisfied that bblfish.com had been contacted. Their users might thing bblfish.com was an excellent book store, which oddly enough had amazon.com written all over it (the issue is less fun if my domain is amzon.com). From time to time I could change the ip addresses and point them to my credit card collection server. And that is frightening.
BUT! It's not that simple. On connecting the browser supporting the algorithm 2.2, must simply be required to use the 1.2 TLS server_name extension which was designed to support virtual hosting. Then the server will refuse the connection if the domain it is serving does not match the one requested. Furthermore at present, since the server is sending a certificate containing the domain name, the client can also verify what the server wishes to be known as. So possession of private key verification does not seem to be needed.
2. On difficulty of comparing ECC keys
Peter Gutmann made an interesting point that ECC public keys can be expressed in a number of equivalent ways which are mathematically difficult to compare for equivalence.
http://www.ietf.org/mail-archive/web/keyassure/current/msg01849.html
possible answer: I suppose that using the public ECC in the the proof of the TLS connection would be ok, but that would push the verification very low.
It looks like the Java does equality between X509 key objects based on their DER encoding. So my guess is that, unless the internal object encodings are somehow canonicalised, then there could be a problem. The bouncycastle class has what looks like a mathematically detailed proof procedure for testing equality
http://www.docjar.com/html/api/org/bouncycastle/jce/provider/JCEECPublicKey.java.html
If one of them can do it, then it all the rest can do it. ECC is still new, and I don't know of many applications that use it. For a programmer using the library in the end it will just be a one method call
pk.equals(pk2).
We have not found it difficult to do RSA comparisons. One just needs to compare a couple of Big Integers. In fact I think it is good for people to get out of the certificate magic, and learn how public keys really work. If it is really impossible to do ECC key comparison, then that's important to know. I would like a few ECC keys that I can prove somehow are equal and see what these libraries do.
3. Size of keys
public keys are going to be bigger than signatures, but smaller than certificates. I am still not sure what the difference is, and have heard different claims here. Of course we should look at minimal, self signed certificates and compare those to the public key and to the signature and work out what the packet size difference is when it's wrapped into the DNSsec wrapper. I know that the main criticism of the Dan Bernstein of DNSsec was the size of the packets and how this could be used for denial of service attacks. See his talk "High-speed high-security cryptography: encrypting and authenticating the whole Internet" http://www.youtube.com/watch?v=ljt1cxUcZMM . Dan Kaminsky had a long response to it
http://dankaminsky.com/2011/01/05/djb-ccc/ but I still think one should be careful not to increase the opening here if possible.
4. X509 richness in extensibility
Peter Gutmann wrote: http://www.ietf.org/mail-archive/web/keyassure/current/msg01864.html
"Another reason to stick with X.509 as key bags is that eventually you're going
to want to put policy in the DNS ("must connect with TLS", "must use EV
certs", "must use a PFS algorithm like DH/ECDH", "cannot use non-FIPS
algorithms", and so on). Guess what X.509v3 key bags were specifically
designed for?"
That makes sense, but I am not sure how hypothetical those extensions are.
It is true for example that the SAN extension in X509 would allow a WebID to be placed there, that would for example allow the service to be described somewhere on the web in more webby, easier to understand and to extend manner. That would then furthermore be linkeable, so that one could develop linked webs of trust much more easily. For example the SAN of a service could point to a profile https://amazon.com/srv/443 which could contain in N3/Turtle
<https://amazon.com/srv/443> co:ownedBy <https://nasdaq.com/co/AMAZN> ...
And other things describing the service.... Well at least one should consider that the extensibility need not be placed inside the X509 cert, making it therefore smaller and the DNSsec less prone to attacks.
5. Complexity of code
This is I think the weakest argument against raw public keys.
- I showed that it takes 2 lines of code with existing java libraries to parse an X509 public
key http://www.ietf.org/mail-archive/web/keyassure/current/msg01878.html
- Yaron Sheffer and Paul Wouters point to existing protocols that use public keys
http://www.ietf.org/mail-archive/web/keyassure/current/msg01811.html
>
> As one of the document editors, if the WG says that it also wants to have keys as targets, I will also need (a) a rationale for why this is wanted
At present I think a lot depends on the difference in size of the keys and the load on DNS. Keys can just be more useful than signatures. But the extensibility of X509 is a point in its favour too.
> and (b) text explaining how to make a certificate association between the key and the certificate that comes from the TLS server. I have asked a few times for these, with no luck so far. I don't know that the WG can actually decide to add bare keys without knowing how they will be used.
That is perfectly reasonable. But before giving text out it was useful to understand the problem space. I'll leave it at this for the moment. This was a very useful conversation, thanks a lot.
Henry
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure
Social Web Architect
http://bblfish.net/
Received on Monday, 21 February 2011 15:30:12 UTC