On 22 March 2015 at 21:51, Benjamin Kaduk <[email protected]> wrote: > First off, I have a general comment that there seem to be some places in > the document where it is implicitly assumed that the HTTPS client and > server trust each other to behave correctly and are "only" truing to > detect misbehavior by other parties (i.e., CAs or parties subverting the > CA infrastructure, etc.), to the exclusion of having the client and server > retain some level of distrust or sanity checking of each other.
If it is not clear, I think it should be made explicit that the purpose of CT gossip is to detect misbehaving CT logs - and nothing more. The purpose of CT is to detect misbehaving CAs. A misbehaving server is making itself vulnerable, so they have an incentive to behave. If a server misbehaves in collusion with a log, it will hopefully be detected by an HTTPS client sharing SCTs directly with an auditor (which is mentioned in a sentence in 3.1.2, and is a natural extension if a user _wishes_ to give up some privacy.) But this scenario also doesn't seem to make a lot of sense - why would a server collude with a log when it can achieve the same goal with significantly less work and less risk? > 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 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?) > 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. > What are the consequences if the server > misbehaves and shares "other data that they may learn from the submission > of SCTs by HTTP clients"? It would be a privacy violation of the client. > 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 -tom _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
