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 | | 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 | > 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'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)? _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
