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

From: Kai Engert <[email-masked]>
Date: Fri, 10 Jan 2014 17:39:07 +0100

I would like to suggest a potential improvement for the TLS protocol.

The intention is to make it more difficult for an adversary to act as a
MITM, by using the abilities of a CA to obtain a valid certificate, that
isn't controlled by the real owner of a TLS server.

This message presents the ideas that I had today as a draft.

The proposed enhancement consists of two parts.

(1) TLS Clients should cache the most recently seen and sucessfully
validated (accepted) server certificate for each hostname.

When a client connects to the server again at a later time, and notices
that the server sends a certificate that is different from the one that
has been cached, and in addition the new certificate has been signed by
a different CA certificate, then the client should report the previously
cached certificate back to the server, using a new TLS protocol message.

This way, the owner of a TLS server could learn if any users have
visited a MITM server that impersonated the server using certificates
that aren't controlled by the real owner of the domain. This could be
automated on the server side. A list of previously used and valid
certificates could be installed on the server, and any reports with
known good certificates could be automatically ignored. Also, in order
to ignore any certificates that belong to closed environment CAs, the
server could ignore reports of certificates that cannot be validated
using a chain to known public CAs.

Should a server operator learn that a CA has falsely issued a
certificate, the certificate can be publicly reported and a public
investigation could be started.

This proposal is based on the idea that temporary and targeted attacks
to users are possible, and attempt a way to detect them. If it's correct
to assume that a non-zero percentage of all targeted attacks are
temporary, then attacks could automatically become known once the
temporary attack is over and the client connects to the real destination
server again.

While this reporting cannot immediately protect TLS clients from being
tricked into accepting a falsely issued certificate, it could at least
help to detect the CAs that are involved in enabling such targeted
attacks. Such public knowledge could be helpful to prevent such attacks
in the future, by removing such CAs from the embedded trust lists used
by TLS client software.

(2) TLS clients should require key continuity.

TLS Clients should cache the most recently seen and sucessfully
validated (accepted) server certificate for each hostname.

When a client connects to the server again at a later time, and notices
that the server sends a certificate that is different from the one that
has been cached, and in addition the new certificate has been signed by
a different CA certificate, but the previous certificate hasn't expired
yet, then the client should perform a key continuity check by requiring
a proof of ownership of the previous key.

The idea is, if a TLS server administrator has chosen to switch the
server configuration to a new certificate, the server administrator can
be assumed to still be in possession of the private key that was
associated to the previous certificate.

How could the proof-of-ownership of the previous key look like? Maybe
it's better to talk about proof-of-legitimate-transition.

A data format could be defined, which consists of a simple data
structure that contains the new certificate, plus a digital signature
that was created by using the private key that belongs to the previous
certificate.

Since a server could have used multiple certificates in the past that
haven't yet expired, the server should be able to store multiple
proofs-of-legitimate-transition. The server would send the correct one
to the client, based on the certificate the TLS client reports as most
recently seen.

Using this strategy, it would no longer be sufficient to attack any
other CA (a CA that is different from the one used officially by the
server operator), as the attacker would require to obtain the server's
current private key, too.

I can think of a scenario where creating the proof wouldn't be possible,
for example, if domain ownership has changed. In that case, the CA that
had issued the previous certificate should revoke the certificate. The
new owner of the domain should be able to convince the CA to revoke the
previous certificate, by presenting current domain ownership documents.
Once this has been done, an OCSP response (or a CRL) could be obtained
from the previous CA that proofs revocation. If a TLS client reported
the mismatching certificate to the server, the TLS server could staple
the OCSP message with the revoked status into the TLS handshake, using a
new TLS message. This could be allowed as a sufficient
proof-of-legitimate-transition. Clients should accept an old OCSP
message of status revoked (regardless of its age), therefore allowing
the TLS server to cache this proof of transition forever.

I hope these ideas make some sense. I'm sure there are edge case which I
haven't covered yet. I'm looking forward to your feedback and hope that
we might be able to find incremental tweaks to these ideas to make them
work in general in a future version of TLS, such as TLS 1.3.

Best Regards
Kai

---

From: Alyssa Rowan <[email-masked]>
Date: Fri, 10 Jan 2014 19:19:31 +0000

On 10/01/2014 16:39, Kai Engert wrote:

> (1) […IF (new_certificate) THEN send_warning(new_certificate)…]

I applaud the motive, but I'm not sure about the delivery.

Three potential problems I can see with an in-band new-certificate
canary.

Firstly, it relies on TLS clients caching certificates, like SSH
clients; they have not traditionally done this. I'll let those who
write clients chime in on why they may or may not want to.

Secondly, if the server does change certificate legitimately, it's
going to get a lot of these warnings from everyone. That could get
annoying.

But thirdly - and most importantly - if an adversary is in a position
to be a man-in-the-middle and actually use their fake CA certificate,
they're also in a position to read your draft, know exactly what the
new-certificate canary looks like - and make sure the server never
gets it by filtering it out or injecting a RST to the server. And that
is probably exactly what they'll do, because they do it already
(“QUANTUMRESET”) and it's a very, very easy attack; much easier than
getting a forged certificate.

Sorry, I just don't think it would work.

An out-of-band approach would be harder to disrupt and more
successful, like the SSL Observatory type things we already have, and
Certificate Transparency public audit log rules for CAs (which I
personally think should be strictly enforced as a minimum bar for any
CA remaining in browsers, although some CAs are apparently reluctant
to do this, so that may not be too easily forthcoming in the immediate
future).

I think some browsers might already do this: Chrome, perhaps?

> (2) TLS clients should require key continuity.

As above - requires caching - but I'll let those who write clients
chime in on this one.

Would need a "I'm Z, old key X, new key Y" statement signed by old key
X, yes.

Obvious edge cases that leap out at me:—
• Old key X expired first. Oh-so-common.
  - Do we still trust its assertion?
• We don't have old key X. As you say, needs stapling of revocation.
  - But how many historical keys are we going to have to staple?
  - What if this domain changes hands a lot?
• New key Y has a problem, e.g. isn't on the OCSP lists yet.
• Old key X is revoked, but OCSP is unreachable and not stapled.
• Z is large, does DNS round-robin or anycast and has huge load
  balancers all over the world with different keys [X₁, X₂, X₃, X₄…].
  - Forcing them to have the same key seems even _worse_.
    Now someone can swipe the key from any load balancer and look like
    every one.

Needs some thinking through. It may or may not be a good idea, but
there are certainly a few potential complications.

- -- 
/akr

---

From: Kai Engert <[email-masked]>
Date: Fri, 10 Jan 2014 20:51:22 +0100

> write clients chime in on why they may or may not want to.

Thanks for considering the client side, I'll add some thoughts as well.

I agree there might be clients that wouldn't want to implement a cache,
because they don't save a state. Or they might not want to update a
cache when operating in a mode that intends to avoid local caching
("private browsing mode"). I think that's fine.

Even if the most popular TLS clients, like browsers, e-mail agents and
vpn clients were the only TLS clients that implemented the canary
reporting, I believe it would still be beneficial.

(Browsers in a "private browsing mode" could recommend to the user that
they are operating with reduced web security checking. OTOH, if a user
runs in private browsing mode, but a previous server certificate has
already been cached from regular browsing, it could be considered safe
to update the local cache, as it wouldn't creating additional leaks).

> going to get a lot of these warnings from everyone. That could get

That's why I'm suggesting that server software should have a
configuration option, which allows to configure a list of allowed
certificates. That list would contain the previously used certificates
for the given hostname. The server could ignore any reports with those
certificates.

> gets it by filtering it out or injecting a RST to the server.

Yes, the canary reporting cannot prevent an attack. But I assume that
most attacks are temporary. I assume that eventually most clients will
be able to use a direct route to the real destination, without being
attacked. For example, after they are back from travelling or from using
a WiFi hotspot, or if they are able to use a VPN occassionally. Or it
they connect to the neighour's wifi, instead of using their own fixed
DSL line which has been hacked. Or if they switch between a DSL line
with an active MITM and a 3G connection that is free of MITM.

>  And that
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Kai Engert <[email-masked]>
Date: Fri, 10 Jan 2014 20:54:47 +0100

Sorry, I accidentally hit a key combination that sent the message, prior
to me finishing the message.

I need to continue the message and address the remaining parts of your
message.

Regards
Kai

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Jan 2014 12:12:38 -0800

These ideas (and the followups from Alyssa) are interesting, but I suspect that they belong in the websec WG instead of here, unless you truly mean them to apply to every application that uses TLS. I don't see how they would work, for instance, with SMTP servers that do TLS.

--Paul Hoffman

---

From: Kai Engert <[email-masked]>
Date: Fri, 10 Jan 2014 21:28:39 +0100

On Fr, 2014-01-10 at 12:12 -0800, Paul Hoffman wrote: 
> These ideas (and the followups from Alyssa) are interesting, but I
> suspect that they belong in the websec WG instead of here, unless you
> truly mean them to apply to every application that uses TLS. I don't
> see how they would work, for instance, with SMTP servers that do TLS.

I'm motiviated to find ways to makes these ideas work with any TLS
connection, completely independent of the encapsulated application
protocol.

I think a SMTP/TLS client could equally cache the previous cert and
potentially report it to the TLS server on a subsequent connection.

Where do you see differences that would cause it not to work with
protocols other than http?

Regards
Kai

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 10 Jan 2014 13:18:09 -0800

Hi Kai,

Have you seen TACK?  It does something similar but with self-managed
signing keys, and has good procedures (IMO) for handling key and cert
changes and pin lifetimes.

http://tools.ietf.org/html/draft-perrin-tls-tack-02
http://tack.io/

Paul is correct there's more discussion about pinning on websec.  But
I agree with you this approach should be applied to SMTP, IMAP, etc.

I'll also note that the bottleneck for ideas like this isn't IETF
acceptance, but rather browser willingness to spend effort on
experimental proposals (there are sites interested).

Most browser experimentation in this area is going into CT at the
moment, it seems to me.

Trevor

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 10 Jan 2014 16:32:06 -0500

> This message presents the ideas that I had today as a draft.

this sounds like it covers similar ground to the TACK proposal:

  http://tack.io/
  https://tools.ietf.org/html/draft-perrin-tls-tack-02

TACK permits sites to opt into this sort of key continuity
infrastructure, though, rather than assuming a global key continuity
policy that all servers may or may not be able to meet.

As a thought experiment, do you think including TACK as a part of TLS
1.3 would meet the goals you're trying to achieve here?

	--dkg

---

From: Kai Engert <[email-masked]>
Date: Fri, 10 Jan 2014 23:22:42 +0100

This message replaces my earlier incomplete message.

> gets it by filtering it out or injecting a RST to the server.

Yes, the reporting cannot prevent an attack, that isn't the purpose of
the reporting (but might potentially be achieved when combined with 
the second part of the proposal).

I assume that most attacks are temporary and that eventually most clients
will be able to use a direct route to the real destination, without being
attacked. For example, after they are back from travelling or from using
a WiFi hotspot, or if they are able to use a VPN occassionally. Or if
they connect to the neighbour's wifi, instead of using their own fixed
DSL line which has been hacked. Or if they switch between a DSL line
with an active MITM and a 3G connection that is free of MITM.

Unless an individual is specifically targetted by an adversary who
has the resources to MITM absolutely all connectivity options at all 
times, the TLS client should eventually be able to succeed in submitting
the report.

For this part of the proposal, the intention is to make it likely that
most abuse of CA capabilities will eventually get noticed.

> getting a forged certificate.

Sorry, I don't understand this part of the argument.
Where can I read more about "QUANTUMRESET"?

> I think some browsers might already do this: Chrome, perhaps?

An out-of-band channel can be more easily blocked without consequences.

Browsers don't want to block primary connections with an error message,
just because an out-of-band check failed. That's why as of today, 
browsers continue to accept TLS server certificates despite 
connectivity failures, when attempting to check status using OCSP.

Querying the SSL observatory is expensive (latency), adds a single point
of failure (if a successful result becomes mandatory), and it's still 
difficult to make an automatic decision whether a certificate is the
right one (for example, if a server uses multiple different certificates
based on client's cryptographic capabilities).

The reporting I have suggested doesn't depend on a centralized
infrastructure, nor out-of-band connections, and might still help to
gain more trust in CAs (or find out which ones aren't behaving as
expected).

>   - Do we still trust its assertion?

It could become a best practice that updated certificates get rolled
out to servers a few weeks prior to certificate expiration,
that way most regularly connecting clients would roll over to the
new key in time.

If the old cert has really expired, I wouldn't require an assertion.

Note the key continuity check is proposed as an additional check on
top of regular certificate validation.

In order to abuse this gap, a MITM would still have to have access
to falsely issued certificate and would have to carefully wait until
the current certificate expires, without intercepting any connections
while the old one is still valid, but intercepting all connections
immediately afterwards.
That's probably quite tricky, and it's not sure how many MITMs would
be sufficiently patient to wait until this gap attack works.

I agree there might still be some MITMs who were willing to wait for 
the gap, but the server administrator can minimize this risk by rolling
out the replacement certificate early. 

>   - What if this domain changes hands a lot?

We only need to staple one revocation, the one for the certificate
that the client reports as having cached.

The server must keep a list of all old certificates and a revocation
statement for stapling for each of them.

I proposed to do without key continuity check if the CA remains the
same. The new domain owner would have to get a certificate from the 
same CA, and would have to stay with that CA, as long as the previous
certificate hasn't expired yet. This helps to confirm that the
certificate is double checked, as the CA has contact records for
the previous owner of the domain.

On top of that, as a last resort, TLS Clients would probably offer 
a mechanism to allow the user to "connect anyway", despite the 
failed key continuity check, just as with certificate errors, so 
there's a way out of this situation for this special case where 
one domain changes a lot.

(The TLS client should use a new kind of feedback message, that
informs the client that ownership of the domain has very likely
changed, and to only proceed with the connection if the 
change of domain ownership is known/expected.)

> • New key Y has a problem, e.g. isn't on the OCSP lists yet.

I don't see a problem with that as part of this proposal.
Requiring strict and general availability of fresh OCSP
information is a separate decision. In order to pass the key
continuity check, I don't suggest to require OCSP.

When I previously talked about having a OCSP status message
available to proof the revocation of a previously seen certificate,
that was meant as a special situation where this information
is mandatory, but I don't require stapled OCSP data in general.

Since the proof I have asked for (satisfied with a OCSP message)
would be related to a previous certificate (not the one used
for the current handshake), this exchange would have to be 
separate from the general OCSP stapling protocol anyway.

> • Old key X is revoked, but OCSP is unreachable and not stapled.

If OCSP is unreachable and OCSP isn't stapled, then the TLS client
doesn't know that X has been revoked.

If the client expects X, but sees Y, the certificates have been
issued by different CAs, and no key continuity proof is presented 
by the server, then fail the certificate validation.

The TLS client should warn the user, show appropriate warnings and
explanations (just as with other certificate validations today).

TLS client could give the user a mechanism to proceed anyway.

>     Now someone can swipe the key from any load balancer and look like

Use certificates from the same CA on all systems.
If you need to transition to updated certificates, no problem as long
as you keep using the same CA. If you switch to a different CA (or if
you decide to transition to a different CA, prepare the proof using 
the previous key, and install on servers.

The primary purpose of the proposal is to detect falsely issued 
certificates from an unrelated CA. (If the CA you have chosen cooperates
with the adversary, we would need a different idea to detect that.
I'll keep brainstorming on that.)

> there are certainly a few potential complications.

Thanks for your helpful feedback. I'm looking forward to additional
thoughts.

Regards
Kai

---

From: Ralph Holz <[email-masked]>
Date: Sat, 11 Jan 2014 00:14:25 +0100

Hi Kai,

I am not sure what "real" attacker you are adressing, 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? 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?
Finally, what is the server operator expected to do with this
information, and how is it signalled to him?

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)

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

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Jan 2014 16:33:29 -0800

> connection, completely independent of the encapsulated application

OK, that would be likely to make it part of the TLS WG then. As others have noted, the folks in the websec WG have discussed these issues already and are considering some of them for HTTP-over-TLS.

> potentially report it to the TLS server on a subsequent connection.

I'm still wondering about what you are proposing for failures in key continuity.

> protocols other than http?

You don't say so explicitly, but I'm imagining that you will later add "and if the key continuity fails, don't set up a connection". This completely bolloxes using TLS for opportunistic encryption, which is the common way to use it in SMTP/TLS. It could work in a user-sitting-in-front-of-an-application scenario like HTTP and IMAP, but not SMTP and others that basically use opportunistic TLS.

--Paul Hoffman

---

From: Watson Ladd <[email-masked]>
Date: Fri, 10 Jan 2014 16:36:36 -0800

> You don't say so explicitly, but I'm imagining that you will later add "and if the key continuity fails, don't set up a connection". This completely bolloxes using TLS for opportunistic encryption,…

We need to move to a world with no more plaintext. If someone is doing
tricks in DANE, TACK will catch them. Opportunistic encryption is
no encryption, even without MITM: a forged RST gets the plaintext.
Putting TACK into TLS is a big step towards that goal.
Sincerely,
Watson

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Jan 2014 17:34:10 -0800

On Jan 10, 2014, at 4:36 PM, Watson Ladd <[email-masked]> wrote:

> We need to move to a world with no more plaintext.

Exactly right. That's why many SMTP servers use TLS in opportunistic mode. 

> If someone is doing
> tricks in DANE, TACK will catch them.

If someone is "doing tricks in DANE", then DANE was not designed correctly. You should definitely bring those design errors to the DANE WG.

> Opportunistic encryption is

It does? I thought it gets the connection restarted, and TLS will get set up again.

> Putting TACK into TLS is a big step towards that goal.

If your goal is to kill off opportunistic encryption, yes. I didn't get the feeling that was Kai's goal with his proposal.

--Paul Hoffman

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 10 Jan 2014 19:14:59 -0800

> If someone is "doing tricks in DANE", then DANE was not designed correctly. You should definitely bring those design errors to the DANE WG.

I'd guess he's talking about trust failures, such as your TLD signing
a bad key for your domain.

But having a second security check like pinning could also backstop
design flaws we're unaware of, or software flaws in validating DNSSEC
or certificate chains.

> It does? I thought it gets the connection restarted, and TLS will get set up again.

Let's all agree that opportunistic encryption is valuable, and adding
authentication is even more valuable, and move on.

> If your goal is to kill off opportunistic encryption, yes.

Ouch!  Man, that's not true.

TACK gives you a pinning check that could co-exist with another system
(Web PKI, DNSSEC) or could be added to opportunistic encryption.

I think your concern is for MTA-to-MTA SMTP where there's no user to
"click through" pinning errors due to operator screwup.  Instead,
you're assuming the connection would hard-fail, and mail flow would be
interrupted.

"Report-only" handling of failures would probably be better.  I.e.,
the sending MTA would notify its administrator if mails were delivered
to a recipient MTA which had a pin validation failure.

Anyways, interesting topic and more could be said.  Perhaps the UTA
list is a better place for application-specific discussion of
TLS-layer pinning?

Trevor

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Jan 2014 19:48:29 -0800

> design flaws we're unaware of, or software flaws in validating DNSSEC

Again, my question is whether such checks have value in scenarios where there is no user sitting there looking for warnings.

> authentication is even more valuable, and move on.

I would love to, but you can take that up with Watson.

> Ouch!  Man, that's not true.

Sorry, I was unclear. Putting TACK into TLS in a way that would force user interaction when there were warnings would help kill off opportunistic encryption, which is what Watson says he wants. Putting TACK into TLS-for-HTTP will make key-substitution attacks more obvious to the browser user, if the browser vendors put it in and figure out the GUI for it.

> to a recipient MTA which had a pin validation failure.

Yes, definitely. Having TACK, or whatever Kai was initially suggesting, appear in SMTP security logs is probably a good thing.

> list is a better place for application-specific discussion of

Kai's suggestion was for a feature that is built into TLS; that would be the purview of this WG. If it is application-by-application (and not just web browsers), it would be uta; if it is web browsers only it would be websec. Whee...

--Paul Hoffman

---

From: Kai Engert <[email-masked]>
Date: Mon, 13 Jan 2014 16:44:54 +0100

> Where can I read more about "QUANTUMRESET"?

In the meantime I've learned what this is about. It's a mechanism to
implement MITM on a connection.

I believe your point is, it doesn't matter which pysical connectivity
option a client uses to connect to the Internet - because the adversary
doesn't need to manipulate connections close to the victim, but rather
could enforce that MITM remains always active for a particular client.

I agree, for state level attackers who can manipulate the Internet
backbone, this could block the ability of a victim to report a falsely
issued certificate to the real server.

Question is, is the quantum server really sufficiently reliable enough
to be active at all times, no expections? For each victim, a onetime
glitch or downtime would be sufficient to get the false certificate
reported.

Kai

---

From: Kai Engert <[email-masked]>
Date: Mon, 13 Jan 2014 16:56:25 +0100

> glitch or downtime would be sufficient to get the false certificate

Replying to myself, a few additional comments on that:

If a powerful adversary used QUANTUM* to implement MITM widely, for many
clients, using a falsely issued certificate, the adversary risks
detection. For example, I have proposed the http://detector.io project,
where I encourage all operators of TLS servers to monitor their own
server for an unexpected certificate, by connecting from elsewhere, for
example, by making use of the capabilities of the existing Tor network.

The ideas presented in this particular mailing list thread focus on the
idea that most MITM attacks wouldn't be executed broadly, because of the
high risk of detecting the falsely issued certificate. Rather, I focus
on targetted attacks, which involve only clients of a very small subset
of the network.

When targetting only a small subset of a network with MTIM, I think it's
likely that eventually the client will be able to connect around that
network, either caused by a roaming client, or by a temporary downtime
of the MITM attack, which would be sufficient for reporting the false
certificate as I'm proposing here.

Kai

---

From: Kai Engert <[email-masked]>
Date: Mon, 13 Jan 2014 18:01:54 +0100

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

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.

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

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

> as long as that first contact was secure.

I'll comment on this and TACK separately.

Regards
Kai

---

From: "Ryan Sleevi" <[email-masked]>
Date: Mon, 13 Jan 2014 11:06:38 -0800

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