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

Eric Rescorla <> Mon, 17 May 2021 20:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 381103A44AE for <>; Mon, 17 May 2021 13:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0YJXJcLcMewc for <>; Mon, 17 May 2021 13:53:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BC803A448B for <>; Mon, 17 May 2021 13:53:15 -0700 (PDT)
Received: by with SMTP id j30so7240214ila.5 for <>; Mon, 17 May 2021 13:53:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7KOs4iR4PSC0CYgNbnpFiC3/C/QHJnVOeocvC42wwXc=; b=PKNTdmy7sW2+fwo8f01wC3RAEbak8OOuqTq9Y26I4CfLrdOYVoGVUj2bLifUfIDldE rxCEfdWmqd+AZiehnTqto2Q23vU6MEyBSLvcChDdxsHx5alab9J20kGsk4nb6CEEc6ag Uubd13WeX5I0mRid43vNJNMzCENlG3twn9ioVjeWrDReNVGkXxNuQD9FV9RsbDBrlARK hclVArBRQwt2tWMBjjyNSsxs0kuJKOmL9v/jy1NJPoHcMTlgMmd1dhIKaE/nT019mPrK +LMhX4uAjTiuECflNDz3vJ0BTMz/KmShO/gCefGR020p/JwXgt9BKTvtDpJc6DiJNDUS 8VNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7KOs4iR4PSC0CYgNbnpFiC3/C/QHJnVOeocvC42wwXc=; b=XylK5OBVo04E/R45CkYcM3qo1DVHigoQ998XMng962eAFa5rtvxKtkgl7LzD9dTQpQ Kda5l3FXiNfrpyQByDAbZV0Y8zS+gFASPP5IWYIlc9TS4rU8uZyl8VgJ+xgvzJgTvvjY IEL31Pe9zbLrlj0dvNRKzi7GGYU9chW8e3TvIWiSdT1Z4CR+/CAaYtkzUcmZ/ONtfWfd fjlz/S10t5Jw7Fz89sC7AUEk3jPLYmSZi2hPeK0RrRaQVjDJG+fnpK7Ru0Y9XGY02YkG jgzatpbXSoAzaOEHtdrsMe1FLQJPhEsM3QMjtnmoBZ3baxS/OYJg6ZTiEahtzG1stgtk 6x2g==
X-Gm-Message-State: AOAM533zzVTtpgL0lBqLqKU6PlZ3T4AxI9t5kCl/CqBZeeLVVHIbd8QS lM8LcP2Ti2ZEDT42R0efcagNtPwIQ1cgLSQxohUsGg==
X-Google-Smtp-Source: ABdhPJxythP1/wV3Lyq45Dem17ZjyHwTEB8j+fY2KnBpFkDSZV7wPYbSlJ/NnR4EFklJdPrnkU/xI5fhaJu0BCcZpxY=
X-Received: by 2002:a92:de0c:: with SMTP id x12mr1321228ilm.282.1621284794308; Mon, 17 May 2021 13:53:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Mon, 17 May 2021 13:52:37 -0700
Message-ID: <>
To: Darin Pettis <>
Cc: "<>" <>, Florian Wilkens <>
Content-Type: multipart/alternative; boundary="0000000000003eb07d05c28cc845"
Archived-At: <>
Subject: Re: [TLS] Use-case for non-AEAD ciphers in network monitoring
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 May 2021 20:53:31 -0000

On Mon, May 17, 2021 at 1:33 PM Darin Pettis <>

> 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

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.


> On Mon, May 17, 2021 at 3:01 PM Eric Rescorla <> wrote:
>> 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 <
>>> wrote:
>>> 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]
>>> [2]
>>> [3]
>>> --
>>> 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
>>> <>
>>> _______________________________________________
>>> TLS mailing list
>> _______________________________________________
>> TLS mailing list