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

[Darin Pettis <[e-mail]>]

…use case*

Thanks in advance,
Darin Pettis

On Mon, May 17, 2021 at 3:33 PM Darin Pettis <[e-mail]>
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 <[e-mail]> 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 <
>> [e-mail]> 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: [phone]
>>>
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>