On 2016-06-12 at 15:53 +0200, Julien ÉLIE wrote: > Hi Ángel, > > First of all, thanks for your valuable comment. I will take it into > account in the wording of the draft. >
Hello Julien You are welcome > I understand the scenario. > It implies here that the client will have to know somehow what kinds > of newsgroups or articles need extra-security. The client will have > to send the right COMPRESS commands at the right time. Yes. Take into account that often only the client will be able to know if the newsgroup contents are deemed confidential by the user or not. > Wouldn't it be better that the server also knows somehow what kinds > of newsgroups or articles need extra-security, and clears the > compression dictionary even if not explicitly asked by the client? Of course, the server MAY flush the compression dictionary more often than required to satisfy some security properties (assuming that's supported by the algorithm). > We could otherwise have a situation where not all the clients > accessing secret articles are correctly configured. Therefore, one > of the clients may leak information. If both the client and the > server ensure not to compress public and confidential data together, > it would be better, wouldn't it? No objection to that. > Hmm, on second thoughts, this suggestion of a None algorithm and > allowing to switch to another algorithm at any time adds complexity I expect it isn't too much. It's basically the same operation of switching into compressed or encrypted. Moreover, it's easier to verify that the compressor is properly flushed, as the state is completely reinitialised. > that could be avoided by another suggestion: if a client wants to > access both public groups and secret articles, why not open two > separate NNTP connections (either in parallel or one after the > other)? These two sessions can be compressed, and there will be no > leakage. You are sending a stronger signal to someone that was watching the connection, as he will be able to see the two connections. Plus, that requires more server resources (supporting several connections per client) and there is an added overhead of STARTTLS + AUTH on the new connection. For the client wishing to implement this, it may encounter itself being throttled or limited to 1 connection to the server per IP. > So as to answer your proposal of ensuring that the contents of > articles are not compressed together, we could call "COMPRESS DEFLATE > FLUSH" (or another better optional argument) that asks the server to > clear the compression dictionary after every response. I expect it to have a similar complexity as allowing a complete algorithm change, while being more limited. What if eg. the user wanted to authenticate again with a different set of credentials? Best regards _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
