On Mon, 23 Mar 2015, Linus Nordberg wrote: > Tom Ritter <[email protected]> wrote > Sun, 22 Mar 2015 22:38:48 -0500: > > | > I'm not > | > sure that the client wants to always trust the server, given that the > | > scheme is positing a universe where some clients will sometimes > | > successfully connect to hostile servers supplied with fraudulent > | > certificates (that validate) by the attacker. > | > | The client is trusting that it will eventually connect to a behaving > | server and that a server is interested in detecting mis-issuance for > | itself. Another way to phrase it is that a client is not cordoned off > | for a given server once and forever, with no way to ever connect to > | the valid server again
I know that, and you know that, but we want to make sure that the document says that as well. Linus's suggestion below is a good start. But this is still not really addressing the issue I was trying to raise. Yes, the goal of this protocol is to enable a client and server to cooperate to detect misbehavior by third parties. But that does not absolve us of a responsibility to analyze the situation where one of the client and/or server misbehaves, and document the security and privacy considerations in that case. > | If it's not clear that the client does not empty it's SCT cache into a > | server and say "Okay, I'm all set" -then it should be made so. The > | client doesn't do that. It retains SCTs and reports them according to > | some unspecified UA algorithm. (exponential backoff plus > | randomization?) > > Branch sct-feedback of https://github.com/ln5/internet-drafts.git makes > an initial attempt at explaining this [1]. Improved wording is welcome! > > [1] > https://github.com/ln5/internet-drafts/commit/6310b87e826d0a6f650fa39532932d24176b7cbe That is helpful. Could we also add a paragraph to the end of the introduction motivating clients sending SCTs to servers due to it not presenting an additional privacy leak? Perhaps something like: """ However, there is no loss in privacy if a client sends SCTs for a given site to the site named in the SCT, since the site's access logs would already indicate that the client is accessing that site. In this way a site can accumulate records of SCTs that have been issued by various logs for that site, providing a consolidated repository of SCTs which can be queried by an auditor interested in that site (such as the site's owner itself). """ > | > In a related vein, in 3.1.2, should the server be allowed to exclude SCTs > | > that it considers legitimate? > | > | This is an optimization: if a server sends you SCTs A,B,C and then you > | as a client report back to it "I know about SCTs A, B, and C - it > | doesn't make a whole lot of sense for a server to report those to the > | auditor. > | > | I suppose; however, that an attacker may feed a server invalid SCTs > | somehow to 'load it's cache' such that it never reports them. So > | perhaps yes, it should report the SCTs it knows about to an auditor. > > I'm thinking of SCT's being legitimate as a "policy decision" made by > the operator and not something a piece of software decides. Does this > make sense? Should we add text to explain this? I guess I'm coming at this from the assumption that an auditor will want to know about all SCTs for a given site, including the "legitimate" ones. On the other hand, it could be useful for the site to have a way to indicate to an external auditor which SCTs it believes are legitimate. But it's not clear that omitting them from the results is the best way to make that indication, since it is not distinguishable from the site not knowing about those SCTs. In short, is the extra complexity of making this optional justified? > | > I'm also a little confused by the last paragraph of 3.1.2, "the selection > | > MUST NOT be influenced by potential HTTPS clients connecting directly to > | > the auditor". It seems like the only risk of allowing a client to request > | > monitoring for a given site is additional resource usage by the server > | > (assuming the client is aware of the privacy considerations of making such > | > a request). I suspect that there is a valid concern here, but the text as > | > written may be overly broad. > | > | It's designed to prevent the following traffic analysis: > | > | - Adversary is watching traffic of the auditor and client, and wants > | to learn historical client behavior > | - Client connects to an auditor and sends a bunch of SCTs over HTTPS > | - Auditor immediately goes and queries all the domains the client sent for > | - Adversary learns which domains the client sent in SCTs for > > Should we add text explaining this? Should explanations like this go > into "Security considerations", refering to appropriate sections (like > 3.1.2. in this particular case)? I think it would be fine to mention this in 4.1.2 (near "SCTs [are] sensitive data"). I still think it is possible for a properly-written auditor to add sites to monitor in a way which does not expose client information via traffic analysis (i.e., probabilistic/staggered/delayed queries), but I am willing to conced that getting it right is sufficiently hard that we should not be recommending it. -Ben _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
