[tor-talk] x.509 for hidden services

[Gregory Maxwell <gmaxwell@xxxxxxxxx>]

==Background== (you can skip to the Tor section if you don't care)

The Bitcoin universe is in the process of creating a specification for
digital invoices called "the bitcoin payment protocol". (More info:
https://bitcointalk.org/index.php?topic=300809.msg3225143#msg3225143)

The payment protocol allows someone to request someone else pay
Bitcoin for specific things, instructing them to pay specific amounts
in specific ways, and allows the receiver to provide things like
instructions for sending a refund if the transaction is for some
reason aborted... all sorts of extra metadata which doesn't belong in
the public Bitcoin network for scalability and privacy reasons.

One of the things these invoices have is an optional signing mechanism
for authentication and non-repudiation. Normally these requests would
be sent over an authenticated and encrypted channel which provides
confidentiality and authentication, but not non-repudiation.

The non-repudiation will provide cryptographic evidence to the
participants which can be used to resolve disputes: e.g.

"He didn't send me my alpaca socks!" "Thats not the address I told you to pay!"
"He told me he'd send my 99 red-balloons, not just one!"  "No way,
that was the price for 1 red-balloon!"

The payment protocol is extensible and may someday commonly support
many kinds of signatures, but the initial implementations only support
signing with internal x.509 certificates and verifying those
certificates with standard CAs. As _horrible_ as this is, it's better
than nothing, and the primary users asking for this functionality have
SSL websites today.  We don't believe that any other PKI mechenism is
actually functional enough to be usable (e.g. as evidenced by the fact
that downloads of our GPG signatures, is on the order of 1% of the
downloads of the Bitcoin software; and probably only a small portion
of those users have actually done anything to verify the signing keys)
today, so other options haven't been a priority.

However, the need to use the known insecure CA infrastructure for this
(optional!) feature has seriously spazzed out some people. A lot of
this is pure confusion, e.g. people thinking that all payment requests
would have to go via the CA (no kidding!), but its surprisingly hard
to convince people who are responding emotionally of the subtle
tradeoffs involved especially when they have the luxury of saying
"it's your problem to go figure out, figure it out and go write a
bunch extra of software for me". So having some alternative on day one
would be useful in helping the more conspiracy minded understand that
this isn't some effort to cram the use of CAs down their throat.

==Where Tor comes in==

One of the downsides if using x.509 certs to non-repudiate here is
that sites hosted as tor hidden services can't participate.

It occurred to me that this could be fixed with very little code:

Take the HS pubkey, pack it into a self-signed x.509 cert with the
cn=pubkeybase32.onion.  And specify that .onion certs have a special
hostname validation rule that hashes and encodes the key.

Then the whole process would work for .onion, we'd have a non-CA
option available and working, etc.

I'm aware that HS pubkeys have been used for application level
authentication in Tor elsewhere (e.g. I believe torchat does this) so
it's not entirely unprecedented. I'm not aware of anyone packing them
in x.509 certificates. If anyone has, I'd like to use the same
encoding style for greater compatibility.

The biggest reason I can see not to do this is that it will not be
compatible with future editions of hidden services which aren't based
on RSA keys. (e.g. the EC point addition stuff to protect against
enumeration attacks wouldn't fit into this model). I don't think this
is a serious concern: if HS x.509s do become widely used we could add
a new authentication type for the new onion addresses when those are
introduced.

Does anyone else see any other reasons not to do this?

Are there other applications which would benefit from having x.509
certs for onion names?
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk