Re: [TLS] [Uta] Compression along with TLS in NNTP

[Julien ÉLIE <[e-mail]>]

Hi Ángel,

Sorry for the delay in the response.  I was asking some input from 
developers of news clients.


>> 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.

In the news.software.nntp, Michael Bäuerle gave the following answer:

"In general I see the problem at layer 8:  the user needs to understand 
what is going on and how to control things with the user interface of 
the programs.
The same thing as with encrypted E-Mail:  it's far too easy with most 
programs to send confidential information as clear text by accident.

For security purposes it is likely already too much to expect that the 
"compression on/off" switch is recognised as security relevant by the 
users. Therefore I think the best solution for security is to use a 
separate newsreader (explicitly compiled without compression support) 
for security relevant tasks."


>> 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).

OK.


>> 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.

I understand that point, and that it is a bad idea in general (stronger 
signal + more resources with the issue of limitation to 1 connection / 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?

A user cannot authenticate twice in NNTP (RFC 4643).
The AUTHINFO command is no longer available after a successful use.  The 
user needs to open another NNTP connection.  Using an NNTP command 
several times in a row to change a state is not usual.


Suggestion from news.software.nntp not adding more complexity:

"The simple "compression on/off" switch is very easy to implement and 
should be sufficient for nearly all non academic scenarios.

But maybe the default setting for the switch should be defined as "off",
because this is the more secure option.  Possible words instead of the
current:

| Implementations MUST support a configuration where compression can be
| easily disabled.

---
Implementations SHOULD use a default configuration with disabled
compression and MUST support an option to easily enable compression
[either with global scope or server/connection based].
---

This will ensure that e.g. a new version of a newsreader with support
for compression will not enable it automatically (possibly without
knowledge of a user who have not read the changelog)."


I suggest to also say, like your proposal, that news servers MAY have a 
global or connection based configuration parameter permitting to enforce 
more confidentiality on specific newsgroups (notably by ensuring for 
these newsgroups that the contents of two secret articles are not 
compressed together).  The server will then clear the compression 
dictionary either after selecting these newsgroups or before sending any 
article posted to these newsgroups.


Wouldn't these additions:
- default configuration of disabled compression,
- ideas to ensure protection is maximal for those wishing to implement a 
newsgroups based compression,
- clarification that the main problem is that public data and 
confidential data are compressed together (and not that encryption and 
compression are used together),
satisfy the needs of security?

We believe it would work better than complexifying the simple COMPRESS 
command, and that it no longer introduces potential security issues in 
the default configuration (whereas the previous version did).

-- 
Julien ÉLIE

« A man inserted an 'ad' in the classifieds:  "Wife wanted".
   Next day he received a hundred letters.
   They all said the same thing:  "You can have mine." »