Subject: [OPSEC] Request comments and discussion for draft-camwinget-tls-ns-impact

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 4 Mar 2020 02:18:05 +0000

Hello OPSEC participants,

Given the trends to improve on security and privacy, we thought it important to also
document how network security solutions are used and how they interact with TLS.
We have submitted https://datatracker.ietf.org/doc/draft-camwinget-tls-ns-impact/
and believe it is appropriate to discuss in this working group.

Warm regards,  Nancy (and my co-authors)

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 4 Mar 2020 07:42:18 +0000

Dear Nancy,

I have read the document and I like it, a very well written and useful
catalog of TLS-specific security functions and how they are affected
by TLS 1.3. Thanks for putting this together.

/js

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 4 Mar 2020 10:34:43 -0500

> and believe it is appropriate to discuss in this working group.

Thank you for this document -- I found it to be nicely readable and
understandable -- other than one major questions / point.

I'm sure I'm going to mess up the terminology horribly here -
apologies in advance...

Section 3:
" To achieve this, a TLS Proxy must be able to present a valid X.509
   certificate to the TLS client to appear as a valid TLS Server;
   similarly, the client must be able to validate the X.509 certificate
   using the appropriate trust anchor for that TLS connection."

I'm seen at least 2 deployment types for this sort of inspection - the
first is where a client is informed that there is a proxy server that
they need to send their traffic through -- i.e the system or browser
is configured with a proxy server (OS X called this "Secure Web
Proxy"), and is configured with something like
https://proxy.example.com:8080.

The second is a security appliance which does MiTM type stuff, and the
client installs a corporate CA certificate.
These are two very very different deployment scenarios, and the
"valid" part in "valid X.509 certificate" have very different
meanings[0]. I think that it would be useful to clearly outline these
two methods of watching "encrypted" user traffic, and clarify which
one(s) you are talking about.
The sentence: "This TLS Proxy is a transparent hop on the packet path;
and where necessary, preserves the client's and server's original IP
address and the intended source and destination TCP ports." implies
only the second, but I think it would be useful to be much clearer in
the introduction...

W
[0]: Yup, technically they are both valid, but (at least in my
opinion) the second is much less so :-P

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 4 Mar 2020 23:33:04 +0000

Many thanks for the quick response Jürgen!  And of course, as authors, we would like to see
If there is interest in the WG to adopt the document; barring we reasonably address all feedback.

Warm regards, Nancy

On 3/3/20, 11:42 PM, "Schönwälder, Jürgen" <[email-masked]> wrote:

    Dear Nancy,

    /js