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

Darin Pettis <> Mon, 17 May 2021 20:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE58C3A4407 for <>; Mon, 17 May 2021 13:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 m7FwWgRcyCap for <>; Mon, 17 May 2021 13:37:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB5113A4421 for <>; Mon, 17 May 2021 13:37:34 -0700 (PDT)
Received: by with SMTP id r11so8400286edt.13 for <>; Mon, 17 May 2021 13:37:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PUVWb97rS5Cf+fO74pz3jptiD119BLnt46j+polToHE=; b=DUgXuq/C1z87RtXd462qZtMagN68/JvWU8Q4xyDgv/y9mggGoVyZr5AuE2QqUFJfBt avhBAc619i96fN4Xb3q0SEzMV5wDBBY3m2T4d8e1JOcxuKXVGpkqpVFOYbpY93pv0T9b 4LWKEhPF42hjeOWf/pzP8PlCq/hPmBwUZZT4iA3Q9GZB9rp/nHT+QXk4rGS7vf8VLQ6D MalZq/6uDKPk4+hJCA3Q2pZywxDOIYJDetKhjzpNqnMujFujLIe983LTb2+mc2Wllr2e ajiKahAR94bQGsCyq0N7aJMomg18vsEIxs4DJzdLZs2eNwIU7tDXC7Lv+/KlSGYLCAdi UZeA==
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=PUVWb97rS5Cf+fO74pz3jptiD119BLnt46j+polToHE=; b=gzVuCwLdr2vO+wREfMJYeWOhLMl9qi8wCBqAF9/6n3kYWHaQalJT36AqQM7uxd4hhj Ci4vQmaZ70TgKZ2WK7tp8oI42n/Rq840Cm/cVuBWyidne1jj1/IKIHV2oUQO1MekUF9U ybwW8DTdUhqHHFmOZHlkWxy/sLX/iOctnkg65wW+a1nZmqBM0edGAtl2EosGHA3kS8+v j8Cn7En1ar5HxXy+A5qLorknkq55n/GOp8UAydWyRn1AbBqiQ94UOeFtpeNo4OB0jete R3CHvJFULXuN76JoBaNkou7vI8EKeW0QlSn7o0xJo/T/Pjfu9RM0NZO86aaUgMRAWdSj 2LAA==
X-Gm-Message-State: AOAM5337UHA/IvdPzJuZIw+VZsqu49orfkDeMLiEerepm3lrI7T0jyC0 S3dQBIWwfDlbHJg2UsgXWlhED6TGWZMxd8xNBt+3b/V6
X-Google-Smtp-Source: ABdhPJz3QR9UgLwJJzJssC4qvESDroINhVYexosy4LbTuFVSFSkQjhK2O0L14j0TCBnO1vvbgmscuoww2r9ImAJIkqI=
X-Received: by 2002:a05:6402:cb8:: with SMTP id cn24mr2189377edb.325.1621283852796; Mon, 17 May 2021 13:37:32 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Darin Pettis <>
Date: Mon, 17 May 2021 15:37:21 -0500
Message-ID: <>
To: Eric Rescorla <>
Cc: "<>" <>, Florian Wilkens <>
Content-Type: multipart/alternative; boundary="00000000000020452605c28c90b6"
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:37:40 -0000

…use case*

Thanks in advance,
Darin Pettis

On Mon, May 17, 2021 at 3: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
> 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