Re: [TLS] Ideas for TLS 1.3: Server key continuity and certificate reporting

[Kai Engert <[e-mail]>]

On Sa, 2014-01-11 at 00:14 +0100, Ralph Holz wrote: 
> I am not sure what "real" attacker you are adressing,

During many informal chats, people have repeatedly told me, they have no
trust in certificate authorities (CAs).

I accept the fact that (as of today) we need trusted third parties to
make Internet security for the masses of users simple. Nevertheless, I'm
worried, too.

The speculation that some CAs might be willing to issue false
certificates for MITM purposes might be true. I would like us to
implement technology that allows to confirm or to negate the
speculation.

There are three possibilities:

Speculation (a) All CAs issueing certificates for the public Internet
are trustworthy. None of them would ever sign a false certificate. If it
happens, it was an accident, and such certificates get immediately
revoked, and all private keys are immediately destroyed, to ensure that
nobody could abuse the certificates with clients that don't do strict
revocation checking.

Speculation (b) All CAs issueing certificates for the public Internet
might secretly issue false certificates for MITM purposes for one
motivation or the other, for example if they are being compelled by the
government or other powers related to their place of operation, or
because of blackmail or corruption or undercover agents within their
organization.

Speculation (c) Neither (a) nor (b) is true. Rather most are
trustworthy, but some might secretly issue false certificates.


The certificate validation that is usually combined with TLS relies on
the assumption that (a) is true.

If everyone of you agreed that (b) were true, we could drop my reporting
proposal, but we would also have to stop using TLS immediately, and
design a system that enforces multiple assertions from different parties
and technologies prior to trusting any TLS connection.


My proposal is based on my opinion that (c) is the most realistic
speculation.

If we were able to identify all CAs that might issue false certificates,
we would be able to remove them from all software that ships with a list
of trusted CAs.

My proposal to introduce a reporting mechanism for server certificates
is intended to identify all CAs that aren't trustworthy.

(My second proposal to introduce key continuity checks was a quick
follow up idea, which could be dropped independently, if it turned out
as not working as described.)


> and if this static kind of pinning is really helpful.
> 
> On (1):
> 
> First, I have a suspicion that certificates may change relatively fast,
> and CAs change too fast for pinning against the CA, too -- or at least
> that is how I understood two colleagues of mine who investigated this.
> 
> Second, on (1), reporting a cert: you assume a temporary attack, but how
> is the client to find out if the attack is over?

For the reporting part, the client wouldn't attempt to make a decision
whether it's an attack or not. It simply reports the previously seen
certificate to the server.


> Is it supposed to
> report the suspicious cert on every connection attempt until it
> re-encounters the old cert?
> But what if the change was legitimate?

If current cert is different from previously seen valid cert, then
report the previous cert to the server.

Only if the current cert can be validated, forget the previously seen
cert and update the local cache using the new valid cert.

This means, with most servers, a report will usually be sent only in a
few scenarios.

However, if a cluster of servers uses multiple certificates at the same
time, and the client randomly sees one of multiple certificates with
each connection, change reports will be sent frequently.


> Finally, what is the server operator expected to do with this
> information, and how is it signalled to him?

The server must have a list of all currently used certificates (local
configuration, public part only). This is the list of known and expected
certificates.

All reports of certificates contained in the known list are
automatically and silently ignored on the server side.

If the server receives a report with a certificate that isn't contained
in the know list, then the server attempts to perform a standard
certificate validation (like client software would do). If the
certificate appears valid, it's worthy to report it to the server
operator.

Only falsely issued certificates should pass the filtering.

Signalling should be implemented by TLS server software in any way
appropriate. Logfiles, local email, whatever the software wishes to
support for reporting server software failures might work for this kind
of alert, too.


> A further thought comes to mind -- couldn't I spam the system by
> reporting rogue certs to servers all the time? (This is a problem that
> we also faced with Crossbear)

A public facing TLS servers will require protection against DDoS attacks
anyway. The need for having to validate a reported certificate as part
of a client connection would increase the load for each attacking client
connection slightly, but that's about it.

If the reported certificate cannot be validated (because it was really
just a DoS attempt, not a falsely issued certificate), the server can
simply proceed with the regular countermeasure to block attacking client
connections (e.g. standard rate limiting of connection attempts by IP
address, etc.).


> > (2) TLS clients should require key continuity.
> 
> What you propose here is a kind of life-cycle management for pins. Are
> you familiar with TACK by Trevor and Moxie? Their scheme does
> essentially this and provides for key roll-over, both legitimate and due
> to compromise. The core idea is not to pin against the TLS key, which is
> subject to change, but to a domain key, much in the style of Sovereign
> Keys. It also provides for roll-over of the domain key. I think your
> ideas are pretty much covered by TACK.
> 
> For the record, should the IETF make a move towards adopting TACK as
> part of TLS, I'd be happy to see that. I think one of TACK's greatest
> strengths is that it is immune even against a globally acting attacker
> as long as that first contact was secure.

I'll comment on this and TACK separately.

Regards
Kai