On Tue, 24 Mar 2015, Benjamin Kaduk wrote: > On Tue, 24 Mar 2015, Linus Nordberg wrote: > > > Benjamin Kaduk <[email protected]> wrote > > Mon, 23 Mar 2015 11:50:26 -0400 (EDT): > > > > | 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. > > > > Do you have suggested text? > > Any text I would suggest would be text that I am not entirely happy with, > since I do not have confidence that I correctly understand the security > and privacy considerations in question. > > Unfortunately, I left the copy of the document that I marked up at the > hotel, so I have to recreate my work and only remember one of the places > that tickled this concern (there were at least two): > > In section 3.1.1, """When the client later reconnects to any HTTPS server > for the same domain it again receives a set of SCTs. The client [...] > MUST send to the server the ones in its store that were not received from > that server.""" This precludes the client from doing any sort of MITM > detection and refusing to send SCTs to a (presumed) attacker. Admittedly, > the scope of exposure here is pretty small; it seems like the only privacy > loss would be that attacker A who has MITM'd the client then can learn > whether the client has *also* been MITM'd by attacker B at some point in > the past (since presumably the attackers know which SCTs are legitimate). > But, it is not too much of a stretch to think that three-letter > organizations might want to know if their target is being attacked by > someone else.
It looks like the other one was in 3.1.2, "HTTPS servers MUST NOT share any other data that they may learn from the submission of SCTs by HTTP clients". My immediate response to that statement was "what goes wrong if a server misbehaves?" Thinking about it now, it seems like the answer is "not very much, compared to a misbehaving server which does not implement CT", but confirmation would be nice. Maybe my response to this line of thought would be to remove the RFC 2119 language and just ensure it's in the security/privacy considerations, but it's probably not a big deal either way. -Ben _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
