Hi Tom, Apologies again for missing your emails earlier. We are making a new revision to address your comments. Please see inline below...
On Jun 24, 2020, at 4:31 AM, tom petch <[email protected]<mailto:[email protected]>> wrote: From: OPSEC <[email protected]<mailto:[email protected]>> on behalf of [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: 24 June 2020 00:56 Nancy Some general thoughts. You assume that the server has an X.509 certificate. Probably the right approach but I think that you need an Assumptions in s.1 ruling out PSK etc. Good points. Handling PSK will require some prerequisites, to be on path and proxy the previous sessions. Will clarify it. You assume that the client does not have a certificate; ditto. Correct. Client authentication is possible but requires additional provisioning. It does not change the list of operational practices. The problem statement is that TLS1.3 cannot do what TLS1.2 can and that is not explained until s.4. I think that some of that if not the whole section belongs earlier, section 1 or 2. Agreed that’s a more natural flow. Will move s.4 before discussing the list of practices. I was going to ask if encrypted SNI belong in this I-D somewhere then saw it in the references. I think that you need to say more than [ESNI] ESNI/ECH impact would need more study. You are right we should cover it for all the scenarios. At high level, the effectiveness of passive inspection will be significantly reduced, and likely outbound proxy won’t be possible unless additional provisioning is in place. Will capture it at this level and add more analysis as the spec finalizes and more is understood from the deployment. Does channel binding belong in here somewhere? I saw an I-D to provide channel binding for TLS 1.3 on the grounds that it no longer worked which is something I had not realised about TLS1.3. Will leave it for Nancy to reply. In passing, you have a mix of TLS 1.3 and TLS v1.3; I prefer the former but prefer consistency more! Certainly! Corrected. Best, -Eric Tom petch A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure WG of the IETF. Title : Impact of TLS 1.3 to Operational Network Security Practices Authors : Nancy Cam-Winget Eric Wang Roman Danyliw Roelof DuToit Filename : draft-ietf-opsec-ns-impact-00.txt Pages : 17 Date : 2020-06-23 Abstract: Network-based security solutions are used by enterprises, the public sector, internet-service providers, and cloud-service providers to both complement and enhance host-based security solutions. As TLS is a widely deployed protocol to secure communication, these network- based security solutions must necessarily interact with it. This document describes this interaction for current operational security practices and notes the impact of TLS 1.3 on them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ns-impact/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsec-ns-impact-00 https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ns-impact-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
