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." »
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
