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 <m...@lowentropy.net<mailto:m...@lowentropy.net>> wrote: Hi Eric, On Wed, Jul 29, 2020, at 07:18, Eric Wang (ejwang) wrote: In any case, the proxy has to conduct selective proxying in a safe, 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
