Subject: [Uta] Feedback on draft-ietf-uta-tls-attacks-02 concerning NULL cipher

From: Ralph Holz <[email-masked]>
Date: Wed, 03 Sep 2014 19:42:32 +0200

Good day,

I have solicited some feedback on the wording in 4.1, the MUST NOT on
selecting the NULL cipher. I have feedback from members of the TLS WG,
and from operators of Grid centres. My fear was that MUST NOTing the
NULL cipher in the BCP may lead implementers to drop it entirely. I have
a suggested new wording, with a new note, that I think would resolve this:

"Deployments of TLS to secure application-layer protocols MUST NOT
negotiate the NULL cipher.

Note: TLS implementations MAY retain code for the NULL cipher to allow
specialised purposes like debugging, custom solutions, etc."

That will make it clear that implementers are free to retain NULL (and
they will), but that the purpose of the BCP is to propose secure TLS
configurations to protect application-layer protocols, and for those no
deployment should ever negotiate NULL.

As for the feedback - it seemed to be divided into two categories:

1) Kill off the NULL cipher for all deployments.

2) There are some use cases, do not forbid it in
a) implementations
b) deployments

The operators of Grid centres did have some very good use cases
concerning a) - namely European centres having dedicated authentication
mechanisms that rely on code in e.g. OpenSSL to provide exactly this
NULL cipher (but MAC-ed). I can forward their exact use case if there is
interest here. They did emphasise, however, that speed of encryption is
no longer a concern for them.

Concerning b), some people mentioned use cases like

* monitoring traffic in internal networks, especially in VPN settings
* IPC
* some other mechanisms that seem rarely used

I think implementations keeping NULL in code, but not enabling it for
deployments, is the way to go and addresses all uses cases in a) and b).
A note should be sufficient to make this clear.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 03 Sep 2014 22:07:52 +0300

Resending Ralph's mail, with the correct draft name in the subject.

Thanks,
	Yaron

---

From: Chris Newman <[email-masked]>
Date: Wed, 03 Sep 2014 13:14:51 -0700

> deployment should ever negotiate NULL.

I like this proposal.

> A note should be sufficient to make this clear.

It would be interesting if the IETF started defining new application protocols
as always using TLS. Then the implementer has to integrate the TLS stack right
away but having the NULL cipher around for debugging and field testing would be
very helpful to that model. If the NULL cipher goes away, it will create
pressure to continue having non-TLS variants of application protocols.

		- Chris

---

From: Ralph Holz <[email-masked]>
Date: Wed, 03 Sep 2014 23:01:51 +0200

Good day,

as an addendum I should add that some people in the TLS WG feel that
MUST NOT etc. will always refer to both deployment and installation, as
this seems to be a common understanding in the IETF. I.e., MUST NOTing
something referring to deployment = configuration precludes you from a
MAY referring to an implementation.

Re-reading the definition of what a BCP is, I do not agree, actually,
but I do not wish to enter this discussion either (others may). But I
felt I should forward this.

Ralph

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 04 Sep 2014 12:53:24 +0200

Hi UTA,

> 1) Kill off the NULL cipher for all deployments.
+1
> no longer a concern for them.
Disclaimer: for the last 2.5 years I've - also - been working and
consulting in HPC/grid computing.

While it is true that you might want to use the NULL cipher for
performance reasons, in this particular field it is also true that it's
extremely common that custom developed tools (or tools that
intentionally defy standards) are used for pure performance reasons (see
HPN-SSH). If this is the only valid point that came up on tls@ I think
we can safely ignore it. HPC and Grid sites/engineers will in any case
opt to change and tune software according to their needs not IETF BCPs.

Aaron