IMO this document is absolutely not ready to become an RFC. It basically ignores the purpose of TLS which is to prevent exactly the MITM attacks being espoused here (IMO). In ignoring that, it ignores all of the bad consequences of such MITM attacks.
As evidence: "To proxy a TLS session, a TLS Proxy must be able to present a valid X.509 certificate to the TLS client to appear as a valid TLS Server;" That assumes that an x.509 data structure created on the fly, with no interaction with the named subject can be "valid." That is antithetical to the intent of x.509 and TLS. That is such a fundamental misconstruction of x.509, of PKI and of TLS that it alone means that the draft is sufficiently inaccurate to be unworthy of publication as an IETF consensus RFC. If really necessary I'm sure many other related problems can and will be found in the text. I hope that waste of effort is not needed. The basic problem here seem to me to be an effort to justify (and perhaps promote?) existing MITM practices without fairly or accurately describing their downsides. As I also commented on a related document: the effort expended on attempts to garner IETF consensus on such text is not worthwhile. If someone actually wrote truly objective text on the reasons why people deploy TLS MITM attack boxes and on the real downsides that would be different. This is nowhere near such objective text. My recommendation: declare this document dead. And don't bother with the supposed BCP. Instead, try to find someone who can write an evidence-based description of the falsifiable pros and cons of these TLS MITM products. And then send that to the ISE. S. PS: I'm sure someone will claim that being logical about this "ignores reality" so just to get in a comment on that ahead of time: reality includes lots of bad engineering - if and when we want to document that, there is an onus on us to say why it is bad and how to do better. That would require offering evidence as to the efficacy or otherwise of TLS MTIM boxes when compared to the benefits of using TLS as-designed. That evidence, in my experience, never seems to actually be offered by those who espouse these MITM attack products.
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
