…use case* Thanks in advance, Darin Pettis
On Mon, May 17, 2021 at 3:33 PM Darin Pettis <[email protected]> wrote: > 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 protected]> 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 < >> [email protected]> 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ät Hamburg >>> Fachbereich Informatik >>> Vogt-Kölln-Straße 30 >>> <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> >>> >>> _______________________________________________ >>> TLS mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/tls >>> >> _______________________________________________ >> TLS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tls >> >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
