<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 20, 2019, at 07:49, Matt Caswell <<a href="mailto:matt@openssl.org" class="">matt@openssl.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">On 20/05/2019 15:23, Salz, Rich wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">   I don't see it that way. As I understand it this is a completely different<br class=""></blockquote>    protocol to standard TLS.<br class=""><br class="">That's an interesting point, but ... they use the SSL "name."<br class=""></blockquote><br class="">Which isn't even an IETF name...the IETF call it TLS ;-)<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">It is not intended to interoperate with it in any way.<br class=""></blockquote>Is that true?  I didn't look closely at the protocol changes, but maybe you're right.  On the other hand, if so, then why keep the existing IETF numbers?<br class=""></blockquote><br class=""><br class="">That was my understanding.<br class=""><br class="">But perhaps Paul Yang can confirm?<br class=""></div></div></blockquote><div><br class=""></div><div>The Chinese modified TLS protocol is not intended to interoperate with any other TLS protocols. The cipher suites defined in this protocol should not be used with the standard IETF TLS. So I guess what Matt said would be feasible to do. But in reality, users may want to have a combination of both IETF TLS and Chinese TLS together when he launches a TLS server or client, to have the auto-selection functionality if a TLS client comes in. So the way of implementation would be tricky...</div><div><br class=""></div><div>Another problem we are still facing nowadays is actually there *would* even be interoperability issues between Chinese TLS implementations (as we discussed earlier in Vancouver). The GM/T 0024 is not very strict and clear on several details in the protocol thus implementations have freedom to be diverse. So if OpenSSL finally picks up the Chinese TLS, we probably need to make sure the implementation should be widely tested against most Chinese TLS implementations. As what Tim has asked at: <a href="https://github.com/openssl/openssl/pull/8910#issuecomment-491964656" class="">https://github.com/openssl/openssl/pull/8910#issuecomment-491964656</a></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">   As a completely different protocol they can use whatever codepoints they want to<br class=""></blockquote>    use as they see fit - and there is no conflict with IETF specifications.<br class=""><br class="">If you are correct, then yes I agree.  But that makes any OpenSSL integration that much harder, doesn't it?  Would the project take on the work of making things like the apps and tests work?  In particular, a new global flag saying "tnssl" (or such), and failing to interop with existing TLS, checking the modified cipher suites (and disallowing them for real TLS), etc.<br class=""><br class=""><br class=""></blockquote>Yes, we would have to take care that the two really are separate.<br class=""><br class="">Matt<br class=""><br class=""><br class=""></div></div></blockquote></div><br class=""></body></html>