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

[Martin Thomson <[e-mail]>]

It seems to me like the next step is to share a paper, ideally in the form of an internet-draft, that describes more precisely what you would like to see happen.

On Wed, May 26, 2021, at 18:48, Florian Wilkens wrote:
> Dear all,
> 
> first, we want to thank you for your feedback, it is much appreciated!
> We wanted to briefly clarify some details about our idea:
> 
> - AEAD/non-AEAD: completely true. We were mainly looking at ciphers from
> TLS 1.3 that all use keys and IVs but that is of course unrelated to
> AEAD as a concept.
> - registering our own ciphersuite: while that is certainly an option, we
> are not really advocating for new cipher suites but rather keeping at
> least a single cipher suite in the standard that allows for separate
> keys for confidentiality and integrity.
> 
> We also tried to catch up on the discussions in 2016/2017 around
> industry concerns to TLS 1.3 (regarding PFS and static key exchanges).
> While some parts are certainly similar, we think our approach is
> different, as we do not aim to weaken the overall connection security
> but rather keep the client machine in control of the key material (as it
> is already with current TLS).
> 
> To be clear, our prototype already works on current TLS as is. The
> client sends either the pre-master-secret or derived session keys to the
> network monitor. Naturally, this will continue to work with future TLS
> versions as the client ultimately possesses all required key material.
> There are certainly scenarios in which an enterprise might still want to
> deploy an MitM proxy at the network edge to retain more control, however
> our approach is able to avoid the disadvantages induced by these
> proxies. In fact multiple commercial offerings (including one proposed
> on the linked NIST workshop) already do exactly what we propose and hand
> over all key material to a central party for decryption. Whether this is
> good practice, is a discussion for another time, but it is already
> happening anyway and there is demand for these solutions.
> 
> Our prototype is able to slightly decrease the attack surface on the
> network monitor, as it is not able to forge valid packets in the same
> connection due to the missing integrity key. The impact on application
> protocols such as HTTP is a problem, however this problem is also
> present on both commercial solutions that exfiltrate all key material
> from the client and MitM proxies.
> 
> Overall, we just wanted to raise some awareness for the use case as we
> felt that a small change to a future TLS standard could achieve some
> slight improvements regarding the network monitor. However, if that does
> not match the WG's opinion that is certainly okay, as we can work with
> current TLS.
> 
> So again thank you for you feedback!
> Cheers,
> Florian
> 
> 
> On 17.05.21 18:23, 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] https://arxiv.org/abs/2104.09828
> > [2] https://zeek.org
> > [3] https://github.com/zeek/zeek/pull/1518
> > 
> > 
> > _______________________________________________
> > TLS mailing list
> > [e-mail] <mailto:TLS%40ietf.org>
> > https://www.ietf.org/mailman/listinfo/tls
> > 
> 
> 
> -- 
> M.Sc. Florian Wilkens
> Research Associate
> Phone: [phone]
> 
> IT-Sicherheit und Sicherheitsmanagement (ISS)
> Universität Hamburg
> Fachbereich Informatik
> Vogt-Kölln-Straße 30
> 22527 Hamburg
> Deutschland
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail] <mailto:TLS%40ietf.org>
> https://www.ietf.org/mailman/listinfo/tls
> 
> Attachments:
> * OpenPGP_signature