From nobody Mon May 17 13:33:43 2021 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FA23A43FB for ; Mon, 17 May 2021 13:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElOSlnwp-1tt for ; Mon, 17 May 2021 13:33:35 -0700 (PDT) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B3B3A43F8 for ; Mon, 17 May 2021 13:33:35 -0700 (PDT) Received: by mail-ej1-x629.google.com with SMTP id z12so9692191ejw.0 for ; Mon, 17 May 2021 13:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jqm1LcAHagdOMyO1Z+PvwF9iTu5yF49hgNsFs2PYfhE=; b=LtSrSdNVVOE+jJeMw8TCHouM91+ofiDMW/2IhQiJtduQv9Prto/ykjRhoABMXhf/dp IMV5piy/ZJANaAiYfEl0Z+4d2Qh0Q6bqwz7u2v1nX6YnaiMVoD8RdQge02HDYDcduMs1 9L7gYcl4AFwlF5EGYISVLU7yNzq4gPNHykBa4raGIVc2h323jaAqr6WabyCc8hVTkoHo +YUZKiTR1xXoveDnV2SjCT9P2j5FFuvV+8mAL6ivpcxPWElr2kkaB1nvIIJW4/pfSrO5 mw1l110ZhFCtnkO3/gdHNDS5CiC9NepC8yYYGmfjPAm4ai+hNfSfRxwoFxge4KsIhxvX lh5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jqm1LcAHagdOMyO1Z+PvwF9iTu5yF49hgNsFs2PYfhE=; b=HalpYROIaXZ2eBc0cZFZ58rE6Mus61cpDxcxzylX8WN3cqAhehw83CxGzLycKjxB+j Q073InMeTb619YpxxIu1WyhGjSNRYoCTPoG0LIydrmPUr+8LZ/M6v52J1G237M83/G6K H1Xcp3Q7uxQDRqlUxlVIlbPtwRt3KdLNqoEOnpB/n6Lx4JfJamIe877Xd5LEKYIkONY7 LExyLlnuba30F65csNO2iVd+UdhL3pDxZ0QUSXlENCQAZ9auQTmC2DupDY3it/WNXzSL Ngt2Li6mFFLmwC+htIlKFKFwbZckaJc8lCvzHJ0HucJxQP1DeHIg5khE4eL+Y8dNFP7c zbyQ== X-Gm-Message-State: AOAM532nn2HTDMZYesmAPza/GUMY6UlXdt9UTjFqF9wNNWYyfxbP1Fwr I9FI7GfL8nnm00mimr2qHPaez0JwMPBGWYmOQCc= X-Google-Smtp-Source: ABdhPJxWRK/nEmhcP5pmGSvO7fvgKlM/qjhwM0AaMdsB0Exb0Sq0mtvaZxIYBvlfvXk8MUR83sNfpYCBrJNtY7aOarg= X-Received: by 2002:a17:906:3a45:: with SMTP id a5mr1870867ejf.288.1621283608592; Mon, 17 May 2021 13:33:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Darin Pettis Date: Mon, 17 May 2021 15:33:17 -0500 Message-ID: To: Eric Rescorla Cc: "" , Florian Wilkens Content-Type: multipart/alternative; boundary="0000000000009205bc05c28c814d" Archived-At: Subject: Re: [TLS] Use-case for non-AEAD ciphers in network monitoring X-BeenThere: tls@ietf.org 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:33:41 -0000 --0000000000009205bc05c28c814d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks to Eric and Rich for your technical responses and cautionary statements. I do see that Florian=E2=80=99s 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=E2=80=99s 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 < > wilkens@informatik.uni-hamburg.de> 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] 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=C3=A4t Hamburg >> Fachbereich Informatik >> Vogt-K=C3=B6lln-Stra=C3=9Fe 30 >> >> 22527 Hamburg >> >> Deutschland >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000009205bc05c28c814d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks to Eric and Rich for your technical responses and = cautionary statements. =C2=A0

I do see that Florian=E2=80=99s use-case below points to the continue= d need for enterprise inspection as once the data lands inside the data cen= ter they become the custodians of it and are responsible for the security a= nd performance of the data. =C2=A0

I would like to ask the group to ameliorate the use case and cha= llenge them to come up with a way for enterprises to see the data internall= y while keeping it safe externally. =C2=A0=C2=A0
TLS 1.3 did a great job regarding safety of data o= n the Internet. For the next version, let=E2=80=99s focus on how to best me= et this used case

On Mon, May 17, 2021 at 3:01 PM Eric Rescorla <ekr@rtfm.com> wrote:
Hi Florian,

This suggestion comes up occasi= onally, and as Rich Salz says,
you could just register your own cipher s= uite.

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 i= n 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 tha= t will require
changes on both sides, client and server.

3. It ca= n 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 c= onfidentiality key would allow one to inspect HTTP
client requests but n= ot to modify them. However, because much HTTP
authentication is via cook= ies, as a practical matter being able to
inspect an HTTP transcation is = sufficient to impersonate the client to
the server.

-Ekr

<= br>

On Mon, May 17, 2021 at 9:25 AM Florian Wilkens <wilkens@informatik.uni-h= amburg.de> 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=C2=A0 to selectively forward the TLS write key= s
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=C3=A4t Hamburg
Fachbereich Informatik
Vogt-= K=C3=B6lln-Stra=C3=9Fe 30
22527 Hamburg
Deutschland

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000009205bc05c28c814d--