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

["Ryan Sleevi" <[e-mail]>]

On Mon, January 13, 2014 9:01 am, Kai Engert wrote:
>  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.)

If (c) is your goal, what, if any, advantages are there over RFC 6962? All
I can see are disadvantages.

Incorporating into TLS 1.3:
- Only provides herd immunity for clients that adopt TLS 1.3

CT protects all clients, past and present.

- Effectively requires online checking capabilities for TLS servers (about
legitimacy of reports), otherwise simply logging reports can become a DoS
vector.

CT allows offline processing, by either the server operator acting as a
log monitor, or - better yet, by outsourcing the work itself to a log
monitor.

- Requires adoption by server operators (in the hundreds of millions)

CT only requires the adoption of user agents (in the tens to hundreds) and
CAs - which, depending on your preferred counting metric (hi Phil!),
ranges from ~1000 or fewer.

The problem 9c) is one that CT is uniquely designed to address, so I don't
see the need for protocol changes to support an alternative reporting
mechanism, unless there can be demonstrated significant advantage. And I
don't think "saves CA's $X dollars" to be a significant advantage, when it
would require server operators spend "$(X*Y) dollars" to implement TLS 1.3
to kinda gain protection but only with clients and only if it's not a
state actor.