On Mon, 13 Jun 2016 10:55:07 -0400 Stephen Kent <[email protected]> wrote:
> Andrew, > > > > > ... > > I would much rather the attack be fixed (I described one possible > > fix) than merely describing it in the threat document. Is this not > > an option? > Not for me to say. But I agree that the issue you cited is troubling. > > ... > > No, even if a monitor has access to full cert data, they aren't > > maximally useful when redaction is used (I consider this > > unexpected). If a monitor is configured with: > > > > www1.example.com should have key A > > www2.example.com should have key B > > > > and it sees a pre-cert for ?.example.com using key A, it can't > > say for certainty whether this is OK, because the pre-cert might be > > for www1.example.com, or it might be for www2.example.com. > > draft-kent-trans-monitor-auditor-01.txt says to accept the pre-cert > > in this case, which makes it possible to launch the attack I > > described. > > Yes, a Monitor serving www1 would think the log entry was OK, > even though it also would match www2. But, this requires that www2 > has the same key as www1. If there was a compromise of www1, then > I agree that a Monitor would not detect the compromise, but a > Monitor isn't really intended to do that. Alternatively, www1 could be operated by a third party who holds the private key (not an uncommon scenario). I think a Monitor should be expected to detect an attempt by that third-party to misuse their key to impersonate www2. > If this represents collusion > between www1 and www2 then this is good example of how colluding > Subjects could use an SCT issued for one Subject with a cert for > another Subject, because of the properties of redacted certs. Got it. It doesn't require collusion between the subjects. Rather, one subject colludes with the CA to attack the other subject. Regards, Andrew _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
