Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Tony Arcieri]

On Friday, June 10, 2016, Nikos Mavrogiannopoulos  wrote:

> I'm actually surprised you mention the microsoft servers as being
> version negotiation tolerant. They were the most prominent examples
> of terminating the handshake if TLS 1.2 was offered to them
>

Personally I'd give that award to F5 BIG-IP devices


-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Julien ÉLIE]

Last year, in September 2015, we spoke about the removal of TLS-level
compression in TLS 1.2.


Of course one should read "TLS 1.3".

--
Julien ÉLIE

« I don't worry about terrorism.  I was married for two years. »
  (Sam Kinison)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Compression along with TLS in NNTP

[Julien ÉLIE]

Hi all,

Last year, in September 2015, we spoke about the removal of TLS-level 
compression in TLS 1.2.
NNTP was relying on this feature provided by previous TLS versions to 
compress data.  We agreed that the right move was to standardize a new 
NNTP command.  It is what we finally did with the COMPRESS extension.
Interoperability is proven:  two news servers (INN, Cyrus NNTP) and a 
news client (flnews) have already implemented it.  It also works fine 
with Python nntplib+zlib libraries.


Here is the latest version of the draft:
https://tools.ietf.org/html/draft-murchison-nntp-compress-03

If you have any comments, please don't hesitate to tell.


Especially, I have a question:

   o  How are TLS (and SASL) specific exchanges supposed to be handled?
  Should it be mentioned in the RFC that they are outside the scope
  of NNTP compression?  (I speak of stuff like TLS handshakes,
  renegotiations, etc. that can occur after the use of COMPRESS.
  OpenSSL may use SSL_read/SSL_write on its own, mayn't it?  And it
  does not know that it should compress data...)




Here is an extract of the paragraphs dealing with TLS in the draft, so 
that you can easily see what to comment (wording improvement, missing 
stuff...).



   The point of COMPRESS as an NNTP extension is to behave as a
   transport layer, similar to STARTTLS [RFC4642].  Compression can
   therefore benefit to all NNTP commands sent or received after the use
   of COMPRESS.

[...]

1.1.  About TLS-level Compression

   Though data compression is made possible via the use of TLS with NNTP
   [RFC4642], the best current practice is to disable TLS-level
   compression as explained in Section 3.3 of [RFC7525].  The COMPRESS
   command will permit to keep the compression facility in NNTP and
   control when it is available during a connection.

   Compared to TLS-level compression [RFC3749], NNTP COMPRESS has the
   following advantages:

   o  COMPRESS can be implemented easily both by NNTP servers and
  clients.

   o  COMPRESS benefits from an intimate knowledge of the NNTP
  protocol's state machine, allowing for dynamic and aggressive
  optimization of the underlying compression algorithm's parameters.

   o  COMPRESS can be activated after authentication has completed thus
  reducing the chances that authentication credentials can be leaked
  via for instance a CRIME attack ([RFC7457] Section 2.6).

[...]

2.2.2.  Description

[...]

   Both the client and the server MUST know if there is a compression
   layer active (for instance via the previous use of the COMPRESS
   command or the negotiation of a TLS-level compression [RFC3749]).  A
   client MUST NOT attempt to activate compression or negotiate a TLS
   layer (for instance via the use of the COMPRESS or STARTTLS [RFC4642]
   commands) if a compression layer is already active.  A server MUST
   NOT return the COMPRESS or STARTTLS capability labels in response to
   a CAPABILITIES command received after a compression layer is active,
   and a server MUST reply with a 502 response code if a syntactically
   valid COMPRESS or STARTTLS command is received while a compression
   layer is already active.

[...]

6.  Security Considerations

   Security issues are discussed throughout this document.

   In general, the security considerations of the NNTP core
   specification ([RFC3977] Section 12) and the DEFLATE compressed data
   format specification ([RFC1951] Section 6) are applicable here.

   Implementers should be aware that combining compression with
   encryption like TLS can sometimes reveal information that would not
   have been revealed without compression, as explained in Section 6 of
   [RFC3749].  As a matter of fact, adversaries that observe the length
   of the compressed data might be able to derive information about the
   corresponding uncompressed data.  The CRIME and the BREACH attacks
   ([RFC7457] Section 2.6) are examples of such case.

   In order to help mitigate leaking authentication credentials, this
   document states in Section 2.2.2 that authentication SHOULD NOT be
   attempted when a compression layer is active.  Therefore, when a
   client wants to authenticate, compress data, and negotiate a secure
   TLS layer (without TLS-level compression) in the same NNTP
   connection, it SHOULD use the STARTTLS, AUTHINFO, and COMPRESS
   commands in that order.  Of course instead of using the STARTTLS
   command, a client can also use implicit TLS, that is to say it begins
   the TLS negotiation immediately upon connection on a separate port
   dedicated to NNTP over TLS.

   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 is
   active.  In case private and confidential newsgroups or articles are
   accessed,