Subject: [TLS] Call For Adoption: draft-wang-opsec-tls-proxy-bp

From: Ron Bonica <[email-masked]>
Date: Sun, 19 Jul 2020 17:34:54 +0000

Folks,

This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp<https://datatracker.ietf.org/doc/draft-wang-opsec-tls-proxy-bp/>.

Please send comments to [email-masked]<mailto:[email-masked]> by August 3, 2020.

                                                                Ron

Juniper Business Use Only

---

From: Jen Linkova <[email-masked]>
Date: Thu, 23 Jul 2020 11:30:08 +1000

One thing to add here: the chairs would like to hear active and
explicit support of the adoption. So please speak up if you believe
the draft is useful and the WG shall work on getting it published.

On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
<rbonica=[email-masked]> wrote:
>
> Folks,
>
>
>
> This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp.
>
>
>
> Please send comments to [email-masked] by August 3, 2020.
>
>
>
>                                                                 Ron
>
>
>
>
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

--
SY, Jen Linkova aka Furry

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Sat, 25 Jul 2020 03:04:08 +0000

This draft provides guidelines for TLS proxy implementations; given current activities using TLS with proxying I believe this document is useful for the community and implementors.  I support its adoption.

Warm regards, Nancy

On 7/22/20, 6:31 PM, "OPSEC on behalf of Jen Linkova" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Jul 2020 15:07:09 +0100

I oppose adoption. While there could be some minor benefit
in documenting the uses and abuses seen when mitm'ing tls,
I doubt that the effort to ensure a balanced document is at
all worthwhile. The current draft is too far from what it'd
need to be to be adopted.

Send to ISE.

S.

On 23/07/2020 02:30, Jen Linkova wrote:
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Eric Wang (ejwang)" <[email-masked]>
Date: Mon, 27 Jul 2020 05:14:56 +0000

Hi Stephen,

Thanks for your feedback.  I’d like to clarify, given the reality today that CDN/load balancers and enterprises deploy TLS proxy, this draft is merely to lay out a baseline guidance to the implementation and operation[1].  It is not meant to analyze "use and abuse" or "pros and cons", for which there were many discussions and publications in the past and the draft references some of them.

Given the progression of TLS and its wide adoption, the use of TLS proxy is also becoming a practice and is growing in enterprise/CDN.  We felt it’s a good thing for the community to define a set of best practices for practitioners to reference when implementing and operating TLS proxy.  Without one, TLS deployments would be negatively impacted.  Also, given some of the implementation inconsistencies noted during the TLS 1.3 evolution, we felt a bcp guide could help the community moving forward.  That’s the purpose of this draft.

Best,
-Eric

[1] https://tools.ietf.org/html/draft-wang-opsec-tls-proxy-bp-00#section-1

On Jul 25, 2020, at 7:07 AM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

Send to ISE.

S.

On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
<rbonica=[email-masked]<mailto:rbonica=[email-masked]>> wrote:

Folks,

                                                               Ron

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

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

<0x5AB2FAF17B172BEA.asc>_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 27 Jul 2020 12:19:44 +0000

I support Stephen and oppose adoption. IMHO, this is not a technology that IETF should standardize.

On 7/25/20, 10:07, "TLS on behalf of Stephen Farrell" <[email-masked] on behalf of [email-masked]> wrote:

    Send to ISE.

    S.

---

From: Ira McDonald <[email-masked]>
Date: Mon, 27 Jul 2020 08:26:56 -0400

I support Stephen and Uri and oppose adoption.

On Mon, Jul 27, 2020 at 8:20 AM Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

> On 7/25/20, 10:07, "TLS on behalf of Stephen Farrell" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 27 Jul 2020 12:37:12 +0000

Not adopting this seems to be ignoring reality. There are places which use TLS intermediaries. Are those users not welcome here?

I support adoption.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jul 2020 13:55:02 +0100

Hi Rich,

On 27/07/2020 13:37, Salz, Rich wrote:
> Not adopting this seems to be ignoring reality. 

That depends on the "this" though. This "this" seems
to me to be very much ok with mitm'ing, while doing
a little bit to recognise the downsides of mitm'ing.
I'm not objecting to attempts to describe reality,
but am rather arguing that achieving rough consensus
on something starting from that "this" is not worth
the effort, as we've I think seem demonstrated a
couple of time recently.

Cheers,
S.

> There are places
> which use TLS intermediaries. Are those users not welcome here?
> 
> I support adoption.
> 
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 27 Jul 2020 12:55:36 +0000

The document is not imposing any standards but rather provide guidelines for those implementing TLS proxies;  given that proxies will continue to exist I'm not sure why there is a belief that the IETF should ignore this.

Warm regards, Nancy

On 7/27/20, 5:20 AM, "OPSEC on behalf of Blumenthal, Uri - 0553 - MITLL" <[email-masked] on behalf of [email-masked]> wrote:

    
        Send to ISE.
    
        S.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 27 Jul 2020 13:18:16 +0000

Nancy,

Understood. However, in this particular case, instead of "if you want to do this, then do it that way, and I'll help you inter-operate" I prefer "if you want to do this - you're on your own, don't seek a blessing or advice from me".

Regards,
Uri

On 7/27/20, 08:56, "Nancy Cam-Winget (ncamwing)" <[email-masked]> wrote:

    Warm regards, Nancy

            Send to ISE.

            S.

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 27 Jul 2020 09:30:35 -0400

I'm concerned about this work happening outside the TLS working group.  For
example, the question of proper handling of TLS extensions is not addressed
at all in this draft, and has significant security and functionality
implications.  There are various other tricky protocol issues (e.g. version
negotiation, TLS 1.3 record padding, TLS 1.3 0-RTT vs. TLS 1.2 False Start,
round-trip deadlock when buffers fill, ticket (non-)reuse, client
certificate linkability pre-TLS-1.3, implications of SAN scope of
synthesized certificates) that could arise and are going to be difficult to
get right in any other WG.

The title "TLS Proxy Best Practice" implies that it is possible to proxy
TLS correctly, and that this document is the main source for how to do it.
I think the TLS WG is the right place to make those judgments.  For the
OpSec group, I think a more appropriate draft would be something like "TLS
Interception Pitfalls", documenting the operational experience on failure
modes of TLS interception.

On Mon, Jul 27, 2020 at 8:57 AM Nancy Cam-Winget (ncamwing) <ncamwing=
[email-masked]> wrote:

> The document is not imposing any standards but rather provide guidelines
> for those implementing TLS proxies;  given that proxies will continue to
> exist I'm not sure why there is a belief that the IETF should ignore this.
>
> Warm regards, Nancy
>
> On 7/27/20, 5:20 AM, "OPSEC on behalf of Blumenthal, Uri - 0553 - MITLL" <
> [email-masked] on behalf of [email-masked]> wrote:
>

---

From: Nick Harper <[email-masked]>
Date: Mon, 27 Jul 2020 07:11:55 -0700

As currently written, this draft has multiple problems.

Section 4 decides not to repeat the Protocol Invariants described in
section 9.3 of RFC 8446. However, further sections are written assuming
that a proxy acts in a way contrary to those Protocol Invariants. One such
example is section 4.2 in this draft. It describes how a proxy might
generate its list of cipher suites by modifying the client's list. A proxy
that copies the cipher suites from the client-initiated ClientHello into
its own ClientHello is violating the 1st and 3rd points of the TLS 1.3
Protocol Invariants. For a best practices document, I think it would be
reasonable to reiterate the Protocol Invariants.

In addition to reiterating the Protocol Invariants, it should also
summarize the advice from the cited papers SECURITY_IMPACT and
APPLIANCE_ANALYSIS. One of the problems pointed out by those papers is that
TLS proxies will make connections to a server that presents a certificate
the client wouldn't accept, but because of the proxy, the client isn't
aware of the certificate issues. I don't see this issue addressed at all in
the draft. (A similar issue with the server selecting a weak cipher suite
is possibly implied by section 4.2, but it is not spelled out well.)

If this draft is adopted, it needs to say the following things, which it
currently doesn't.

- When a TLS proxy generates its ClientHello, it should be created
independently from the client-initiated ClientHello. The proxy MAY choose
to omit fields from its ClientHello based on the client-initiated
ClientHello, but it MUST NOT add fields to its ClientHello based on the
client-initiated ClientHello. This is effectively a restatement of the 1st
(a client MUST support all parameters it sends) and 3rd (it MUST generate
its own ClientHello containing only parameters it understands) points of
the TLS 1.3 Protocol Invariants.

- If a proxy chooses to conditionally proxy TLS connections and needs more
information than what is contained in the client-initiated ClientHello,
then the only way to make that decision is to send its own ClientHello to
the server the client is connecting to and use information observed on that
connection to make the decision to proxy the pending connection.

- If a proxy chooses to not proxy some TLS connections, the proxy will fail
open. The only way to avoid failing open is to proxy all connections.

On Mon, Jul 27, 2020 at 6:31 AM Ben Schwartz <bemasc=
[email-masked]> wrote:

> I'm concerned about this work happening outside the TLS working group.
> For example, the question of proper handling of TLS extensions is not
> addressed at all in this draft, and has significant security and
> functionality implications.  There are various other tricky protocol issues
> (e.g. version negotiation, TLS 1.3 record padding, TLS 1.3 0-RTT vs. TLS
> 1.2 False Start, round-trip deadlock when buffers fill, ticket (non-)reuse,
> client certificate linkability pre-TLS-1.3, implications of SAN scope of
> I think the TLS WG is the right place to make those judgments..  For the
>> On 7/27/20, 5:20 AM, "OPSEC on behalf of Blumenthal, Uri - 0553 - MITLL"
>> <[email-masked] on behalf of [email-masked]> wrote:
>>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 27 Jul 2020 14:21:24 +0000

>    Understood. However, in this particular case, instead of "if you want to do this, then do it that way, and I'll help you inter-operate" I prefer "if you want to do this - you're on your own, don…

So you don't feel that community is welcome here at the IETF, or that you won't personally participate?

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 27 Jul 2020 14:30:59 +0000

As my personal opinion - both.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 27 Jul 2020 17:39:04 +0000

As written, the document provides a basic/general description of MITM proxies. It mentions some of the issues (client auth, handling of 0-RTT application data, single point of failure, updates/patches, risks of disclosure of PII/PHI), but does not really provide alternatives or specific solutions. I oppose adoption of this document in its current shape.

Some specific issues:

  *   The document does not describe alternatives to MITM proxies.
  *   Section 4.1.2 “Inbound provisioning” does not discuss security and operational issues around server key sharing with the proxy. No real discussion of short-lived creds and “keyless” scenarios.
  *   Section 4.2 “Maintain security posture and limit modifications” seems to recommend modifications to the ClientHello, rather than having the proxy generate a new ClientHello. Proxies sending ClientHellos they did not generate are a common cause of interop issues.
  *   Section 4.2 also explicitly allows completely insecure configurations:

      “TLS proxy stacks MAY provide user configurable options, such as an
   option to accept self-signed server certificates, an option to let
   the handshake continue with expired but otherwise valid server
   certificates, etc.”

Cheers,

Andrei

From: TLS <[email-masked]> On Behalf Of Nick Harper
Sent: Monday, July 27, 2020 7:12 AM
To: Ben Schwartz <bemasc=[email-masked]>
Cc: Jen Linkova <[email-masked]>; Nancy Cam-Winget (ncamwing) <ncamwing=[email-masked]>; OpSec Chairs <[email-masked]>; OPSEC <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

Section 4 decides not to repeat the Protocol Invariants described in section 9.3 of RFC 8446. However, further sections are written assuming that a proxy acts in a way contrary to those Protocol Invariants. One such example is section 4.2 in this draft. It describes how a proxy might generate its list of cipher suites by modifying the client's list. A proxy that copies the cipher suites from the client-initiated ClientHello into its own ClientHello is violating the 1st and 3rd points of the TLS 1.3 Protocol Invariants. For a best practices document, I think it would be reasonable to reiterate the Protocol Invariants.

In addition to reiterating the Protocol Invariants, it should also summarize the advice from the cited papers SECURITY_IMPACT and APPLIANCE_ANALYSIS. One of the problems pointed out by those papers is that TLS proxies will make connections to a server that presents a certificate the client wouldn't accept, but because of the proxy, the client isn't aware of the certificate issues. I don't see this issue addressed at all in the draft. (A similar issue with the server selecting a weak cipher suite is possibly implied by section 4.2, but it is not spelled out well.)

If this draft is adopted, it needs to say the following things, which it currently doesn't.

- When a TLS proxy generates its ClientHello, it should be created independently from the client-initiated ClientHello. The proxy MAY choose to omit fields from its ClientHello based on the client-initiated ClientHello, but it MUST NOT add fields to its ClientHello based on the client-initiated ClientHello. This is effectively a restatement of the 1st (a client MUST support all parameters it sends) and 3rd (it MUST generate its own ClientHello containing only parameters it understands) points of the TLS 1.3 Protocol Invariants.

- If a proxy chooses to conditionally proxy TLS connections and needs more information than what is contained in the client-initiated ClientHello, then the only way to make that decision is to send its own ClientHello to the server the client is connecting to and use information observed on that connection to make the decision to proxy the pending connection.

- If a proxy chooses to not proxy some TLS connections, the proxy will fail open. The only way to avoid failing open is to proxy all connections.

On Mon, Jul 27, 2020 at 6:31 AM Ben Schwartz <bemasc=[email-masked]<mailto:[email-masked]>> wrote:
I'm concerned about this work happening outside the TLS working group.  For example, the question of proper handling of TLS extensions is not addressed at all in this draft, and has significant security and functionality implications.  There are various other tricky protocol issues (e.g. version negotiation, TLS 1.3 record padding, TLS 1.3 0-RTT vs. TLS 1.2 False Start, round-trip deadlock when buffers fill, ticket (non-)reuse, client certificate linkability pre-TLS-1.3, implications of SAN scope of synthesized certificates) that could arise and are going to be difficult to get right in any other WG.

The title "TLS Proxy Best Practice" implies that it is possible to proxy TLS correctly, and that this document is the main source for how to do it.  I think the TLS WG is the right place to make those judgments..  For the OpSec group, I think a more appropriate draft would be something like "TLS Interception Pitfalls", documenting the operational experience on failure modes of TLS interception.

On Mon, Jul 27, 2020 at 8:57 AM Nancy Cam-Winget (ncamwing) <ncamwing=[email-masked]<mailto:[email-masked]>> wrote:
The document is not imposing any standards but rather provide guidelines for those implementing TLS proxies;  given that proxies will continue to exist I'm not sure why there is a belief that the IETF should ignore this.

Warm regards, Nancy

On 7/27/20, 5:20 AM, "OPSEC on behalf of Blumenthal, Uri - 0553 - MITLL" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    On 7/25/20, 10:07, "TLS on behalf of Stephen Farrell" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

        Send to ISE.

        S.

        On 23/07/2020 02:30, Jen Linkova wrote:
        > <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
        >>
        >> Folks,
        >>
        >>
        >>
        >> https://www.ietf.org/mailman/listinfo/opsec<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsec&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C23d5e7f8ac1047d98fe108d8323724a6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637314559736707680&sdata=P0RE3llePUKRCp8og1EVm7G45N1UujWmY6aTOTRBGUE%3D&reserved=0>
        >
        >
        >
        > --
        > https://www.ietf.org/mailman/listinfo/tls<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C23d5e7f8ac1047d98fe108d8323724a6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637314559736712671&sdata=vmUnm3RlE4rBBLF6oLlh%2B%2FzReeorfWNrbczvyVV7cXI%3D&reserved=0>
        >

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C23d5e7f8ac1047d98fe108d8323724a6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637314559736717662&sdata=2rDSL3aK31w3fXWvrqAmE5frKSTbaABPNls9H2ZFABU%3D&reserved=0>
_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C23d5e7f8ac1047d98fe108d8323724a6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637314559736722653&sdata=%2BzrWj9rV6e4ewc%2BZJxS4PPFgZRcoi%2FB0sdAQKMPNfLw%3D&reserved=0>

---

From: Roelof duToit <[email-masked]>
Date: Mon, 27 Jul 2020 15:09:59 -0400

As co-author I support adoption of the draft and appreciate the feedback.

The authors agreed at the time that the OPSEC WG charter would better match our intention of documenting the BCP for TLS proxies given that the TLS WG charter places more of an emphasis on the TLS protocol.  Having said that, we do also agree that the TLS WG should be involved.  The recommendation from the TLS WG chairs was to continue in OPSEC and to cc the TLS WG.

--Roelof

> On Jul 27, 2020, at 9:30 AM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> On Mon, Jul 27, 2020 at 8:57 AM Nancy Cam-Winget (ncamwing) <ncamwing=[email-masked] <mailto:[email-masked]>> wrote:
> On 7/27/20, 5:20 AM, "OPSEC on behalf of Blumenthal, Uri - 0553 - MITLL" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> 
>     On 7/25/20, 10:07, "TLS on behalf of Stephen Farrell" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>         > <rbonica=[email-masked] <mailto:[email-masked]>> wrote:
>         >>
>         >> Folks,
>         >>
>         >>
>         >>
>         >> Please send comments to [email-masked] <mailto:[email-masked]> by August 3, 2020.
>         >>
>         >>
>         >>
>         >>                                                                 Ron
>         >>
>         >>
>         >>
>         >>
>         >> [email-masked] <mailto:[email-masked]>
>         >> https://www.ietf.org/mailman/listinfo/opsec <https://www.ietf.org/mailman/listinfo/opsec>
>         > 
>         > 
>         > 
>         > --
>         > [email-masked] <mailto:[email-masked]>
>         > https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
>         > 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: Roelof duToit <[email-masked]>
Date: Mon, 27 Jul 2020 16:32:14 -0400

Thank you Andrei.

> The document does not describe alternatives to MITM proxies.

The [SECURITY_IMPACT] paper mentions alternatives, and we could certainly include a high-level summary of some of those even though our intention was to document the BCP for TLS proxies where the reader is considering a TLS proxy network function.   If we do include an expanded section on alternatives then it should also reference the capabilities and limitations of endpoint-only security solutions (reference: https://datatracker.ietf.org/doc/html/draft-taddei-smart-cless-introduction-03 <https://datatracker.ietf.org/doc/html/draft-taddei-smart-cless-introduction-03>)

> Section 4.1.2 “Inbound provisioning” does not discuss security and operational issues around server key sharing with the proxy. No real discussion of short-lived creds and “keyless” scenarios.

Sections 4.1 and 4.12 provide guidelines and leaves the implementation up to the developer.  That is not to say that we cannot be more specific about key sharing and key storage for inbound solutions.   We could certainly mention draft-ietf-tls-subcerts as well.

> Section 4.2 “Maintain security posture and limit modifications” seems to recommend modifications to the ClientHello, rather than having the proxy generate a new ClientHello. Proxies sending ClientHellos they did not generate are a common cause of interop issues.

That section needs more clarification.  We are most certainly not proposing that TLS proxies should forward the original ClientHello and are aware of the risks - especially when RSA key exchange is used.  The intention of section 4.2 is for the TLS proxy to base certain attributes of the generated ClientHello on what was advertised by the client, with the goal of maintaining the security posture.

> Section 4.2 also explicitly allows completely insecure configurations:

That paragraph needs examples.   One such example is where device-to-device communication in the enterprise traverses the TLS proxy and where said devices must be excluded from further inspection based on a combination of policy attributes - it is not always practical to update the devices.

---

From: "Eric Wang (ejwang)" <[email-masked]>
Date: Mon, 27 Jul 2020 21:20:57 +0000

Hi Nick,

Many thanks for the detailed comments.

In general, the draft tried not to repeat the TLS RFCs.  From section 4.2, “Because a TLS proxy effectively builds two TLS sessions, one with a TLS client and one with a server respectively, … The TLS server and client stacks in the TLS proxy MUST be conformant to [RFC8446] and [RFC5246].”

It was the intention with Protocol Invariants as well, but it appears the text caused some confusion in S 4.2. We will clarify it, and it is worthwhile to capture points from the cited papers too.

Section 5.3<https://tools.ietf.org/html/draft-wang-opsec-tls-proxy-bp-00#section-5.3> describes selective decryption which is related to your last two points.  Will update it with your comments (there are techniques to “fail open” from proxy but only possible before certain stage of the handshake).

Best,
-Eric

On Jul 27, 2020, at 7:11 AM, Nick Harper <nharper=[email-masked]<mailto:nharper=[email-masked]>> wrote:

Warm regards, Nancy

        Send to ISE.

        S.

---

From: "Eric Wang (ejwang)" <[email-masked]>
Date: Mon, 27 Jul 2020 23:48:47 +0000

Thanks you Rich.  Obviously I support the adoption as one of the authors. But more importantly, the reality of growing TLS proxy was the driver for starting the draft.  That has been a sidecar with the progression of TLS and its wide deployment.  We felt the lack of a baseline bcp is going to hurt the security posture of TLS rather than driving the intermediary away.

Best,
-Eric

On Jul 27, 2020, at 5:37 AM, Salz, Rich <rsalz=[email-masked]<mailto:rsalz=[email-masked]>> wrote:

I support adoption.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Jul 2020 01:35:47 +0100

On 28/07/2020 00:48, Eric Wang (ejwang) wrote:
> We felt the lack of a
> baseline bcp is going to hurt the security posture of TLS rather than
> driving the intermediary away.

That makes no sense to me.

Adopting this draft will require eliminating all such
gibberish and instead finding text that can garner IETF
consensus. I really do not think that effort is worth
the significant cost for anyone involved, pro-MITM or
not.

S.

---

From: Roelof duToit <[email-masked]>
Date: Mon, 27 Jul 2020 22:44:47 -0400

RFC 8446, section 9.3 states:
Note that TLS's protocol requirements and security analysis only
apply to the two connections separately.  Safely deploying a TLS
terminator requires additional security considerations which are
beyond the scope of this document.

The context of that paragraph is "A middlebox which terminates a TLS connection" and it implies that there are undocumented security considerations.
The tls-proxy-bp draft is a contribution towards that goal and we think it is worth the effort.

--Roelof

> On Jul 27, 2020, at 8:35 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
>

---

From: Ashutosh Singh <[email-masked]>
Date: Mon, 27 Jul 2020 22:22:47 -0700

I agree with the proposed approach and I also believe in discussion around
safe and responsible middlebox deployment. I support the adoption of this
draft!

Regards
-Ashu

On Mon, Jul 27, 2020 at 7:45 PM Roelof duToit <[email-masked]> wrote:

> *Note that TLS's protocol requirements and security analysis only*
> *apply to the two connections separately.  Safely deploying a TLS*
> *terminator requires additional security considerations which are*
> *beyond the scope of this document.*
>
> The context of that paragraph is "*A middlebox which terminates a TLS
> connection*" and it implies that there are *undocumented* security
> considerations.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 28 Jul 2020 17:25:48 +1000

On Mon, Jul 20, 2020, at 03:34, Ron Bonica wrote:
> This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp 
> <https://datatracker.ietf.org/doc/draft-wang-opsec-tls-proxy-bp/>.

I think that others have said enough about the wisdom of adoption of the approach.  I agree with them, but recognize the right to disagree.

Even if we were to accept that it is a good idea to document best practices for TLS proxying, this document is not currently a good basis for that work.  The introduction is a little deceptive, in that it says that it is about proxying, but there are numerous places in the draft that talk about selective proxying or some amount of forwarding and inspection.  Those practices would require design work.  From what I can infer from the draft, it often assumes the same sort of bad designs that are specifically identified elsewhere as having bad characteristics.

As it is, the draft is not consistent in terms of its approach and scope.  If the goal is to describe pure proxying (a TLS server and a TLS client that intermediate), then it needs a good edit.  If the goal is to describe selective proxying or selective forwarding and modification of TLS messages, then that is a much bigger task.  What are often stated in the draft as requirements around this points are in fact assumptions.  And many of them bad, as others have stated.

--- More detail follows

Intermediaries if this nature are added to effect some sort of centralized control.  This seems to be the primary motivation here also.  If we accept that this is happening, it is important to note the operational effects of that.  Not just on those who have this desire, but on all of those affected.

There is some text about the effect this might have on the ability of clients or servers to introduce new features in Section 4.8.  This is nowhere near sufficient.  By breaking the connection the number of stack layers that are exposed to potential interference, the consequences are not limited to TLS.

Creating negative externalities contributes to TLS interception being despised.  If the intent is to help, then this doesn't go nearly far enough in describing the secondary effects a proxy might cause.

Probably the worst problem is rooted in Section 5.1.  The introduction establishes this as being about proxying, but there are several places that talk about not-proxying sometimes.

Selective non-proxying opens the document up to a whole new set of problems that arise from poor designs for deciding not to proxy.  There is not nearly enough detail here to address this problem properly.  A "good" design for selective TLS proxying does not seem to be the basis of the recommendations.  I'll give a few examples of problems.

>From the Section 4.8 again:

> the TLS proxy MUST conduct proper TLS protocol checks to avoid false identification of TLS handshakes, while taking special care not to contribute to protocol ossification.  

This practice has been directly responsible for more ossification than intermediation, no matter what qualification exists.  

If per-destination not-proxying is required, the proxy can connect to a server, determine that the server is on a non-proxy list, and then complete the handshake with the client (with a caveat regarding ECH here).  I can guess why this doesn't happen (it's expensive and see also Section 5.4), but that doesn't excuse the practice.

The following text from Section 5.3 is deeply problematic:

   A decryption policy decision MAY be made based on the server
   certificate or other trustworthy parameters.  To verify possession of
   private keys that are associated with a particular server
   certificate, the proxy SHOULD complete an out-of-band TLS handshake
   with the same TLS server IP address and TCP port as targeted by the
   TLS client.

It is possible that the authors misunderstand how TLS works, but this check won't work.  Not only because TLS 1.3 encrypts information, but because this is only necessary if the proxy forwards a ClientHello from the client to the server.  At that point, it is too late and the damage has been done (see Andrei's review).

There are a bunch of places where pure proxying - as described in the introduction - is not assumed.  This leads to the same problems already cited.  For instance, in Section 4.2:

> The proxy MAY remove cipher suites from a client-initiated Client Hello message, add new cipher suites, and re-order them in the proxy-initiated Client Hello message.

---

From: "Arnaud.Taddei.IETF" <[email-masked]>
Date: Tue, 28 Jul 2020 08:35:44 +0000

I strongly support this work as it represents capabilities that are being developed, deployed and used in practice. It has good intentions and provides a good approach in the context of defense in depth approaches. No security cannot be just on both ends of the communication. One can dream about it but that is not how reality is. Removing this possibility is a limit to the overall defense.

I do not understand the reasons behind ignoring reality and the IETF would have, in my naive mind, a strong interest in getting this work under good community adoption so that it is kept in good control with validated best practices. Everyone would win.

I support this draft

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday 23 July 2020 03:30, Jen Linkova <[email-masked]> wrote:

> rbonica=[email-masked] wrote:
>
> > Folks,

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 28 Jul 2020 04:12:55 -0700

On Tue, Jul 28, 2020 at 12:26 AM Martin Thomson <[email-masked]> wrote:

> It is possible that the authors misunderstand how TLS works, but this
> check won't work.  Not only because TLS 1.3 encrypts information, but
> because this is only necessary if the proxy forwards a ClientHello from the
> client to the server.

In addition, this check is susceptible to trivial forwarding attack in
which the server in question forwards the data to the true server.

-Ekr

---

From: tom petch <[email-masked]>
Date: Tue, 28 Jul 2020 16:15:18 +0000

From: OPSEC <[email-masked]> on behalf of Nancy Cam-Winget (ncamwing) <ncamwing=[email-masked]>
Sent: 25 July 2020 04:04

<tp>

OPPOSE

There is a place for this I-D as and when the authors respond to the unanswered comments on the last I-D that they got adopted in OPSEC.   If they do not acknowledge, let alone respond to, comments then that should be a bar to new work because as and when the comments are addressed there are more comments waiting.

I do see a revised I-D of that other I-D in among the vast number that have appeared as they always do around the time of an IETF, but given that it is one among hundreds it will be a while before I am ready with more comments on that other I-D. 

Tom Petch

Warm regards, Nancy

---

From: "Eric Wang (ejwang)" <[email-masked]>
Date: Tue, 28 Jul 2020 21:18:58 +0000

Thank you for the detailed comments.

The scope of the document is limited to proxy at the TLS layer.  Explicitly out of the scope is inspection of the proxied record data.   Will clean up derivations from this scope.

It was the intention to cover selective proxying however, because that is a practical requirement for an actual deployment.  The intention was to discuss the TLS layer attributes (e.g. SNI, Server Cert) that could be used as input for the decision.  The document also stated the requirement to gracefully remove the proxy from the session when needed (and possible).  But the criteria for selective proxying decision, being compliance, privacy, risk level,... are out of the scope.  The decision making often falls under the larger “policy” domain and is controlled at system level outside of the proxy.  It also left out discussion on the detailed mechanism which was deemed as implementation specific.

In any case, the proxy has to conduct selective proxying in a safe, non-disruptive manner. This may require more design work as you pointed out.  The document could describe possible mechanisms so that an acceptable practice could be discussed.  We are open to other ways to shape it.

More inline...

On Jul 28, 2020, at 12:25 AM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

--- More detail follows

Indeed it was driven by sort of “centralized control” from the network (including OS stack). The industry has moved to a hybrid model with a combination of endpoint (client, server), application, and network based solutions. Endpoint/App based solution plays an increasingly important role and likely not requiring an intermediary. Meanwhile, network based solution including intermediary continues to be deployed for various reasons. We could add more analysis related a TLS proxy though a full blown discussion would be out of the scope.

From another perspective, the trend calls for more collaboration between the solutions and elements, especially between client apps and the network.  In some sense, this document also surfaces some issues and gaps. A proxy can only operate within the scope specified by the current standards.

Unless I misunderstood it, the document is suggesting the same as you listed.  Basically, the proxy makes a separate connection to the server as a client (“out-of-band” wrt to the originating client-server connection), retrieves the server’s certificate from the proxy-server handshake, and determines whether the server is on a non-proxying list or not.  If on the list, the proxy forwards the originating client CH as is to the server, and steps aways from the originating client-server handshake.

There are additional considerations in this approach (latency etc.). The document intentionally left out the details to implementations, but could also cover them if needed.

Will clean up those texts based on this and other discussions.

Best,
-Eric

---

From: Watson Ladd <[email-masked]>
Date: Tue, 28 Jul 2020 20:23:48 -0400

On Mon, Jul 27, 2020, 1:15 AM Eric Wang (ejwang) <ejwang=
[email-masked]> wrote:

> Hi Stephen,
>
> Thanks for your feedback.  I’d like to clarify, given the reality today
> that CDN/load balancers and enterprises deploy TLS proxy, this draft is
> merely to lay out a baseline guidance to the implementation and
> operation[1].  It is not meant to analyze "use and abuse" or "pros and
> cons", for which there were many discussions and publications in the past
> and the draft references some of them.
>

CDNs are usually aware of application level semantics and have some
interesting security problems when not.

There's no generic safe way to terminate TLS, and that's a real problem for
this draft: it needs to be specific to certain use cases.

> Given the progression of TLS and its wide adoption, the use of TLS proxy
> is also becoming a practice and is growing in enterprise/CDN.  We felt it’s
> a good thing for the community to define a set of best practices for
> practitioners to reference when implementing and operating TLS proxy.
> Without one, TLS deployments would be negatively impacted.  Also, given
> some of the implementation inconsistencies noted during the TLS 1.3
> evolution, we felt a bcp guide could help the community moving forward.
> That’s the purpose of this draft.
>

We've seen middlebox writers ignore black letter extensibility requirements
in the existing RFCs and adopt broken patterns before. Why will another
draft help?

> On Jul 25, 2020, at 7:07 AM, Stephen Farrell <[email-masked]>
> wrote:
>
>

---

From: Nick Harper <[email-masked]>
Date: Tue, 28 Jul 2020 17:34:59 -0700

On Tue, Jul 28, 2020 at 2:19 PM Eric Wang (ejwang) <ejwang=
[email-masked]> wrote:

> The scope of the document is limited to proxy at the TLS layer.
> Explicitly out of the scope is inspection of the proxied record data.
> Will clean up derivations from this scope.
>
> It was the intention to cover selective proxying however, because that is
> a practical requirement for an actual deployment.  The intention was to
> discuss the TLS layer attributes (e.g. SNI, Server Cert) that could be used
> as input for the decision.  The document also stated the requirement to
> gracefully remove the proxy from the session when needed (and possible).
> But the criteria for selective proxying decision, being compliance,
> privacy, risk level,... are out of the scope.  The decision making often
> falls under the larger “policy” domain and is controlled at system level
> outside of the proxy.  It also left out discussion on the detailed
> mechanism which was deemed as implementation specific.
>
> In any case, the proxy has to conduct selective proxying in a safe,
> non-disruptive manner. This may require more design work as you pointed
> out.  The document could describe possible mechanisms so that an acceptable
> practice could be discussed.  We are open to other ways to shape it.
>

An acceptable practice MUST include not violating the protocol invariants
in RFC 8446. It is not possible for a proxy to obey the protocol invariants
and selectively proxy based on the contents of the TLS handshake between
the proxy and the server a client wishes to connect to.

>
> More inline...
>
>
> Probably the worst problem is rooted in Section 5.1.  The introduction
> establishes this as being about proxying, but there are several places that
> talk about not-proxying sometimes.
>
> Selective non-proxying opens the document up to a whole new set of
> problems that arise from poor designs for deciding not to proxy.  There is
> not nearly enough detail here to address this problem properly.  A "good"
> design for selective TLS proxying does not seem to be the basis of the
> recommendations.  I'll give a few examples of problems.
>
> the TLS proxy MUST conduct proper TLS protocol checks to avoid false
> identification of TLS handshakes, while taking special care not to
> contribute to protocol ossification.
>
>
> This practice has been directly responsible for more ossification than
> intermediation, no matter what qualification exists.
>
> If per-destination not-proxying is required, the proxy can connect to a
> server, determine that the server is on a non-proxy list, and then complete
> the handshake with the client (with a caveat regarding ECH here).  I can
> guess why this doesn't happen (it's expensive and see also Section 5.4),
> but that doesn't excuse the practice.
>
> client to the server.  At that point, it is too late and the damage has
> been done (see Andrei's review).
>
>
>
> Unless I misunderstood it, the document is suggesting the same as you
> listed.  Basically, the proxy makes a separate connection to the server as
> a client (“out-of-band” wrt to the originating client-server connection),
> retrieves the server’s certificate from the proxy-server handshake, and
> determines whether the server is on a non-proxying list or not.  If on the
> list, the proxy forwards the originating client CH as is to the server, and
> steps aways from the originating client-server handshake.
>

The proxy MUST generate a fresh ClientHello when doing this (something
Andrei and I previously mentioned). When the proxy makes its separate
connection to the server, the server can behave differently when responding
to the proxy compared to when it responds to the client, and could present
itself to the proxy as something innocuous that should not be proxied.
Assuming at this point that the proxy has held onto the client's
ClientHello (waiting for the response from the server to the proxy's
ClientHello), the proxy decides either to intercept this connection or
allow the client's ClientHello to go through to the server. When the proxy
allows the client's ClientHello to go through to the server (without
interception), there's no guarantee that the server will respond to the
client the same way it did to the proxy, or even that the identity the
server presented to the proxy is the server's real identity.

If the proxy copies extensions unknown to it from the client's ClientHello
to its own, then it will not be able to parse the response from the server
when the server acts on those unknown extensions. This caused a year of
delay in finishing TLS 1.3, and is bad for everyone. A malicious client and
cooperating server don't even need to use an extensibility point unknown to
the proxy to evade a proxy selectively terminating connections based on the
TLS handshake between the proxy and server.

This sort of selective proxying is fundamentally broken and should not be
recommended as a best practice.

>
> There are additional considerations in this approach (latency etc.). The
> document intentionally left out the details to implementations, but could
> also cover them if needed.
>
>
>
>
> There are a bunch of places where pure proxying - as described in the
> introduction - is not assumed.  This leads to the same problems already
> cited.  For instance, in Section 4.2:
>
> The proxy MAY remove cipher suites from a client-initiated Client Hello
> message, add new cipher suites, and re-order them in the proxy-initiated
> Client Hello message.
>
>

---

From: Rob Sayre <[email-masked]>
Date: Tue, 28 Jul 2020 17:54:20 -0700

Oppose.

Nothing new to add.

thanks,
Rob

On Sun, Jul 19, 2020 at 10:35 AM Ron Bonica <rbonica=
[email-masked]> wrote:

> Please send comments to [email-masked] <opsec@ietf..org> by August 3,
> 2020.
>
>
>
>                                                                 Ron
>
>
>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 29 Jul 2020 13:26:13 +1000

Hi Eric,

On Wed, Jul 29, 2020, at 07:18, Eric Wang (ejwang) wrote:
> non-disruptive manner. 

I will try to be clearer on this point.

This requires design work and this document is a poor vehicle for that.  It needs a separate document that documents the design, the properties of that design, and the assumptions that it requires to achieve those properties.

The TLS working group has decided not to undertake work in this area.  That TLS working group decision needs to be respected by other parts of the IETF.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 29 Jul 2020 11:20:04 +0000

Also, a CDN is not a proxy.  It *IS* an entity that the origin has contracted with to perform certain functions.

---

From: "Eric Wang (ejwang)" <[email-masked]>
Date: Wed, 29 Jul 2020 22:46:26 +0000

It looks the “selective proxying” topic requires a full document to analyze it.  The co-authors discussed and it would be a good idea to remove it from this draft.  We will made the updates.

The concern is valid that "there's no guarantee that the server will respond to the client the same way it did to the proxy, or even that the identity the server presented to the proxy is the server's real identity”.  We also have to dive into the details about which piece of server responded information is being used for selective proxying, and how often/what to do when that changes.

The "malicious client and cooperating server” problem exists outside of a TLS proxy deployment. There are many ways to circumvent a TLS proxy if one controls both sides.  The document touched it in Section 5.2<https://tools.ietf.org/html/draft-wang-opsec-tls-proxy-bp-00#section-5.2>.

Some TLS proxy implementations violated the RFC in the past, but nothing in our draft suggests that a modern TLS proxy does or should violate the TLS spec.  It was the motivation of this draft to help reduce/prevent non-compliance, as mentioned earlier.

On Jul 28, 2020, at 5:34 PM, Nick Harper <nharper=[email-masked]<mailto:nharper=[email-masked]>> wrote:

On Tue, Jul 28, 2020 at 2:19 PM Eric Wang (ejwang) <ejwang=[email-masked]<mailto:[email-masked]>> wrote:
Thank you for the detailed comments.

An acceptable practice MUST include not violating the protocol invariants in RFC 8446. It is not possible for a proxy to obey the protocol invariants and selectively proxy based on the contents of the TLS handshake between the proxy and the server a client wishes to connect to.

More inline...

The proxy MUST generate a fresh ClientHello when doing this (something Andrei and I previously mentioned). When the proxy makes its separate connection to the server, the server can behave differently when responding to the proxy compared to when it responds to the client, and could present itself to the proxy as something innocuous that should not be proxied. Assuming at this point that the proxy has held onto the client's ClientHello (waiting for the response from the server to the proxy's ClientHello), the proxy decides either to intercept this connection or allow the client's ClientHello to go through to the server. When the proxy allows the client's ClientHello to go through to the server (without interception), there's no guarantee that the server will respond to the client the same way it did to the proxy, or even that the identity the server presented to the proxy is the server's real identity.

If the proxy copies extensions unknown to it from the client's ClientHello to its own, then it will not be able to parse the response from the server when the server acts on those unknown extensions. This caused a year of delay in finishing TLS 1.3, and is bad for everyone. A malicious client and cooperating server don't even need to use an extensibility point unknown to the proxy to evade a proxy selectively terminating connections based on the TLS handshake between the proxy and server.

This sort of selective proxying is fundamentally broken and should not be recommended as a best practice.

Best,
-Eric

---

From: "Eric Wang (ejwang)" <[email-masked]>
Date: Wed, 29 Jul 2020 22:55:21 +0000

Hi Martin,

I understand your point.

When starting this document, we analyzed TLS proxy for 3 possibilities:

1. It may violate existing specs inevitably;

2. It can be compliant but needs development work for some new “helper” protocol;

3. Neither #1 or #2, but it needs a set of requirements to be defined.

From the discussions so far, a plain TLS proxy fits in #3.  To the end, it is a TLS server and a TLS client deployed back to back, and both must be and can be compliant.

It looks “selective proxying” is in question and requires deeper discussions, so it should be addressed separately.

How about a scope of #3 as a starting point given no design work needed by the TLS working group?

On Jul 28, 2020, at 8:26 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

Hi Eric,

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Jul 2020 00:26:47 +0100

Hiya,

On 29/07/2020 23:46, Eric Wang (ejwang) wrote:
> It was the motivation of this draft to help reduce/prevent
> non-compliance, as mentioned earlier.
TLS MITM products, by design, do not comply with the TLS
protocol, which is a 2 party protocol.

There is *only* non-compliance in this space.

S.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 29 Jul 2020 16:56:39 -0700

> protocol, which is a 2 party protocol.

Without taking a position on this document, I do not believe this statement
to be correct.

1. TLS doesn't document at all how the server is validated, so from a
technical perspective a MITM proxy is simply a TLS server with a
certificate issued by a locally installed CA attached to a TLS client that
connects to the server (what is known in SIP as a B2BUA).
2. TLS 1.3 specifically documents invariants for TLS terminating
middleboxes, including MITM proxies (
https://tools.ietf.org/rfcmarkup?doc=8446#section-9.3).
3. Ignoring MITM proxies, TLS is widely deployed in operating
configurations where the client connects to a TLS reverse proxy (i.e., a
CDN) which then connects to the server; this is also not a two-party
situation.

What text in TLS do you believe terminating proxies (in either direction)
do not conform to?

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Jul 2020 01:06:47 +0100

Hiya,

> What text in TLS do you believe terminating proxies (in either direction)

I gtend to start with the abstract: "TLS allows
client/server applications to communicate over the
Internet in a way that is designed to prevent
eavesdropping, tampering, and message forgery."

I think that text has remained through various
iterations.

More importantly, the analyses done for tls1.3
afaik do not consider such 3rd parties except as
an attacker.

I'm by no means denying the fact that MITM boxen
are deployed, but the idea that some of them are
"conformant" and some are not seems bogus.

S.

---

From: Carrick Bartle <[email-masked]>
Date: Wed, 29 Jul 2020 17:28:57 -0700

> eavesdropping, tampering, and message forgery."

It seems clear that TLS proxies obey the letter, if not the spirit, of that statement.

However, it seems to me that no further discussion in the TLSWG is necessary given Martin's assertion that "The TLS working group has decided not to undertake work in this area."

> On Jul 29, 2020, at 5:06 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 29 Jul 2020 17:35:16 -0700

> I think that text has remained through various

Yes, and in this context, the MITM proxy is a server from the client's
perspective and a client from the origin server's perspective.

> afaik do not consider such 3rd parties except as

I would say rather that those analyses consider them as protocol endpoints
and address the two individual connections terminated by the proxy and have
nothing to say about the composition of those two connections.

> "conformant" and some are not seems bogus.

Well, they are either conformant with the text of 8446 S 9.3 or they are
not (and just to be clear, being conformant with 9.3 does not make them
good for the reason indicated above).

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Wed, 29 Jul 2020 17:48:06 -0700

> good for the reason indicated above).

This argument doesn't seem baseless, but I think these MITM documents also
presume IETF consensus on the current PKI system, and I am not sure that
has ever been tested.

thanks,
Rob

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 30 Jul 2020 01:26:01 +0000

>I would say rather that those analyses consider them as protocol endpoints and address the two individual connections terminated by the proxy and have nothing to say about the composition of those two connections.

I think that some of those opposed are conflating the general “end to end” argument with what the TLS protocol RFC says, as ekr is saying.

Conformance isn’t the issue, really, it’s ickiness.  It’s one thing if an enterprise install intermediaries to monitor the outbound traffic on its machines, it’s another if a national-scale attacker does surreptitiously, and it’s various other things along those spectrums. We’d all like a clear bright line to say YES here, NO there, and WELL MAYBE IF YOU MUST over there, but that’s not possible.

---

From: "Eric Wang (ejwang)" <[email-masked]>
Date: Thu, 30 Jul 2020 04:47:29 +0000

To echo the ickiness part…   Putting on my end user hat, if I have to take it with an enterprise device on the enterprise network, I would rather it be done securely, respecting my privacy...  If I’m on my home network, I want an easy way to detect and reject it, no matter it is from a vendor, provider or state.  At this time, there seems no easy way on either side.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 29 Jul 2020 22:23:56 -0700

On Wed, Jul 29, 2020 at 9:48 PM Eric Wang (ejwang) <ejwang=
[email-masked]> wrote:

> To echo the ickiness part…   Putting on my end user hat, if I have to take
> it with an enterprise device on the enterprise network, I would rather it
> be done securely, respecting my privacy...  If I’m on my home network, I
> want an easy way to detect and reject it, no matter it is from a vendor,
> provider or state.  At this time, there seems no easy way on either side.
>

I don't think this makes sense.

thanks,
Rob

---

From: Paul Brears <[email-masked]>
Date: Thu, 30 Jul 2020 11:28:45 +0000

I support this draft and agree with the points made below.

Paul

From: Arnaud.Taddei.IETF<mailto:Arnaud.Taddei.IETF=[email-masked]>
Sent: 28 July 2020 09:36
To: Jen Linkova<mailto:[email-masked]>
Cc: OPSEC<mailto:[email-masked]>; OpSec Chairs<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

I support this draft

---

From: Töma Gavrichenkov <[email-masked]>
Date: Thu, 30 Jul 2020 15:03:40 +0300

Peace,

On Mon, Jul 27, 2020, 4:18 PM Blumenthal, Uri - 0553 - MITLL <[email-masked]>
wrote:

> in this particular case, instead of "if you want to do this, then do it
> that way, and I'll help you inter-operate" I prefer "if you want to do this
> - you're on your own, don't seek a blessing or advice from me".
>

I don't think this is how it works.

I would personally prefer an explicit "this is not recommended or in any
way endorsed".

I've already heard that "IETF considers this a grey area to be defined in
future, and some interoperability is outlined in 8446" in middlebox sales
pitches.

--
Töma

---

From: Töma Gavrichenkov <[email-masked]>
Date: Thu, 30 Jul 2020 15:11:16 +0300

Peace,

On Wed, Jul 29, 2020, 2:20 PM Salz, Rich <rsalz=[email-masked]>
wrote:

> Also, a CDN is not a proxy.  It **IS** an entity that the origin has
> contracted with to perform certain functions.
>

It is (in all but a couple of implementations I think) a *proxy* that the
origin has contracted with.  Could you please elaborate on your point?

--
Töma

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 30 Jul 2020 12:33:23 +0000

*   It is (in all but a couple of implementations I think) a *proxy* that the origin has contracted with.  Could you please elaborate on your point?

It has a TLS cert that identifies itself as the origin.  It doesn’t just terminate TLS, but it does work at the HTTP layer.

How is it different from an origin that uses load-balancing to send you somewhere?  Is www.facebook.com<http://www.facebook.com> a CDN or intermediary, or is it the origin?

---

From: Töma Gavrichenkov <[email-masked]>
Date: Thu, 30 Jul 2020 16:13:09 +0300

Peace,

On Thu, Jul 30, 2020 at 3:33 PM Salz, Rich <[email-masked]> wrote:
>> It is (in all but a couple of implementations I think)
> a *proxy* that the origin has contracted with.  Could
> you please elaborate on your point?
>
> It has a TLS cert that identifies itself as the origin.

It depends!

In the majority of cases (i.e. delivering preseeded static content),
no. It identifies as some-1337-garbage.static.example.com, which it
basically *is*.
The manner in which the content (hopefully uploaded by the origin via
an end-to-end encrypted connection) propagates to edge nodes is then
up to the implementation, and it is contained within the area of
responsibility of the CDN operator.

However, there's a minority of cases where a CDN is also used to
deliver *dynamically generated* content which could not be cached,
e.g. because it is only available to authenticated users.  In this
case, the CDN in fact impersonates the origin, processes all the
authentication data, and the only way to implement that is proxying
across different areas of responsibility.  How's that different from
what middleboxes are doing is not clear to me.

Proxy is a proxy.  There are various kind of proxies probably also
doing something which is deemed useful to their owners and users,
which doesn't relax the statement that such proxying is not endorsed
by the IETF.  The intent and purpose behind proxying are IMO in scope
of model-t and are, accordingly, out of scope here.

> How is it different from an origin that uses load-balancing to send you somewhere?  Is www.facebook.com a CDN or intermediary, or is it the origin?

Is www.facebook.com a Facebook-owned middlebox, or is it the endpoint
server?  (And this is *one* of the reasons I won't trust Facebook for
anything sensitive!)

Again, I think this is more of a topic for model-t.

The main difference though is that the data crosses the boundary
between the areas of responsibility in a way which is not transparent
to me.  It is a common approach to allow insecure connections over the
Internet from the edge nodes to the origin, and I have no way of
knowing if this is the case for the resource I'm currently using.
There are also more subtle differences but I think I've long crossed
the boundary of the off-topic area here myself!

--
Töma

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 30 Jul 2020 13:39:11 +0000

No.  That might be the DNS name, but it is not the TLS certificate that the server presents. That certificate MUST have a name that matches the original name that the client (browser, often) present. That's fundamental.

CDN's also do things like API gateways, BOT detection, etc.  In some cases, the dynamic traffic manipulation is more in either bytes or connections.
Consider this configuration in a fake language
	<match cond="using-weak-cipher()">
		<redirect>/get/better/browser.html</redirect>
	</match>

Where does this fall?

I agree that if example.com hires a CDN or deploys a middlebox to do those things, there is no difference.

>    Proxy is a proxy.

That's too simplistic. We have a product, site shield, that customers can use to limit the IP addresses of who can reach their origin server.  Everyone else is blocked. Some use that to make sure that *only* Akamai servers will talk to them, and that everything else goes through us.  Is that a proxy? How is it different from terminating TLS in the DMZ and sending it inside? How does the client know?

>is ...  a Facebook-owned middlebox, or is it the endpoint
    server?

What is the endpoint server, if facebook sends you there?

    to me. 

And my point is that there is no such boundary. Or perhaps more accurately, it is a barrier that they don't want  you to see. Just like they might not want you to know about the DMZ and interior network, which are often run by different organizations inside the corporation.

---

From: Töma Gavrichenkov <[email-masked]>
Date: Thu, 30 Jul 2020 17:56:44 +0300

Peace,

On Thu, Jul 30, 2020, 4:39 PM Salz, Rich <[email-masked]> wrote:

> We have a product, site shield, that customers can use to limit the IP
> addresses of who can reach their origin server.  Everyone else is blocked.
> Some use that to make sure that *only* Akamai servers will talk to them,
> and that everything else goes through us.  Is that a proxy? How is it
> different from terminating TLS in the DMZ and sending it inside? How does
> the client know?
>

I don't know, and this *is* the problem.

I may be connecting to the service from a network I don't trust with my
information, and I have (almost) no tool to tell me whether it is served
from a different network via a secure connection *or* it is served from an
edge node deployed *in the same network I don't trust*, that node being
connected to the service through an unauthenticated channel.

Like in [1], where this unauthenticated channel is being marketed as
"end-to-end encryption".  This approach basically defies all the end-to-end
encryption efforts.

When it comes to static content, with all the JS security implemented, this
is mostly fine.  Dynamic content is a very different story.

[1]
https://support.cloudflare.com/hc/en-us/articles/200170416-End-to-end-HTTPS-with-Cloudflare-Part-3-SSL-options

--
Töma

---

From: Nick Harper <[email-masked]>
Date: Thu, 30 Jul 2020 08:18:01 -0700

> I don't know, and this *is* the problem.

The point is, whatever server/device has a publicly trusted certificate for
a domain name is authoritative for that domain. That server can get the
content it serves (whether dynamic or static) from any source. TLS only
provides guarantees about the connection between the client and server. It
says nothing about whether the content served was obtained or generated in
some secure manner. That content could be sourced locally, it could be
aggregated or generated from other servers via connections over other
secure protocols that aren't TLS, it could even come from some insecure
source like transmitting an audio stream collected from an antenna
connected to the server.

> connected to the service through an unauthenticated channel.

If you're connecting to a service, at some point you have to trust that the
service operator is running it in a reasonable way. TLS only tells you that
your connection to the server is secure - it tells you nothing about the
provenance of the content served, and even if such a mechanism exists (I am
not advocating that such a thing should exist), the server can always claim
that it generated it instead of that it got it from somewhere else.

> When it comes to static content, with all the JS security implemented,
> this is mostly fine.  Dynamic content is a very different story.
>
> [1]

---

From: Ben Smyth <[email-masked]>
Date: Fri, 31 Jul 2020 16:20:46 +0200

On Tue, 28 Jul 2020 at 10:35, Arnaud.Taddei.IETF
<Arnaud.Taddei.IETF=[email-masked]> wrote:
> I strongly support this work as it represents capabilities that are being developed, deployed and used in practice. It has good intentions and provides a good approach in the context of defense in depth approaches. No security cannot be just on both ends of the communication. One can dream about it but that is not how reality is.

I appreciate that capabilities are being developed, deployed, and
used. However, shouldn't a secure solution be sought? Surely secure
solutions are just waiting to be discovered?

---

From: "Eric Wang (ejwang)" <[email-masked]>
Date: Fri, 31 Jul 2020 18:41:11 +0000

As authors we appreciate all the constructive comments on the draft.  Based on the feedback, we will revise the scope of the document to cover “plain” TLS proxy only (removing “selective proxying”).  We will circulate a new revision when it is ready.

Best,
-Eric (on behalf of the authors)

On Jul 22, 2020, at 6:30 PM, Jen Linkova <[email-masked]<mailto:[email-masked]>> wrote:

Folks,

                                                               Ron

---

From: Rob Sayre <[email-masked]>
Date: Fri, 31 Jul 2020 15:33:23 -0700

Hi,

I think this WG is a bit zombie-like. Its most recent milestones are from
2013 [1].

I favor rejecting all active drafts (although I can see value in publishing
them via the ISE), and closing this WG.

thanks,
Rob

[1] https://datatracker.ietf.org/wg/opsec/about/

On Fri, Jul 31, 2020 at 11:41 AM Eric Wang (ejwang) <ejwang=
[email-masked]> wrote:

> As authors we appreciate all the constructive comments on the draft.
> Based on the feedback, we will revise the scope of the document to cover
> “plain” TLS proxy only (removing “selective proxying”).  We will circulate
> a new revision when it is ready.
>
> Best,
> On Jul 22, 2020, at 6:30 PM, Jen Linkova <[email-masked]> wrote:
>