Subject: [TLS] Use-case for non-AEAD ciphers in network monitoring

From: Florian Wilkens <[email-masked]>
Date: Mon, 17 May 2021 18:23:52 +0200

Hey folks,

we came across a novel use-case that highlights the need for non-AEAD
ciphers in TLS and would like to start a discussion on that.

Our use-case is passive TLS decryption on network monitors (NMs).
Non-AEAD ciphers would allow  to selectively forward the TLS write keys
from clients to a NM that can then passively decrypt TLS sessions,
without touching their integrity (as the write MAC keys remain on the
host). This would be a major improvement compared to the usage of MitM
proxies as current state of the art. MitM proxies terminate all TLS
connections and establish own connections. Thus, a compromised MitM
proxy cannot only decrypt all packets, but also change packet contents.

We propose an approach for passive TLS decryption [1] in which
cooperating hosts selectively forward TLS keys to the NM that then
decrypts TLS sessions. The approach is (i) completely passive and thus
does not interfere with the overall connection security and (ii) is able
to selectively decrypt certain TLS connections with the hosts retaining
full authority over the key material. While a MitM proxy can also claim
to selectively decrypt traffic, we can guarantee this by keeping key
material for selected connections on the client. Furthermore, for
non-AEAD ciphers only the write keys, but not the write MAC keys, are
forwarded, so that the NM can inspect but not modify TLS packets.

Our prototype is built for the Zeek network monitor [2] and is currently
in the process of being upstreamed with explicit interest from the
maintainers [3]. Once merged, this will be the first open-source
solution for passive TLS decryption on both client host (for which we
built a small prototype) and network monitor (Zeek).

We understand that AEAD ciphers offer many advantages and we understand
the decision to limit the set of available ciphers to secure choices
only. However, we think the use-case of passive TLS decryption is highly
relevant especially for enterprise settings. In such settings, mainly
MitM proxies are used that are a security problem on their own.

We look forward to your feedback.

Best,
Florian

[1] https://arxiv.org/abs/2104.09828
[2] https://zeek.org
[3] https://github.com/zeek/zeek/pull/1518

-- 
M.Sc. Florian Wilkens
Research Associate
Phone: +49 40 42883 2353

IT-Sicherheit und Sicherheitsmanagement (ISS)
Universität Hamburg
Fachbereich Informatik
Vogt-Kölln-Straße 30
22527 Hamburg
Deutschland

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 17 May 2021 17:24:24 +0000

Without commenting on the use-case itself, I am concerned that people will not appreciate "drop AEAD and its assurance of authenticity" would now also  mean "can be passively monitored."

I will point out that anyone can publish write a draft and request numbers to be assigned (e.g., look for GOSTR341112 or the integrity-only ciphers just before that in https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4).

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 May 2021 12:59:23 -0700

Hi Florian,

This suggestion comes up occasionally, and as Rich Salz says,
you could just register your own cipher suite.

With that said, I would make three comments:

1. I think it's a bit of a category error to talk about AEAD versus
non-AEAD in this context. AEAD is just an interface, so it's possible
to have AEAD algorithms that can have separate keys. For instance,
consider AES-CTR with HMAC.

2. If you have to define a new cipher suite, than that will require
changes on both sides, client and server.

3. It can be fairly hard to reason about the security properties of
this kind of system. As a concrete example, one might imagine that
having only the confidentiality key would allow one to inspect HTTP
client requests but not to modify them. However, because much HTTP
authentication is via cookies, as a practical matter being able to
inspect an HTTP transcation is sufficient to impersonate the client to
the server.

-Ekr

On Mon, May 17, 2021 at 9:25 AM Florian Wilkens <
[email-masked]> wrote:

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

---

From: Darin Pettis <[email-masked]>
Date: Mon, 17 May 2021 15:33:17 -0500

Thanks to Eric and Rich for your technical responses and cautionary
statements.

I do see that Florian’s use-case below points to the continued need for
enterprise inspection as once the data lands inside the data center they
become the custodians of it and are responsible for the security and
performance of the data.

I would like to ask the group to ameliorate the use case and challenge them
to come up with a way for enterprises to see the data internally while
keeping it safe externally.

TLS 1.3 did a great job regarding safety of data on the Internet. For the
next version, let’s focus on how to best meet this used case

On Mon, May 17, 2021 at 3:01 PM Eric Rescorla <[email-masked]> wrote:

>> <https://www.google.com/maps/search/Vogt-K%C3%B6lln-Stra%C3%9Fe+30+%0D%0A22527+Hamburg+%0D%0ADeutschland?entry=gmail&source=g>
>> 22527 Hamburg
>> <https://www.google.com/maps/search/Vogt-K%C3%B6lln-Stra%C3%9Fe+30+%0D%0A22527+Hamburg+%0D%0ADeutschland?entry=gmail&source=g>
>> Deutschland
>> <https://www.google.com/maps/search/Vogt-K%C3%B6lln-Stra%C3%9Fe+30+%0D%0A22527+Hamburg+%0D%0ADeutschland?entry=gmail&source=g>
>>

---

From: Darin Pettis <[email-masked]>
Date: Mon, 17 May 2021 15:37:21 -0500

…use case*

Thanks in advance,
Darin Pettis

On Mon, May 17, 2021 at 3:33 PM Darin Pettis <[email-masked]>
wrote:

> I would like to ask the group to ameliorate the use case and challenge
> them to come up with a way for enterprises to see the data internally while

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 May 2021 21:48:09 +0100

Hiya,

> next version, let’s focus on how to best meet this used case

I think we had this discussion a few years ago. There is
no sensible boundary at which TLS can apply different
cryptographic treatment.

There were also many many other points raised at that
time that I don't think we'll benefit from repeating.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 May 2021 13:52:37 -0700

> next version, let’s focus on how to best meet this used case

Hi Darin,

I'm not sure there's much TLS work to do here. As I said, defining an AEAD
cipher which doesn't lose
integrity when the confidentiality key is leaked is possible, but that
won't address the issue of not
being able to reason about the security properties. That's primarily an
issue for upper-level protocols
not TLS.

-Ekr

---

From: Darin Pettis <[email-masked]>
Date: Mon, 17 May 2021 16:04:26 -0500

Hi Stephen,
Thanks for the quick reply as I know it is getting late in Ireland.

I’m sure you do remember the conversation as you spent a lot of time at the
microphone around it.  :-)

It is certainly not an easy question to answer but this group comprises the
smartest people that I know!!  Surely someone must be up for the challenge
as fully half of the people in that London hall voiced the need for it.
Furthermore, when the day comes that TLS 1.2 can’t be used anymore, for
whatever the reason, this need is going to come racing down the tracks…

So, while everyone is breathing easy right now, it would be great to
address the need proactively.

Respectfully,
Darin

---

From: Andrei Popov <[email-masked]>
Date: Mon, 17 May 2021 21:11:59 +0000

This NIST workshop<https://www.nccoe.nist.gov/events/virtual-workshop-challenges-compliance-operations-and-security-tls-13> is investigating the exact problem discussed on this thread. Several types of solutions have been proposed there.

Cheers,

Andrei

From: TLS <[email-masked]> On Behalf Of Darin Pettis
Sent: Monday, May 17, 2021 2:04 PM
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [TLS] Use-case for non-AEAD ciphers in network monitoring

Hi Stephen,

I’m sure you do remember the conversation as you spent a lot of time at the microphone around it.  :-)

It is certainly not an easy question to answer but this group comprises the smartest people that I know!!  Surely someone must be up for the challenge as fully half of the people in that London hall voiced the need for it.  Furthermore, when the day comes that TLS 1.2 can’t be used anymore, for whatever the reason, this need is going to come racing down the tracks…

So, while everyone is breathing easy right now, it would be great to address the need proactively.

Respectfully,
Darin

On Mon, May 17, 2021 at 3:48 PM Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

Hiya,

Cheers,
S.

---

From: "Ruslan N. Marchenko" <[email-masked]>
Date: Tue, 18 May 2021 08:11:42 +0200

Am Montag, dem 17.05.2021 um 16:04 -0500 schrieb Darin Pettis:
> It is certainly not an easy question to answer but this group
> comprises the smartest people that I know!!  Surely someone must be
> up for the challenge as fully half of the people in that London hall
> voiced the need for it.  Furthermore, when the day comes that TLS 1.2
> can’t be used anymore, for whatever the reason, this need is going to
> come racing down the tracks…
> 

In my eyes the problem (use case) statement is a bit dishonest in this
context. Enterprises need control over data. What this proposal tries
to offer though is snooping/eavesdropping. And control is proxy (mitm)
when you openly and actively control data flow and do not pretend that
you are not here.

In addition to already mentioned integrity leakage via cookie this
proposal also compromises other security (integrity) controls such as
TLS channel binding.

And again it pretends to be opt-in but in the landscape of current
base-line threat-model it's just an invitation to exploit it (send/leak
the keys to malicious party).

Regards,
Ruslan

---

From: Florian Wilkens <[email-masked]>
Date: Wed, 26 May 2021 10:48:56 +0200

Dear all,

first, we want to thank you for your feedback, it is much appreciated!
We wanted to briefly clarify some details about our idea:

- AEAD/non-AEAD: completely true. We were mainly looking at ciphers from
TLS 1.3 that all use keys and IVs but that is of course unrelated to
AEAD as a concept.
- registering our own ciphersuite: while that is certainly an option, we
are not really advocating for new cipher suites but rather keeping at
least a single cipher suite in the standard that allows for separate
keys for confidentiality and integrity.

We also tried to catch up on the discussions in 2016/2017 around
industry concerns to TLS 1.3 (regarding PFS and static key exchanges).
While some parts are certainly similar, we think our approach is
different, as we do not aim to weaken the overall connection security
but rather keep the client machine in control of the key material (as it
is already with current TLS).

To be clear, our prototype already works on current TLS as is. The
client sends either the pre-master-secret or derived session keys to the
network monitor. Naturally, this will continue to work with future TLS
versions as the client ultimately possesses all required key material.
There are certainly scenarios in which an enterprise might still want to
deploy an MitM proxy at the network edge to retain more control, however
our approach is able to avoid the disadvantages induced by these
proxies. In fact multiple commercial offerings (including one proposed
on the linked NIST workshop) already do exactly what we propose and hand
over all key material to a central party for decryption. Whether this is
good practice, is a discussion for another time, but it is already
happening anyway and there is demand for these solutions.

Our prototype is able to slightly decrease the attack surface on the
network monitor, as it is not able to forge valid packets in the same
connection due to the missing integrity key. The impact on application
protocols such as HTTP is a problem, however this problem is also
present on both commercial solutions that exfiltrate all key material
from the client and MitM proxies.

Overall, we just wanted to raise some awareness for the use case as we
felt that a small change to a future TLS standard could achieve some
slight improvements regarding the network monitor. However, if that does
not match the WG's opinion that is certainly okay, as we can work with
current TLS.

So again thank you for you feedback!
Cheers,
Florian

-- 
M.Sc. Florian Wilkens
Research Associate
Phone: +49 40 42883 2353

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 27 May 2021 08:00:28 +1000

It seems to me like the next step is to share a paper, ideally in the form of an internet-draft, that describes more precisely what you would like to see happen.

On Wed, May 26, 2021, at 18:48, Florian Wilkens wrote:
> > [email-masked] <mailto:TLS%40ietf.org>
> [email-masked] <mailto:TLS%40ietf.org>
> Attachments:
> * OpenPGP_signature