Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-ns-impact-00.txt

From: "Eric Wang (ejwang)" <[email-masked]>
Date: Tue, 28 Jul 2020 20:46:29 +0000

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-masked]<mailto:[email-masked]>> wrote:

From: OPSEC <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
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-masked]
https://www.ietf.org/mailman/listinfo/opsec

_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 28 Jul 2020 23:46:07 +0000

Hi Tom,
With respect to the channel binding, it is true that the bindings defined in RFC 5929 don’t quite map to TLS 1.3 well (especially tls-unique); the draft https://tools.ietf.org/id/draft-ietf-kitten-tls-channel-bindings-for-tls13-00.html creates a new TLS 1.3 compatible type which puts the considerations based on the older RFCs.  So, I would think the same considerations would apply and don’t see how that would have an impact on proxies other than what is noted in RFC 5929.

Best, Nancy

From: OPSEC <[email-masked]> on behalf of "Eric Wang (ejwang)" <ejwang=[email-masked]>
Date: Tuesday, July 28, 2020 at 1:46 PM
To: tom petch <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-ns-impact-00.txt

Hi Tom,

Nancy

Some general thoughts.

Certainly!  Corrected.

Best,
-Eric

Tom petch

Abstract: