Subject: [keyassure] publishing the public key

From: Henry Story <[email-masked]>
Date: Mon, 14 Feb 2011 11:20:33 +0100

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.

There is no need to send a full certificate. Many users will only need to tie a name to a public key and to have a guarantee of the integrity of the information. But the integrity is itself assured by DNSSEC. The tying of the name to the public key is done by the lookup in DNS, as with eg: _443._tcp.www.example.com ) So all that is really required is to return the public key - the type (RSA, DSA, ...) and the fields. This can be done in ASN.1.

  The following use case may help: Imagine a future revision of TLS, which permits the server to not send the server certificate, a bit as the client_certificate_url extension of TLS 1.2 allows the client to send a URL to a location of his certificate, instead of sending his certificate in order to save bandwidth. Here the server just tells the client to look up his public key in DNSSEC .  This would then save bandwidth at both ends: the server would not need to send his certificate and DNSSEC would just send the minimal information needed to confirm. 

   The public key by itself would not be able to contain the types of restrictions on usage of the key of course: only use for signing, ... that are available in X509. 

   An important question is of course: how much bandwidth does one save?

Henry

[1] http://tools.ietf.org/html/draft-ietf-dane-protocol-04

Social Web Architect
http://bblfish.net/

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 14 Feb 2011 14:46:17 +0200

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
> 
> 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]).

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

<snip idea of certificate URLs>

I don't think that would be possible to use without new certificate
type either.

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.

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)

[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

---

From: Henry Story <[email-masked]>
Date: Mon, 14 Feb 2011 15:02:18 +0100

> that would require a IETF consensus (RFC through TLS working

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

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!

> I don't think that would be possible to use without new certificate

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)

> Modern X.509 certs are far larger[3], even if restricted to bare

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

> 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.

Social Web Architect
http://bblfish.net/

---

From: Paul Wouters <[email-masked]>
Date: Mon, 14 Feb 2011 09:19:32 -0500 (EST)

> 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, an…

Yes. This was asked by others including me as well. People thought it would be no
problem to add this to dane once a bare public key TLS method exists.

>   An important question is of course: how much bandwidth does one save?

Bandwidth does not really matter. What matters is latency (less round trips) and a riddance of ASN.1
parsing.

If you want to help writing a bare public key TLS variant, please contact me.

Paul

---

From: Henry Story <[email-masked]>
Date: Mon, 14 Feb 2011 15:54:57 +0100

> If you want to help writing a bare public key TLS variant, please contact me.

What do you mean by a bare public key TLS variant? You mean start an IETF group
to spec out how the client and the server should communicate in a TLS variant
that would not require the server to send a certificate? Or is this something that
one needs to do to explain how a User Agent can prove authenticity of the server from
a public key alone? (That's so simple it's a bit difficult to even see how to write it)
Or is it just that one needs to specify text for dane? Or is dane a subproject of 
keyassure, and this is referring to some other project here? Or is do
we just need to specify some text that is going to go into dane?

Sorry. I don't have a good picture of the web of specs that dane is tied into.

If its longer project I probably won't have time to do this myself as I am already 
quite tied up with WebID. But if I know what is needed we could write up a little 
note on the W3C WebID Incubator Group ( http://tinyurl.com/webidxg ) for our final 
report on what browser improvements would be helpful, and why. Hopefully this will 
be something that the browser vendors at the W3C could have a closer look at. But
it really depends on how long the project is. Perhaps there are people on our list who
have more time to participate. Perhaps this won't take so long to do...

	Henry

Social Web Architect
http://bblfish.net/

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 Feb 2011 07:17:55 -0800

On 2/14/11 2:20 AM, Henry Story wrote:
> Why not publish the only piece of the certificate that is important
> in public key cryptography: the public key.

There is an open issue for this question. See #14 in 
<http://trac.tools.ietf.org/wg/dane/trac/report/1>. When the chairs want 
to open that for discussion, there will certainly be lots of opinions on it.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 Feb 2011 07:24:23 -0800

> Sorry. I don't have a good picture of the web of specs that dane is tied into.

Please read the TLSA document. It is "tied" to TLS and DTLS only.

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 Feb 2011 18:33:15 +0100 (MET)

Paul Wouters wrote:
> Yes. This was asked by others including me as well. People thought it would
> be no problem to add this to dane once a bare public key TLS method exists.
> 
> Bandwidth does not really matter. What matters is latency
> (less round trips) and a riddance of ASN.1 parsing.

The current approach of admins to run a TLS server with a bare public
key is to generate themselves a self-signed (X.509v1) Certificate.
That is probably what many folks are doing when protecting Web access to
their HomeNAS, Home DSL-router, Home DVB-s receiver, etc.

This works with the installed base, in particular with the installed
base of servers.  Though it doesn't work that well with Web Browsers
as clients.  In particular, many recent browers are pretty badly broken
when it comes to a sensible UI for servers using a self-signed cert.

-Martin

---

From: Henry Story <[email-masked]>
Date: Mon, 14 Feb 2011 18:59:33 +0100

> when it comes to a sensible UI for servers using a self-signed cert.

Indeed, and this is why keyassure is going to be so useful for those people. 
They must just be itching to pop their public keys in DNSSEC as soon as the 
first browser vendors implement it. So you are guaranteed a large community
to spread the word and give you feedback. And I think Browser Vendors will be
very keen to implement this, as well as DNSSEC of course, given the terrible state
of DNS.

From WebID's perspective we love keyassure, because it will make deployment of https 
so much easier, and so make it much easier to create the Secure Decentralised 
Social Web which we want to build.  In fact we have an issue open there to follow 
your work here

 http://www.w3.org/2005/Incubator/webid/track/issues/5

It also permits "Turning every Web Server into a CA"
http://lists.w3.org/Archives/Public/public-xg-webid/2011Feb/0060.html

which is pretty cool I think.

 So all of the above will work as keyassure is written out now, but I do 
think that if one can reduce the bandwidth used by DNSSEC as much as possible
as well as get the best value for the bits used - which I think the public key
does - all the better. That will reduce the talk of DNS as a Denial of Serice 
Attack amplifier.

	Henry

Social Web Architect
http://bblfish.net/

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 Feb 2011 19:29:20 +0100 (MET)

Henry Story wrote:
> to spread the word and give you feedback. And I think Browser Vendors will
> be very keen to implement this, as well as DNSSEC of course, given the
> terrible state of DNS.

Not at all.  The average Home user (private home DSL subscriber) is
not a DNS admin, let alone a DNSSEC admin.  So for accessing the Web-UIs
Home devices/equipment/gadgets, DANE will be mostly irrelevant.

But maybe some of the Browser maintainers fix their UIs and start
to distinguish direct access to local resources on private networks
(such as 192.169.x.x and 10.x.x.x and hostnames without domains attached)
from access to resources on the internet.  And stop behaving like nagware
for commercial CAs.

-Martin

---

From: Henry Story <[email-masked]>
Date: Mon, 14 Feb 2011 20:07:04 +0100

>> be very keen to implement this, as well as DNSSEC of course, given the

I was thinking of the issue brought up by the EFF SSL Observatory project, 
that they presented at the Choas Communication Congress in Berlin right
after Christmas 2010 in a talk entitled "Is the SSLiverse a safe place?"

    https://events.ccc.de/congress/2010/Fahrplan/events/4121.en.html

And you can get video on youtube. In particular if you look at slide 10 (of 56)
 
    http://www.youtube.com/watch?v=VUKCDm04AqI&feature=player_detailpage#t=631s

They point out that of the 16.2 Million servers listening to port 443 , only 11.3 Million
started an SSL handshake, and only 4.3 Million had a valid cert chain. So that means that
there are immediately 7 Million servers which could be helped if getting an SSL certificate
could be made a lot easier. And this is not counting how many others would start deploying
SSL if it was easier to do.

   I can't remember if in their presentation they tell us how many valid self
signed certs they found out there... One couls download the DB you query it locally...

> Home devices/equipment/gadgets, DANE will be mostly irrelevant.

Ah you mean for accessing the SSL protected internal servers....

> from access to resources on the internet.  And stop behaving like nagware

I see what you are getting at...

Interesting thought. It's tricky as to how one should do that correctly without there
being a danger in large organisations of people putting up evil SSL proxies.

Perhaps the following could work. Imagine that these devices come shipping with DNSSEC servers that work internally  to resolve those addresses, and which use keyassure to publish the public key... Perhaps  there is something at the DNSSEC level that can be done there...? 

Henry

Social Web Architect
http://bblfish.net/

---

From: Scott Schmit <[email-masked]>
Date: Mon, 14 Feb 2011 21:21:03 -0500

> that would require a IETF consensus (RFC through TLS working
<snip bandwidth considerations, etc>

People keep saying that, but I don't think it's true. This is always an
option:

In some order:
* Client looks up bare key in DNS
* Client connects to TLS service, TLS service sends cert/cert chain

Then, instead of comparing the key/hash of key to the whole cert, the
client picks out the public key and compares them (or their hashes).  If
they match, use the cert as before.

If later the TLS WG develops a bare key option to TLS, this should
transparently support that (the processing changes, but otherwise, it's
the same).

There are problems with this approach, but I'd rather the conversation
not stop with "it's impossible to put bare keys in DNS until TLS
supports it directly!" Instead, I'd prefer we discuss the problems that
a bare key approach would need to deal with. I suspect most of them are
at least related to the question of what cert fields to pay attention
to.

Some issues that would need to be understood/resolved:
* the bare key doesn't tell you anything about the algorithm it's for
(or how to interpret it, really)
* a hacker could potentially alter the certificate in some unexpected
way (usually only affects EE certs if the TA certs are well-protected)
from what the service owner expected -- whether this matters depends on
what you were getting out of the other cert fields.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 14 Feb 2011 21:46:26 -0500 (EST)

> * Client connects to TLS service, TLS service sends cert/cert chain

Why does TLS service have to send cert/cert chain? The client already has
all it needs to know, the bare public key and the DNSSEC validation asserting
the key is validated for use.

> they match, use the cert as before.

the problem is if cert now contains a CN=www.paypal.com. Browser vendors do
not want to ever display information that has no been validated, and for
DANE public keys, none of the certificate is validated. This is why its
better not to drag in these things to begin with.

> at least related to the question of what cert fields to pay attention

I'd be in favour of this, though I also understand people don't want to add
types for vapourware.

> (or how to interpret it, really)

The RRTYPE would need to tell you. Currently, we only have the "hash type"
(section 2.2) though that could perhaps be expanded to also contain the public key type.
Or alternatively, we add another field similar to how DNSKEY describes the
key algorithm (and possibly using the same values)

> what you were getting out of the other cert fields.

This is why "bare public key" has no PKIX container.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 Feb 2011 19:25:39 -0800

On 2/14/11 6:46 PM, Paul Wouters wrote:
> Why does TLS service have to send cert/cert chain?

Because that is what is required by the TLS standard. We should not be 
trying to modify the TLS spec in this WG.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Feb 2011 00:12:08 -0500 (EST)

On Mon, 14 Feb 2011, Paul Hoffman wrote:

> Because that is what is required by the TLS standard. We should not be trying 
> to modify the TLS spec in this WG.

I understand, but there IS a relationship here. With DANE, you have an
alternative to PKIX-TLS. So such a change would affect TLS, but would
require DANE. Similarly, the TLS group could say "we won't add bare
public key because there is no validation for it" and they'd send me
back to DANE.

So please don't call bare public key out of scope yet.

Paul

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 15 Feb 2011 14:16:21 +0200

> So please don't call bare public key out of scope yet.

There are actual technical reasons why putting raw TLS keys in DNS
is a bad idea.

- The problems it causes with TLS library APIs.
- The problems it causes with multiple A/AAAA records.
- The problem of not being able to use the sceme for client-to-server.

You need a new TLS certtype anyway. I say it is much better way to
define new raw key TLS certtype and then assure those via DANE.

BTW: Here's one format for raw keys (no ASN.1):

General conventions:
* uint<n> is n-bit (padding by zeroes on most signficant bits of
first octet to be next multiple of an octet) big-endian number.
* poly<L> is an element of GF(2^L) given in polynomial basis
(again padding on most signficant bits of the first octet with zeroes to be
next multiple of an octet).

struct rawkey_certificate {

//TLS HashAlgorithm registry, MUST NOT be 0 (unhashed) nor 1 (MD5). SHOULD
//NOT be 2 (SHA-1).
	uint<8> tls_hash_algorithm; 

//Key type
	uint<16> key_type;

	switch(key_type)
	{
	case 0:
		//RSA
		uint<16> L_rsa_n;
		uint<16> L_rsa_e;
		uint<L_rsa_n> rsa_n;
		uint<L_rsa_e> rsa_e;
	case 1:
		//DSA
		uint<16> L_dsa_p;
		uint<8> L_dsa_q;
		uint<L_dsa_p> dsa_p;
		uint<L_dsa_p> dsa_g;
		uint<L_dsa_p> dsa_y;
		uint<L_dsa_q> dsa_q;
	case 2...20:
		//Prime ECDSA public key (see the table of curves).
		uint<L> ecdsa_Y_x;
		uint<L> ecdsa_Y_y;
	case 21...30:
		//Binary ECDSA public key (see the table of curves).
		poly<L> ecdsa_Y_x;
		poly<L> ecdsa_Y_y;
	//Other key_types to be defined.
	}
}

Constraints for certificate length (L_cert) with different keytypes:

RSA: L_cert >= 7 + ceil(L_rsa_n / 8) + ceil(L_rsa_e / 8)
DSA: L_cert >= 6 + 3 * ceil(L_dsa_p / 8) + ceil(L_dsa_q / 8)
fixed-curve ECDSA: L_cert >= 3 + 2 * ceil(L / 8).

The reason why I did not define arbitrary ECDSA curves is that PKIX forbids
those and defining full elliptic curve format is actually much more
involved than just using a slew of ready-made curves (it could be done, just
allocate a key_type for that).

I didn't do point compression because ECC points are small anyway and
unpacking those if p = 4k + 1 (like NIST P-curves have) is a bit nasty.

Table of curves:

Keytype:	Type:	L:	Curve:
--------	-----	--	------
2		Prime	192	NIST P-192
3		Prime	224	NIST P-224
4		Prime	256	NIST P-256
5		Prime	384	NIST P-384
6		Prime	521	NIST P-521
7		Prime	160	Brainpool P160r1
8		Prime	192	Brainpool P192r1
9		Prime	224	Brainpool P224r1
10		Prime	256	Brainpool P256r1
11		Prime	320	Brainpool P320r1
12		Prime	384	Brainpool P384r1
13		Prime	512	Brainpool P512r1
14		Prime	160	Brainpool P160t1
15		Prime	192	Brainpool P192t1
16		Prime	224	Brainpool P224t1
17		Prime	256	Brainpool P256t1
18		Prime	320	Brainpool P320t1
19		Prime	384	Brainpool P384t1
20		Prime	512	Brainpool P512t1
21		Binary	163	NIST B-163
22		Binary	233	NIST B-233
23		Binary	271	NIST B-271
24		Binary	409	NIST B-409
25		Binary	571	NIST B-571
26		Binary	163	NIST K-163
27		Binary	233	NIST K-233
28		Binary	271	NIST K-271
29		Binary	409	NIST K-409
30		Binary	571	NIST K-571

[1] (EC)DSA has no indication what hash type is used.

-Ilari

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 Feb 2011 07:30:55 -0800

On 2/14/11 9:12 PM, Paul Wouters wrote:
> require DANE.

I disagree that us using bare keys for identifying TLS server 
certificates is impossible.

> Similarly, the TLS group could say "we won't add bare

They could say that, but you have not even asked the TLS WG, have you?

> So please don't call bare public key out of scope yet.

Paul, saying that is ridiculous. In the message that preceded the one 
you replied to, I actually supported bare keys as long as proponents can 
propose wording that the WG would support on how they should be included.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Feb 2011 11:19:22 -0500 (EST)

On Tue, 15 Feb 2011, Paul Hoffman wrote:

> Paul, saying that is ridiculous. In the message that preceded the one you 
> replied to, I actually supported bare keys as long as proponents can propose 
> wording that the WG would support on how they should be included.

Sorry, I should have been more clear. I did not mean you personally with
that statement.  I meant in general for the keyassure list to keep bare
keys under consideration when continuing to work out the DANE protocol.

Paul

---

From: John Gilmore <[email-masked]>
Date: Tue, 15 Feb 2011 13:58:15 -0800

> signed certs they found out there...

According to Chris Palmer of EFF, the SSL Observatory found 7 million
self-signed certs (and 4.3 million with other certs).  But none of the
self-signed certs were considered "valid self-signed certs" because
the definition of "valid" was "with a valid signature chain, according
to at least one browser", and of course browsers consider self-signed
certs invalid.

It appears that securing your web site with crypto is about three
times as popular as obtaining a certificate from a certifying
authority.

So, providing a simple way in DNS for those 7 million web
administrators to securely anchor their website's public keys to their
domain names, without dealing with a certificate authority, would
provide significant benefits to literally millions of people.

	John Gilmore

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Feb 2011 10:01:49 -0800

A much better saving is to use the tls option that allows for fast rekey by means of a kerberos like ticket stored on the client side.

That approach means the client does one key exchange and that is leveraged over multiple http sessions.

The cert is only a kb, self signed certs are less and your main saving would be not having the signature. Looking at the tls key exchange, what matters is packets, not really bytes. I dont think you will find certs vs keys saves a packet.

Sent from my iPad

On Feb 14, 2011, at 4:46, Ilari Liusvaara <[email-masked]> wrote:

> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 19 Feb 2011 14:41:47 +1300

Paul Hoffman <[email-masked]> writes:

>I disagree that us using bare keys for identifying TLS server certificates is
>impossible.

It's not impossible, but close to it (and for ECC algos it may well be
impossible).  This is a really, really bad way to identify a cert.  For
relatively simple algorithms like RSA "all" you need to do is decode the key
in the cert (assuming your PKI API actually gives you access to it, if it just
treats the cert as a blob used for signing or encryption then you may not be
able to get to it), decode the key in DNS, canonicalise the two in some
manner, and then compare the components (as opposed to storing a hash of the
cert, for which you call memcmp(), thus the "all" in quotes above).  For ECC
keys there are so many ways to store the same key (different parameter
encodings, optional parameters, different ways of identifying the same
parameters and in different formats) that in general there's no really
reliable way to compare them.  Even with the simplest key type, RSA, it was
hard enough, I've got code that mostly works most of the time and that's way
more complicated than it has to be.

If you want to uniquely identify a certificate, use the SHA-1 hash like
everything else does.

Peter.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 20 Feb 2011 17:51:46 -0500 (EST)

On Sat, 19 Feb 2011, Peter Gutmann wrote:

> impossible).  This is a really, really bad way to identify a cert.

The whole point is we do not want to identify a cert. We want to identify a key.

> more complicated than it has to be.

But such a method can be standardised in an RFC? And possibly be re-used for
other standards - like DNSKEY.

> If you want to uniquely identify a certificate, use the SHA-1 hash like

Sure. That's one of the options in the TLSA draft right now.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 20 Feb 2011 14:58:28 -0800

> The whole point is we do not want to identify a cert. We want to

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).

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 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.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 20 Feb 2011 18:16:10 -0500 (EST)

On Sun, 20 Feb 2011, Paul Hoffman wrote:

> That's not the case currently, at least for many of us.

I'm unclear if you mean "currently with CAs" or "currently within the DANE draft".

> 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).

You confuse me here too. We have an RRlabel, which replaces the validated CN=
and the key (blob or hash) that replaces the public key part of the cert.

> 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 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.

I will get that to you before Prague.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 20 Feb 2011 15:32:14 -0800

> I'm unclear if you mean "currently with CAs" or "currently within the

Neither: I mean "currently with the WG, as far as this discussion has gone".

>> 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).
>

Quite true. But we don't have any text that says that.

>> 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.
>

Ah! So we will. If someone comes up with text before then, great, but if 
not, can we put this discussion on hold until we have something concrete 
to discuss?

---

From: Henry Story <[email-masked]>
Date: Mon, 21 Feb 2011 16:29:30 +0100

(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:

> 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

Social Web Architect
http://bblfish.net/

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Feb 2011 17:10:53 -0500

At 4:29 PM +0100 2/21/11, Henry Story wrote:
>>  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.

Do you mean "identifies" or "authenticates?" I think most folks view 
the DNS name (or URL) as the identity of the web site. We're debating 
the mechanics
of how to enable a client to verify that the asserted identity 
matches the client's expectations, based on the content of a series 
of DNS records.

Steve

---

From: Henry Story <[email-masked]>
Date: Tue, 22 Feb 2011 00:49:38 +0100

On 21 Feb 2011, at 23:10, Stephen Kent wrote:

>> One needs to go beyond appearances a little here. My argument is that what identifies a server in TLS is a public key.
> 
> Do you mean "identifies" or "authenticates?" I think most folks view the DNS name (or URL) as the identity of the web site.

Partly. The DNS domain name is a name that one could think of as referring to a set of services, each of those having a name of the form name:port. The relation between the service name and the public key forms an identifying description, or I should say  a definite description  as it is known in philosophy. I used the following example:

  name:port knowsPrivateKeyof pubK 

That sentence does not authenticate, it describes. But it is part of the TLS authentication protocol. Authentication is the process that uses that information to prove the authorship of the messages sent down a socket.

> We're debating the mechanics of how to enable a client to verify that the asserted identity matches the client's expectations, based on the content of a series of DNS records.

Yes, that is what the next part of my e-mail was describing the logic of. Now in the case of server identity the client knows what it wants the server's identity to be, since it initiated the call, went to DNS, found the ip address, and connected. The clienet can then use the public key found in DNS (or returned  by the server) to authenticate the service it is connected to.

Social Web Architect
http://bblfish.net/

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Feb 2011 21:00:14 -0500

At 12:49 AM +0100 2/22/11, Henry Story wrote:
>...
>  >
>>  Do you mean "identifies" or "authenticates?" I think most folks 
>>view the DNS name (or URL) as the identity of the web site.
>
>Partly. The DNS domain name is a name that one could think of as 
>referring to a set of services, each of those having a name of the 
>form name:port. The relation between the service name and the public 
>key forms an identifying description, or I should say  a definite 
>description  as it is known in philosophy. I used the following 
>example:
>

I don't think that most users, who often can't even tell if they have 
contacted a TLS-secured site, would think of a public key as part of 
the identity for the service. I also don't think that most of them 
think about the port either.

>That sentence does not authenticate, it describes. But it is part of 
>the TLS authentication protocol. Authentication is the process that 
>uses that information to prove the authorship of the messages sent 
>down a socket.

once the TLS session has been established, it is symmetric crypto, using a key
delivered or derived using a public key (or pair thereof) that provides the
data origin authentication and connection-oriented integrity guarantees to
which you allude.

>  > We're debating the mechanics of how to enable a client to verify 
>that the asserted identity matches the client's expectations, based 
>on the content of a series of DNS records.
>
>Yes, that is what the next part of my e-mail was describing the 
>logic of. Now in the case of server identity the client knows what 
>it wants the server's identity to be, since it initiated the call, 
>went to DNS, found the ip address, and connected. The clienet can 
>then use the public key found in DNS (or returned  by the server) to 
>authenticate the service it is connected to.

right.

Steve

---

From: Henry Story <[email-masked]>
Date: Tue, 22 Feb 2011 10:17:44 +0100

On 22 Feb 2011, at 03:00, Stephen Kent wrote:

> I don't think that most users, who often can't even tell if they have contacted a TLS-secured site, would think of a public key as part of the identity for the service. I also don't think that most of them think about the port either.

I was not speaking to most users but to this group of security specialists during a discussion on a protocol. The public key is a definite description that uniquely identifies the agent for the purpose of computers, not for the general public.

> data origin authentication and connection-oriented integrity guarantees to

I am aware of symmetric cryptography's role. But it is public key cryptography that is core in authenticating the server, and setting up the symmetric crypto channel. Symmetric cryptography is used because it is less cpu intensive.

Social Web Architect
http://bblfish.net/

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 22 Feb 2011 07:38:13 -0800

Henry: It feels like you are pushing for DANE and WebID to have "bare 
public key" as a way of doing certificate identification without 
justification for how this could be useful in DANE. Without taking any 
stance on WebID, I find this frustrating as the document co-author in 
DANE. The two protocols do not have the same targets and do not even run 
over the same transports.

Could you please re-split the discussion and, in the DANE part, be much 
more specific about how you see bare public keys in DANE being used with 
just TLS? Thanks!

---

From: Henry Story <[email-masked]>
Date: Tue, 22 Feb 2011 17:24:35 +0100

On 22 Feb 2011, at 16:38, Paul Hoffman wrote:

> Henry: It feels like you are pushing for DANE and WebID to have "bare public key" as a way of doing certificate identification without justification for how this could be useful in DANE.
> Without taking any stance on WebID, I find this frustrating as the document co-author in DANE. The two protocols do not have the same targets and do not even run over the same transports.
> Could you please re-split the discussion and, in the DANE part, be much more specific about how you see bare public keys in DANE being used with just TLS? Thanks!

So splitting the discussion here, and stopping the cross posting.

Advantages for DANE
===================

I think my main reason for why this could be better for DANE were:

 - much shorter entry in the DNS, which has to be fast and efficient
 - simpler to understand (few people understand what is in X509)
 
I understand why others think that it's easier to put a full X509 in the DNS. The parsing libs are there, and there is the idea that they could re-use the semantics of X509, which I don't have enough understanding of. 

  So just by myself I would not know at this point what the right thing to do is. I hope my arguments have helped sort out some good arguments from some less good ones so that the right decision, whatever it is can be made.

WebID will work logically just as well with DANE if it has full X509 certs in the DNS as if it has bare public keys - especially if whatever the outcome, browser vendors adopt DANE for the purpose described in 1 above. 

WebID is putting bare public keys in the Profile Pages, so I was wondering why DANE does not do it too. 

Reasons for interest of WebID
=============================

Here are a few reasons for my interest in DANE, which does not get to answering the bare public key part of your question, but I'll just use it to frame my recent contribution.

 1. DANE should make it easy for the self signed https end points that are currently 3 times more numerous than CA signed https end points to be authenticated by browsers. Those browsers will no longer need then to display ugly warnings messages that users are now taught to bypass. This is good for https, for security and so for WebID

 2. The cheaper and easier https endpoint deployment is the better for WebID. Dane should make that possible I hope by allowing site owners to publish the public keys (bare or inside X509 certs) for the services in DNS

 3. DANE and WebID are using different transports but the authentication logic are nearly the same. Where Dane can be used to authenticate servers, WebID is used to authenticate clients. Semantically it's nearly a mirror image - though WebId would end up building on top of DANE.

Henry

Social Web Architect
http://bblfish.net/

---

From: Henry Story <[email-masked]>
Date: Tue, 22 Feb 2011 19:57:15 +0100

Ok so the following off list conversation between me and Paul, should have helped reduce the 
bandwidth pressure on the group. I'll send it back to the list because I think that at least
I am in sync with how Paul is thinking, so that should help.

On 22 Feb 2011, at 19:16, Paul Hoffman wrote:

> On 2/22/11 9:28 AM, Henry Story wrote:
>> 
>> On 22 Feb 2011, at 18:23, Paul Hoffman wrote:
>> 
>>> On 2/22/11 9:14 AM, Henry Story wrote:
>>>> The TLS protocol currently has the server send the client a
>>>> certificate. The client then just needs to look in DNS to find out if
>>>> the public key in the certificate sent by the server matches the
>>>> public key for the service in DNSsec. So bare public keys in DNSsec
>>>> should work.
>>> 
>>> You have yet to say how the TLS client knows what the public key is for the cert they get in TLS. This was discussed multiple times on the list, and (all?) the other supporters of bare keys have agreed that this is not a trivial thing to do, and have backed down from it. You haven't even addressed the issue. Instead, you keep coming back to "we want to do this in WebID".
>> 
>> Does the following sound ok, or am I answering a different question:
>> 
>> 1. TLS client receives cert from TLS server.
>> 2. TLS client extracts key from cert using normal x509 libs
>> 3. TLS client looks up hosname:port in DNSsec, and finds the bare key
>> 4. TLS client matches key found in 2 with the one found in 3
>> 
>> Is that the kind of thing I should send to the list?  I am not sure at which point the problem arises.
> 
> You can send it to the list, but as has been said on the list already, normal X.509 libraries do not let you extract the key. The few that do might have it in different formats, so doing a direct comparison is impossible. So it feels like the relevant part of your list, step 2, is not based in reality. If you can show me wrong, that's great, but if not, you posting the above list doesn't really help.

Ok. So at this point we are back to WebID.  I am speaking here of WebId only because we needed the same tools as you need in Dane. So we have some experience - not perfect - to go by.
   
  WebID  also requires the public key from the X509 certificate to be extracted. It needs to be extracted on the server (in Dane it will be on the client), and the certificate is the client certificate (in Dane it is the server certificate), but the tools to do that will be the same. 

  http://esw.w3.org/foaf+ssl has listed the many implementations of the above on servers for every widespread programming language. That is we have WebID working in perl, python, c, java, ruby(?), javascript, and others....  Now it is true that for php and javascript there was a lack of ASN.1 parsing tools, so people initially used opensso to parse the key, and extract the relevant information that way. Not very nice but we were trying to see if it works.

The Scala code which we can launch directly into the java SSL layer, and which is an OSGI component is here

https://svn.apache.org/repos/asf/incubator/clerezza/trunk/parent/platform.security.foafssl/core/src/main/scala/org/apache/clerezza/foafssl/ssl/X509TrustManagerWrapperService.scala

as you can see there getting the public key from the certificate is one line of code

    val publicKey = cert0.getPublicKey

In WeBID there is a reason to publish the "bare" public key in a web format such as XML, RDF, html, ... If one wants to put they key in HTML it makes more sense to put the key in a format where people can verify visually the correspondence with what their browser tells them. A big ugly PEM blob is just in my view too much of an eysore, and contains too much mystification.

This issue does not perhaps exist in the same way in DNS and so with DANE, as I think the format there is also quite old, and it is unlikely that people will be looking at DNS records without tools. I just don't know that aspect of DNS very well, so I may be wrong.

   I think that if there were java libs to do a DNSSEC lookup it probably would not be that much work to change the SSL layer reasoner to do a Dane lookup. 

	Henry

Social Web Architect
http://bblfish.net/

---

From: Stephen Kent <[email-masked]>
Date: Tue, 22 Feb 2011 19:56:55 -0500

At 10:17 AM +0100 2/22/11, Henry Story wrote:
>...
>  >
>>  I don't think that most users, who often can't even tell if they 
>>have contacted a TLS-secured site, would think of a public key as 
>>part of the identity for the service. I also don't think that most 
>>of them think about the port either.
>
>I was not speaking to most users but to this group of security 
>specialists during a discussion on a protocol. The public key is a 
>definite description that uniquely identifies the agent for the 
>purpose of computers, not for the general public.

The context you envisioned was not clear from your statement. a 
public key can be a UID for an object, but I'd hesitate to call it 
descriptive.

>...
>
>I am aware of symmetric cryptography's role. But it is public key 
>cryptography that is core in authenticating the server, and setting 
>up the symmetric crypto channel. Symmetric cryptography is used 
>because it is less cpu intensive.

I think it best to be precise when discussing what one would like
to see become a standard.

Steve