Subject: [Tcpcrypt] Fwd: Disabling encryption, null ciphers, double encryption

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 24 Apr 2014 20:52:35 +0200

-------- Mensaje original --------
Asunto: 	Participating in the tcpcrypt discussion
Fecha: 	Thu, 24 Apr 2014 10:32:43 -0700
De: 	David Mazieres expires 2014-07-23 PDT 
<[email-masked]>
Para: 	marcelo bagnulo braun <[email-masked]>

Forwarding this email on behalf of David Mazieres as it seems his email 
address bounces in the tcpcrypt ml...

From: David Mazieres <[email-masked]>
To: [email-masked]
Subject: Disabling encryption, null ciphers, double encryption
Reply-To: David Mazieres expires 2014-07-22 PDT
     <[email-masked]>
Date: Wed, 23 Apr 2014 17:50:57 -0700
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain

Nobody forces you to use TCP for a particular application.  But if you
choose TCP, you get congestion control.  There's no configuration option
by which you can disable the congestion window or plug in the "null
congestion window decrease algorithm."  Such concepts make no sense
because everybody uses TCP with the expectation that it will react to
network congestion.

That is the sense in which TCP Inc. must provide forward secrecy.  Once
TCP Inc. is active on a connection, there must be no null or weak
ciphers, there must be no way to disable encryption, and implementations
should not provide access to session keys in such a way that they can be
logged or otherwise disclosed.  Not everyone will want to use TCP Inc.,
but when it's active, users must have confidence that their
communications are protected from passive eavesdroppers regardless of
configuration.

Of course, incremental deployment will be critical.  Systems will ship
with TCP Inc. long before enabling it by default.  We can't expect
people to turn it on all at once, either, meaning implementations must
allow selection of TCP Inc. vs. plain TCP on a per-connection basis.
Some will likely use this per-connection control to disable TCP
Inc. underneath SSL and avoid "double encryption" (which could more
precisely be termed "encryption at two separate layers").  We can argue
about whether or not that's advisable, but it depends on the situation
and is not something we can prevent anyway.

Conversely, applications may wish to tweak behavior such as endpoint
authentication in the presence of TCP Inc.  Doing so requires an
out-of-band signaling mechanism for compatibility.  Such a signaling
mechanism will allow applications to disable application-layer
encryption in the presence of TCP Inc., particularly where TCP Inc. is
deemed more secure than legacy or home-grown application-layer crypto
(which often lacks forward secrecy).  Whether disabling
application-layer encryption over TCP Inc. is advisable depends on the
specifics, but cannot be prevented in any case.

So to summarize:  TCP Inc. is just an option.  However, once enabled, it
must provide security guarantees consistent across all permissible
configurations.  Certain mandatory features of TCP Inc. will, among
other uses, permit the avoidance of double encryption.  Fortunately, the
success of the TCP Inc. working group does not require consensus on the
advisability of avoiding double encryption.

David

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Apr 2014 13:07:37 -0700

Hi, all,

I think a significant point is being lost about disabling encryption 
during a TCP-INC connection - whether at the beginning (i.e., allowing 
upgrade) or later (i.e., allowing downgrade).

I don't think anyone is proposing UNILATERAL change to the security of a 
connection. Connection parameters need to be negotiated. If a user 
doesn't want to accept the terms of a connection - or a proposed change 
- they can always simply decline.

The idea of one-size-fits-all security is part of what has led us to 
alternate approaches - because that one size is usually the problem. 
Let's please not repeat past mistakes on that.

Joe

On 4/24/2014 11:52 AM, marcelo bagnulo braun wrote:
> _______________________________________________
> Tcpcrypt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpcrypt

---

From: Chris Palmer <[email-masked]>
Date: Thu, 24 Apr 2014 13:40:39 -0700

On Thu, Apr 24, 2014 at 1:07 PM, Joe Touch <[email-masked]> wrote:

> alternate approaches - because that one size is usually the problem. Let's
> please not repeat past mistakes on that.

People who want non-secure TCP already have it. It's called "TCP".

The past mistakes we must avoid are endless configuration
possibilities, modes, weird corner-cases, features that are really
misfeatures, et c.