Subject: [TLS] Support of integrity only cipher suites in TLS 1.3

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 3 Apr 2017 16:17:45 +0000

Hi all,

by reviewing the current TLS 1.3 draft I saw that already in version -02 the support for integrity only cipher suites has been removed in favor of AEAD cipher suites. Was there a specific reason to only support the encrypted cipher suites?

The reason I'm asking is that in industrial communication it is often sufficient to have source authentication and message integrity while probes on the network are still able to monitor the traffic for certain properties or verify allowed exchanges. An example is ICCP for inter control center communication.
The two control center are connected via an IPSec tunnel terminated in the DMZ. The desire is to have the TLS tunnel end-to-end to allow for source authentication and also for message integrity, while doing traffic inspection in the DMZ. There exist other scenarios, with a similar requirement.

If I interpret the TLS 1.3 draft right, these scenarios will not be possible in the future without a trusted intermediate host terminating the TLS link to both peers. Hence the question if the decision to use encryption only is only bound to the base specification of TLS 1.3 and that additional cipher suites (allowing integrity only) can be defined later on.

Best regards
Steffen

--
Steffen Fries
Siemens AG
Corporate Technology
CT RDA ITS
Otto-Hahn-Ring 6
81739 Muenchen, Germany
Tel.: +49 89 636-633604
Fax: +49 89 636-48000
mailto:[email-masked]

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Siegfried Russwurm, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

---

From: Harlan Lieberman-Berg <[email-masked]>
Date: Tue, 04 Apr 2017 01:09:48 -0400

"Fries, Steffen" <[email-masked]> writes:
> The reason I'm asking is that in industrial communication it is often
> sufficient to have source authentication and message integrity while
> probes on the network are still able to monitor the traffic for
> certain properties or verify allowed exchanges.

Hello Steffen,

We've had a couple of discussions about this on the mailing list before.
(See especially the "Industry Concerns about TLS 1.3" email thread
starting with [email-masked]).
At this point, I don't think there's much of an appetite to be adding
support for null-encryption cipher suites into TLS 1.3.

In a quick summary of the 100+ message thread, the impression I got from
the conversation was that the WG feels there's too much foot-gun
potential from null cipher suites and that the risk was too high and the
concerns brought up too late.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

---

From: "Fries, Steffen" <[email-masked]>
Date: Tue, 4 Apr 2017 10:48:11 +0000

Hello Harlan,

thank you for the information. I will go back to the discussion and read it to get a better understanding about the reasoning. I had a peek into 3 or 4 emails and there were centered around the deprecation of RSA encrypted  key exchange. This is different from what I had in mind. You mentioned null-cipher, which would be the choice I would see. Yes, maybe it is too late to bring this issue into the discussion. Nevertheless, as there is a need for network monitoring it would be easier to have the monitoring on an integrity protected connection, while the traffic is additionally encrypted when crossing public networks. This is  the intended approach for the scenario I described for Inter Control Center communication.  This would allow for non-intrusive monitoring instead of a distinct termination point, which breaks end-to-end integrity (if not provided on higher layers) also influences the end-to-end performance. I see that the integrity only is a problem for certain other scenarios, but having the flexibility in the protocol would allow to make a decision about the preferred cipher suites for a specific use case based on a security policy. 

Best regards
Steffen

-----Original Message-----
From: Harlan Lieberman-Berg [mailto:[email-masked]] 
Sent: Dienstag, 4. April 2017 07:10
To: Fries, Steffen (CT RDA ITS); TLS WG
Subject: Re: [TLS] Support of integrity only cipher suites in TLS 1.3

Hello Steffen,

We've had a couple of discussions about this on the mailing list before.
(See especially the "Industry Concerns about TLS 1.3" email thread starting with [email-masked]).
At this point, I don't think there's much of an appetite to be adding support for null-encryption cipher suites into TLS 1.3.

In a quick summary of the 100+ message thread, the impression I got from the conversation was that the WG feels there's too much foot-gun potential from null cipher suites and that the risk was too high and the concerns brought up too late.

Sincerely,
--
Harlan Lieberman-Berg
~hlieberman

---

From: Hanno Böck <[email-masked]>
Date: Tue, 4 Apr 2017 18:08:38 +0200

On Mon, 3 Apr 2017 16:17:45 +0000
"Fries, Steffen" <[email-masked]> wrote:

> certain properties or verify allowed exchanges. An example is ICCP
> for inter control center communication. The two control center are
> connected via an IPSec tunnel terminated in the DMZ. The desire is to
> have the TLS tunnel end-to-end to allow for source authentication and
> also for message integrity, while doing traffic inspection in the
> DMZ. There exist other scenarios, with a similar requirement.

Adding such a mode would add additional complexity that might lead to
vulnerabiltiies, e.g. implementations that can be tricked into using a
nonencrypted mode.

It's been a trend in the tls working group to
a) reduce complexity when possible.
b) not try to accomodate obscure use cases that aren't relevant for the
majority of TLS use cases.

Thus I assume a null cipher won't find support here. If you want to
have traffic inspection with TLS imho the right way is to support that
at the end points (let alone any arguments why you're doing traffic
inspection in the first place and whether those reasons are good ones).
If you don't like that then TLS may be not the right protocol for your
use case.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [email-masked]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

---

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 5 Apr 2017 17:14:01 +0000

Adding such a mode would add additional complexity that might lead to vulnerabiltiies, e.g. implementations that can be tricked into using a nonencrypted mode.
[[stf]] in principle yes, as this simplifies the configuration and policy handling. On the other hand it is a security policy point to allow certain cipher suites. 

It's been a trend in the tls working group to
a) reduce complexity when possible.
[[stf]] understood, makes operation less error prone

b) not try to accomodate obscure use cases that aren't relevant for the majority of TLS use cases.
[[stf]] well, as TLS is used in use cases like energy automation, industrial control, railway automation etc. there is an increasing number of use cases applying TLS and there are some, which would leverage integrity only for allowing for monitoring

Thus I assume a null cipher won't find support here. If you want to have traffic inspection with TLS imho the right way is to support that at the end points (let alone any arguments why you're doing traffic inspection in the first place and whether those reasons are good ones).
[[stf]] In principle yes, but the endpoints are often limited and may not support this type of functionality. Again, the traffic inspection in automation related communication is done for auditing and monitoring of the control flow. In the example of energy automation, TLS is always used with mutual authentication. So both peers know each other.

If you don't like that then TLS may be not the right protocol for your use case.
[[stf]] It was possible to now and it is good to rely on a protocol like TLS, which is defined and discussed in this way in the IETF. In the IEC (which is engaged I energy automation communication definition) there is the desire to use standardized security protocols available to avoid the definition of own solutions, whenever possible.

--
Hanno Böck
https://hboeck.de/

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 5 Apr 2017 17:15:37 +0000

Do you have a compelling need for TLS 1.3 as opposed to earlier versions which do have null encryption?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Apr 2017 10:31:23 -0700

Without taking a position on null cipher suites, I would observe that the
new TLS IANA rules will let you register your own (non-standard,
non-recommended) code points for integrity-only suites.

-Ekr

On Wed, Apr 5, 2017 at 10:14 AM, Fries, Steffen <[email-masked]>
wrote:

> [[stf]] in principle yes, as this simplifies the configuration and policy
> handling. On the other hand it is a security policy point to allow certain
> cipher suites.
>
> [[stf]] well, as TLS is used in use cases like energy automation,
> industrial control, railway automation etc. there is an increasing number
> of use cases applying TLS and there are some, which would leverage
> integrity only for allowing for monitoring
>
> Thus I assume a null cipher won't find support here. If you want to have
> traffic inspection with TLS imho the right way is to support that at the
> end points (let alone any arguments why you're doing traffic inspection in
> the first place and whether those reasons are good ones).
> [[stf]] In principle yes, but the endpoints are often limited and may not
> support this type of functionality. Again, the traffic inspection in
> automation related communication is done for auditing and monitoring of the
> control flow. In the example of energy automation, TLS is always used with
> mutual authentication. So both peers know each other.
>
> [[stf]] It was possible to now and it is good to rely on a protocol like
> TLS, which is defined and discussed in this way in the IETF. In the IEC
> (which is engaged I energy automation communication definition) there is
> the desire to use standardized security protocols available to avoid the
> definition of own solutions, whenever possible.
>
> --
> Hanno Böck
> https://hboeck.de/
>

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 6 Apr 2017 08:07:48 +0000

You  are right, I did not take that option into account. But as you mentioned, it is non-standard and with the desire is to be interoperable as most as possible, proprietary enhancements are likely not to be favored.

best regards
Steffen

From: Eric Rescorla [mailto:[email-masked]]
Sent: Mittwoch, 5. April 2017 19:31
To: Fries, Steffen (CT RDA ITS)
Cc: Hanno Böck; [email-masked]
Subject: Re: [TLS] Support of integrity only cipher suites in TLS 1.3

Without taking a position on null cipher suites, I would observe that the new TLS IANA rules will let you register your own (non-standard, non-recommended) code points for integrity-only suites.

-Ekr

On Wed, Apr 5, 2017 at 10:14 AM, Fries, Steffen <[email-masked]<mailto:[email-masked]>> wrote:
Adding such a mode would add additional complexity that might lead to vulnerabiltiies, e.g. implementations that can be tricked into using a nonencrypted mode.
[[stf]] in principle yes, as this simplifies the configuration and policy handling. On the other hand it is a security policy point to allow certain cipher suites.

--
Hanno Böck
https://hboeck.de/

mail/jabber: [email-masked]<mailto:[email-masked]>
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 6 Apr 2017 08:27:00 +0000

Yes, sticking to TLS 1.2 is an option. On the other hand the equipment in scenarios like energy automation is used for a very long time. TLS is used here to secure the communication between specific devices. Besides that, it is also used to allow access for, e.g., service technicians  via web based management on the same devices. One concern is that once in a while the support for TLS 1.2, e.g., in common browsers will run out and the devices need to be upgraded to support different versions of TLS to cope with different security policies. But well, this is likely to be the fate for every long lasting equipment. 

The other point is that for NULL cipher suites that work with elliptic curves no SHA 256 suite is defined. There is just one with RSA. In several use cases there ECDSA is preferred over RSA also due to the required increasing key length and the connected computational load on the devices.

best regards
Steffen

---

From: Kyle Rose <[email-masked]>
Date: Thu, 6 Apr 2017 07:12:24 -0400

On Apr 6, 2017 4:08 AM, "Fries, Steffen" <[email-masked]> wrote:

You  are right, I did not take that option into account. But as you
mentioned, it is non-standard and with the desire is to be interoperable as
most as possible, proprietary enhancements are likely not to be favored.

>From a security standards perspective, interoperability by-default is
expressly *undesirable* for this mode of operation. We want this to break
for anyone who hasn't gone through the trouble of explicitly opting-in.

This seems to be a perfect case for the "allow registration of code points,
but do not standardize or recommend" approach: the mechanism is possible to
implement in a way that respects IANA namespacing by those parties with
special needs requiring it, but the risk that someone will accidentally
implement it in a stack used in end-user software is minimal.

Kyle

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 6 Apr 2017 14:07:54 +0000

Fries, Steffen <[email-masked]> writes:

>One concern is that once in a while the support for TLS 1.2, e.g., in common
>browsers will run out and the devices need to be upgraded to support
>different versions of TLS to cope with different security policies. But well,
>this is likely to be the fate for every long lasting equipment.

I don't think you'll need to worry about that for a long time, if ever.  The
20-year-old SSLv3 has only recently been killed off and that had some pretty
serious security issues.  TLS 1.0 devices will be around for years, possibly
decades, and TLS 1.2 even longer.  Like HTTP 1.1 (vs. HTTP/2), TLS 1.2 could
well stick around forever.

Peter.