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

Ángel González <angel@ietf.16bits.net> Sun, 12 June 2016 02:08 UTC

Return-Path: <angel@ietf.16bits.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9D112D103; Sat, 11 Jun 2016 19:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGE63agGMww9; Sat, 11 Jun 2016 19:08:33 -0700 (PDT)
Received: from mailer.hiddenmail.net (mailer.hiddenmail.net [199.195.249.9]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25F012B057; Sat, 11 Jun 2016 19:08:33 -0700 (PDT)
Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from <angel@ietf.16bits.net>) id 1bBupD-0001Td-0h; Sun, 12 Jun 2016 04:08:31 +0200
Message-ID: <1465697307.2175.32.camel@16bits.net>
From: Ángel González <angel@ietf.16bits.net>
To: Julien ÉLIE <julien@trigofacile.com>, "tls@ietf.org" <tls@ietf.org>, uta@ietf.org
Date: Sun, 12 Jun 2016 04:08:27 +0200
In-Reply-To: <b7806285-193d-08f9-6b81-a19d0fdfae2d@trigofacile.com>
References: <b7806285-193d-08f9-6b81-a19d0fdfae2d@trigofacile.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Evolution 3.20.2
Mime-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/iZyME6zqzWN3lIOno3pkw_qTo4I>
X-Mailman-Approved-At: Sun, 12 Jun 2016 20:12:10 -0700
Subject: Re: [TLS] [Uta] Compression along with TLS in NNTP
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jun 2016 02:16:38 -0000

On 2016-06-10 at 22:43 +0200, Julien ÉLIE wrote:
> NNTP commands other than AUTHINFO are not believed to divulgate
> confidential information as far as public Netnews newsgroups and
> articles are concerned.  That is why this specification only adds a
> restriction to the use of AUTHINFO when a compression layer 
> active.  In case private and confidential newsgroups or articles are
> accessed, a server SHOULD NOT allow compression, and a client SHOULD
> NOT attempt to activate compression, for the same reasons as
> mentioned above in this Section.
> 
> Implementations MUST support a configuration where compression can be
> easily disabled.
> 
> Future extensions to NNTP that define commands conveying confidential
> data SHOULD ensure to state that they SHOULD NOT be used along with
> compression.
> 
> Thanks again for your useful comments!


The main problem is not as much that the contents are compressed or
not, but that known plain text and confidential data are compressed
together.

As such, I don't think it's usually necessary to disable it for
confidential articles/newsgroups.
What you need to avoid is that in the same compress session where you
read the article with the steps to enter into the nuclear facility, you
also read a different public article that the spies know you will read,
as the compressed size will vary depending on the contents of the
secret.

Of course, if instead of a general text of relatively unknown length,
the attacker knows that you will get a list of 100 nuclear launch
codes, seeing how well did it compress might allow them to guess some
of their properties.


Regarding your draft, I would 
a) add a None algorithm
b) allow compress to be called inside a compress session, replacing the
previous one.

Thus, a client would be able to COMPRESS DEFLATE, <read public groups>,
COMPRESS NONE, <read secret article>, COMPRESS DEFLATE, <more public
activity>

Or even call COMPRESS DEFLATE, <read article A>, COMPRESS DEFLATE,
<read article B> to ensure their contents are not compressed together.

Best regards