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 > > TLS@ietf.org <mailto:TLS%40ietf.org> > > https://www.ietf.org/mailman/listinfo/tls > > > > > -- > 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@ietf.org <mailto:TLS%40ietf.org> > https://www.ietf.org/mailman/listinfo/tls > > Attachments: > * OpenPGP_signature _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
