Re: [keyassure] publishing the public key

[Henry Story <[e-mail]>]

On 14 Feb 2011, at 13:46, Ilari Liusvaara wrote:

> On Mon, Feb 14, 2011 at 11:20:33AM +0100, Henry Story wrote:
>> Hi,
>> 
>> In draft-dane-04 [1] one can currently only publish either a signature
>> or a certificate in the DNS. That is the only allowed formats of the
>> resource record are as specified in section 2.2
>> 
>>  1 -- Hash of an end-entity certificate
>>  2 -- Full end-entity certificate in DER encoding
>>  3 -- Hash of an certification authority's certificate
>>  4 -- Full certification authority's certificate in DER encoding
>> 
>> Why not publish the only piece of the certificate that is important in
>> public key cryptography: the public key. ( This is what WebID does
>> currently ) This should be shorter than the certificate, and though it
>> will be longer than the signature, it will be a lot more useful, tying
>> the publisher much less to a particular serialisation format. So you
>> reduce the PGP/X509 disagreements.
> 
> Unfortunately TLS requires sending the full certificate. Yes, one could
> define a new certificate type that contained just the public key, but
> that would require a IETF consensus (RFC through TLS working
> group[1]).

As you certainly know, but as you don't know what I know let me be specific,
TLS does not currently make any claims as to what should be published 
in  DNS. In fact TLS requires(?) that the client will look to see if it can 
build a chain of certificates from the server cert  to a  trusted 
Certificate Authority (CA), and show that the CA authenticates each element
in the chain.
 
keyassure (or is it dane?) will, as I understand, allow another way for trust 
to be established by tying the identity of the server to DNS, rather than 
(or in addition to) tying it to a CA. 

So a User Agent (UA) that is keyassure enabled connecting to a TLS server  
should receive as all UAs now do an X509 certificate. What will be unusual is
that this certificate could be self-signed. 

In the TLS negotiation the UA will have proof that the server knows the private 
key of the public key sent in the certificate, following existing TLS specs. But 
since the Certificate will be self signed the UA will not be able to get confirmation
from a CA that the service that knows that private key is the service that has
global identity alice.example:443 . An evil agent known as Eve could have create a 
public/private key pair and generate a self signed  certificate asserting that it 
is the certificate of service alice.example:443 but place that on the server she
likes to think of as eve.example:443 .

So what do we really need? We just need a trusted service to tell us that 
alice.example:443 is indeed the knower of the given private key. DNS is of course the 
perfect place to get that information, especially when the information can be trusted.
So what we need is DNS to say the following:

<srv:alice.example:443> knowsPrivateKeyOfPublicKey [ a RSAPublicKey; ... ] .

Once that is said, all is said.

My point after that is that so much is said there, that the server would not even
need to send the certificate anymore (saving yet more bandwidth)

> Then one would define new DANE ceritifcate type (3 [2] or 5/6) to
> match that.

ok, so it is possible to do it. 
But I think one should investigate a bit more if one cannot get consensus that
one does not really needs anything more than the public key. After all this is
public key cryptography we are using!

> 
> <snip idea of certificate URLs>
> 
> I don't think that would be possible to use without new certificate
> type either.

I think you could just use the ASN.1 public key object, and DER encode
it. I think that is even specified somewhere. But ok, if the certificate 
type is important... Note that the object does not even have to be signed
(DNSSEC signs things)

> As for bandwidth, sure it would save some. One can send well-secured
> key in roughly 80 bytes total (including CertificateType extension).
> Modern X.509 certs are far larger[3], even if restricted to bare
> minimum fields.

The important calculation would have to be: how many packets does one save
when sending:

  - a hash of an entity certificate
  - a public key only
  - a pretty minimal certificate
  - a usual key 
 
And here one would need two figures: 
  a the size of the information
  b the size after the DNSSEC wrappers that have to be added to the message.

Where the second size is more important of course

> As for what this would be useful for: If the raw key format would
> be easily parsed, it would save lots of tricky ASN.1 and X.509
> parsing (yes, there are libraries for that)

Indeed. That is partly what my thought experiment was getting at: you 
could even remove the ASN.1 from the server, by not having it send server
certs. Though perhaps to bring this up here is to risk confusing issues.


> 
> [1] Not entierely accurate, it is RFC approved by IESG (and they'll
> consult TLS WG).
> 
> [2] Since those 4 types could be collapsed to 2 (2 of those require
> second byte to be zero and 2 require nonzero second byte)
> 
> [3] There's also subtle performance issue there. Those certificates
> can be so large that TCP windows get overflowed. As consequence,
> either one has to break TCP spec (many sites do this) or suffer
> a latency hit.
> 
> -Ilari

Social Web Architect
http://bblfish.net/