On 22 October 2015 at 17:48, Daniel Kahn Gillmor <[email protected]> wrote: > On Thu 2015-10-22 06:23:35 -0400, Ben Laurie wrote: >> On Thu, 22 Oct 2015 at 03:16 Tom Ritter <[email protected]> wrote: >>> On 21 October 2015 at 08:52, Linus Nordberg <[email protected]> wrote: >>> > Impractical since the browser would have to know which domain that >>> > example.com has delegated its SCT Feedback to. >>> >>> This is an engineering problem I don't see a neat solution to. So >>> obviously the solution is a new HTTP header! SCT-Feedback: >>> >>> https://uncle-neds-discount-hanggliding-and-sct-feedback-correlator.website/google.com/ >>> ;) >> >> Quite so. > > I can't tell how much people are kidding around here -- i see Tom's > winky emoticon, at least. > > But which version of the site should get to declare where the delegation > should happen -- the version that has the bogus cert with SCTs from the > colluding logs, or the "real" version?
The header should not persist, it should be required to be present on every response to keep the delegation occuring. So assume the fake server sets it, and you give some SCT feedback to the delegated attacker. Later when you visit the site, and no longer see the header, you give SCTs to the real site. I don't think this changes the threat model, as we assume the attacker cannot forever-middle a user. I tend to like HTTP headers, but I do recognize there's a ton of them. On 22 October 2015 at 05:25, Ben Laurie <[email protected]> wrote: > On Thu, 22 Oct 2015 at 03:16 Tom Ritter <[email protected]> wrote: >> >> I can't >> think of a way you receive (no-maliciously) an older-then-three-week >> STH. > > You can end up with one if you receive a fresh one and then go to sleep for > 4 weeks... That's true. It seems different from the client receiving a 4-week old STH via the network though. If you start up and have a 4-week old STH in your store - you can presume that you recived it when it was fresh. And if you cannot resolve with a consistency proof - it seems 'safer' to me in some way. If you receive a 4-week old STH from a site, I might assume they're trying to load me with a tracking STH. But in general we're back in the bucket of "What do I do with this." Do we share it with websites via STH Pollination even though it can enable very reliable cross-origin linkage? I don't think we can, because (besides the privacy issue) we don't want to require the website to resolve consistency proofs nor do we want the website to give 4-week old STHs to other clients. Do we share it with an auditor-of-last-resort (after failing to resolve a consistency proof), thinking that the privacy implications of a STH are much lesser than the near-certainly of cross-origin linkage? -tom _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
