On 21.10.2011 15:09, Kai Engert wrote:
This is an idea how we could improve today's world of PKI, OCSP, CA's.
https://kuix.de/mecai/
After more brainstorming I came up with some incremental ideas.
Thanks a lot to Adam Langley for pointing out scenarios that weren't yet
sufficiently handled by the design I had presented earlier.
(a) Need better handling for swapping certs in large deployments, in
particular, the need to create vouchers for new certs, while the old
certs are still being actively used.
(b) The requirement that servers constantly (at least daily) require
updated configuration appears impracticable for some environments.
(c) The proposal so far assumed that each server is aware of its own IP
address, and can use an appropriate voucher. But maybe that's not true?
Maybe we need something more flexible?
Proposed solution for (a):
Let's design the voucher-fetching protocol to use any port. The
initially described idea was, a server connects to the vouching
authority (VA), asks for a voucher, and the VA will call back, by
contacting the port in question.
This was based on the idea, a voucher should be port specific. I want to
move away from this proposal. Let's define that a voucher for hostname
A.B.COM can be valid for any port number at hostname A.B.COM
If a server is in possession of multiple valid certificates, it should
be allowed to obtain a voucher for each of them.
If A.B.COM is currently configured to use cert C-1, but plans to switch
to C-2 soon, it must be able to prepare by obtaining a voucher for C-2.
This can be solved, if the server can instruct the VA to contact a
secondary service/port on the hostname, e.g. 444.
While the primary port (443) still uses C-1, the service at port 444 can
be configured to use C-2.
The primary port is used for production, while the secondary port is
simply used to assist in the configuration update. It can be a minimal
service that shuts down the connection after the TLS handshake has been
completed (doesn't offer any application data).
Proposed solution for (b) and (c):
Instead of delivering the vouchers inside of the TLS handshake, let's
broadcast them using DNS!
I had this idea just two hour ago, and I currently think (hope) it
indeed solves several problems.
S-C-Hash: A hash of a server certificate.
VA-N-Hash: A hash of a Vouching Authority's subject name
A.B.COM: A server's hostname.
As explained in the MECAI documents, the operator of a server must
regularly fetch new vouchers from many Vouching Authorities. However,
with the DNS approach, it seems sufficient to do it just once per active
server certificate (not for each IP).
The domain owner will publish multiple DNS records, one for each
combination of {Server Certificate, Vouching Authority} of the following
form:
{VA-N-Hash}.{S-C-Hash}.A.B.COM => The Voucher
(which includes recent OCSP data)
In other words, the site can publish vouchers for both C-1 and C-2 in
parallel.
A client connects to the server and obtains the server's certificate.
Then the client will attempt to find vouchers in DNS, from VAs it trusts.
The client will require (e.g.) at least 2 fresh and valid vouchers,
which are issued by VAs that are unrelated to the server certificates
issueing CA, and it will require that each voucher chains up to a
different root CA/VA.
Also, this DNS approach helps to keep the size of TLS handshakes small,
and it increases the flexibility on the client side. The client can
continue to query DNS for vouchers until it has found a sufficient
number of vouchers it trusts.
This new variation of MECAI still requires daily updates for the
vouchers, however, they now live in DNS.
In environments where multiple servers host a single hostname, the
system that fetches vouchers and updates the information in DNS can be a
different computer than the one(s) running the production site.
The original idea is still: As soon as CAs/VAs are aware that a CA got
hacked, they can blacklist it and stop issueing vouchers. (Or more
easily, they will recognize that a cert is revoked because of
information found in CRL or OCSP).
As soon as the vouchers in DNS have expired, and clients are no longer
able to obtain a sufficient amount of vouchers, the compromised certs
can be treated as revoked. This is the slow scenario.
In the fast scenario, where no DNS manipulating hackers are involved, a
domain owner could contribute to quick distribution of revocation
information, by adding OCSP revocation data to DNS. Maybe we could
define that DNS entries like
{S-C-Hash}.A.B.COM => OCSP record (revoked)
I haven't researched, but has anyone already thought of distributing
OCSP records using DNS in general?
If we had OCSP-in-DNS, we might not even require OCSP stapling. This
could run as a service completely independent of the SSL servers - only
clients would need to be updated to fetch OCSP from DNS - does this make
sense?
However, even with OCSP available in DNS, we might still need something
like MECAI, in order to deal with the absence of OCSP information.
Kai
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
