My notes on several comments in thread: ==================================
I want to add to this part: On 15 March 2016 at 09:57, David A. Cooper <[email protected]> wrote: > If there is an attack here, it seems that it would be as follows. Upon > detection of the bogus certificate browsers determine that the subordinate > CA is malicious and blacklist the cross-certificate from trust anchor 1 to > subordinate CA, but don't blacklist any of the EE certificates issued by the > subordinate CA (and the subordinate CA doesn't revoke them either). The > browsers don't notice that there is a second cross-certificate for > subordinate CA, from trust anchor 2, and so there continues to be a valid > certification path for certificates issued by subordinate CA. This is correct, but there is another attack, one I consider more damning, new fradulent intermediates that the community 'doesn't care about' because the issuer has been removed from trust stores. This isn't mentioned in the text present. Attacker issues intermediates A_X and B_X from CAs A and B that are identical. They issue an end entity cert EE1, signed by *_X (doesn't matter who signs it, the signature is identical.) They Log A -> A_X -> EE1, and get SCTs for EE1. EE, A_X, and A are revoked and blacklisted. Attacker issues a new intermediate A_Y and B_Y from CAs A and B that are identical. They issue another end entity cert EE2, signed by *_Y (again, doesn't matter who signs it) They log A -> A_Y -> EE2, and get SCTs for EE2. A_Y is *not* blacklisted, because the path we see in the logs is not trusted. People decide they don't care. The attacker can use B -> B_Y -> EE2 with the SCTs for EE2 to perform attacks. ================================== On 14 March 2016 at 17:15, Rob Stradling <[email protected]> wrote: > 2. Declare that this is not a problem with CT. It's a problem with using > CRL and/or OCSP to revoke intermediates. So we (where "we" may or may not > be TRANS) need to fix revocation! > Revoking an intermediate _certificate_ just isn't sufficient. > To be effective, the intermediate _public key_ needs to be revoked somehow. I agree with this, except not just intermediates. Revocation should be done by either the public key or the certificate everywhere (intermediates and end-entity.) But practically, because of CA operations, I think it makes sense to revoke by public key for intermediates and by certificates for end-entity. That said, it's a bit beyond our mandate to redo revocation for the whole internet.... ================================== On 15 March 2016 at 08:50, Ben Laurie <[email protected]> wrote: > > 3. Always revoke bad certs that appear in logs! That revocation would need to be via crl-sets or OneCRL. So while this... could work: If I'm the smart attacker I'm going to spam the everloving shit out of the log with bad certs. And when you have to revoke 1 million certificates via crl-sets you will be sad. =) So.... ================================== On 15 March 2016 at 08:51, Ben Laurie <[email protected]> wrote: > Oh, also: > > 4. Require SCTs for all certs in the chain, which prevents hiding the > alternate intermediate. I think this is the answer. I think we need SCTs for all the certs in the chain. And yea, I think we need to mandate this. But how? It's a huge change right, it's going to be some time before Intermediates are issued as PreCerts. So there'll probably need to be a bandaid for the time being. The only thing I can think of is using Mozilla's Intermediate database and hardcoding a few kilobytes of SCTs into browsers. Ugly but... could get most of the way there? ================================== I'll also note that right now we (Gossip authors) don't want to make defending against this attack one of Gossip's responsabilities. But we can defend against this attack in a certain configuration. We have some in-progress text I wrote this morning about it, but it is in-progress. https://github.com/ln5/draft-ietf-trans-gossip/pull/16/files -tom _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
