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: > “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.” 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
