Re: Update

[Salz, Rich]

>>  I'd be opposed to this last option without IANA/IETF being on board. By 
doing so
>we are effectively no longer compliant with IETF TLS since we're using 
certain
>codepoints and version numbers to mean things that IETF/IANA have no 
visibility
>of, i.e. we would be doing exactly what Rich was worried about. I 
don't see
>IANA/IETF doing this anytime soon.
> 
> For the most part, getting IANA on board requires someone in authority 
email to tls-regis...@iana.org asking for code points and pointing to their 
spec.

’someone in authority’ here means the author of the spec who is asking for 
code points?


Yes.  Or someone involved with the spec.

Re: Update

[Paul Yang]

> On May 22, 2019, at 10:16, Salz, Rich  wrote:
> 
>>> I'd be opposed to this last option without IANA/IETF being on board. By 
>>> doing so
>>   we are effectively no longer compliant with IETF TLS since we're using 
>> certain
>>   codepoints and version numbers to mean things that IETF/IANA have no 
>> visibility
>>   of, i.e. we would be doing exactly what Rich was worried about. I don't see
>>   IANA/IETF doing this anytime soon.
>> 
>> For the most part, getting IANA on board requires someone in authority email 
>> to tls-regis...@iana.org asking for code points and pointing to their spec.
> 
>’someone in authority’ here means the author of the spec who is asking for 
> code points?
> 
> 
> Yes.  Or someone involved with the spec.

Hmmm, that would be someone involved in GM/T 0024...

> 

Re: Update

[Paul Yang]

> On May 21, 2019, at 22:13, Salz, Rich  wrote:
> 
> 
>>  I'd be opposed to this last option without IANA/IETF being on board. By 
>> doing so
>we are effectively no longer compliant with IETF TLS since we're using 
> certain
>codepoints and version numbers to mean things that IETF/IANA have no 
> visibility
>of, i.e. we would be doing exactly what Rich was worried about. I don't see
>IANA/IETF doing this anytime soon.
> 
> For the most part, getting IANA on board requires someone in authority email 
> to tls-regis...@iana.org asking for code points and pointing to their spec.

’someone in authority’ here means the author of the spec who is asking for code 
points?

> 

Re: Update

[Salz, Rich]

 
 >   I'd be opposed to this last option without IANA/IETF being on board. By 
 > doing so
we are effectively no longer compliant with IETF TLS since we're using 
certain
codepoints and version numbers to mean things that IETF/IANA have no 
visibility
of, i.e. we would be doing exactly what Rich was worried about. I don't see
IANA/IETF doing this anytime soon.
   
For the most part, getting IANA on board requires someone in authority email to 
tls-regis...@iana.org asking for code points and pointing to their spec.

Re: Update

[Paul Yang]

> On May 20, 2019, at 07:49, Matt Caswell  wrote:
> 
> 
> On 20/05/2019 15:23, Salz, Rich wrote:
>>>   I don't see it that way. As I understand it this is a completely different
>>protocol to standard TLS.
>> 
>> That's an interesting point, but ... they use the SSL "name."
> 
> Which isn't even an IETF name...the IETF call it TLS ;-)
> 
>>> It is not intended to interoperate with it in any way.
>> 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?
> 
> 
> That was my understanding.
> 
> But perhaps Paul Yang can confirm?

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...

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: 
https://github.com/openssl/openssl/pull/8910#issuecomment-491964656 

> 
>>>   As a completely different protocol they can use whatever codepoints they 
>>> want to
>>use as they see fit - and there is no conflict with IETF specifications.
>> 
>> 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.
>> 
>> 
> Yes, we would have to take care that the two really are separate.
> 
> Matt
> 
> 

Re: Update

[Salz, Rich]

>I don't see it that way. As I understand it this is a completely different
protocol to standard TLS.

That's an interesting point, but ... they use the SSL "name."

> It is not intended to interoperate with it in any way.

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?

>As a completely different protocol they can use whatever codepoints they 
> want to
use as they see fit - and there is no conflict with IETF specifications.
  
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.

 

Re: Update

[Richard Levitte]

On Mon, 20 May 2019 16:05:49 +0200,
Salz, Rich wrote:
> 
>   * The current requirement for inclusion is “national standard” or better.  
> Thus, this change
> should be accepted.
> 
> The problem is that they squatted on codepoints that the IETF controls.  So 
> while it is a national
> standard, it is also in conflict with the IETF specifications.

Did they?  For the protocol version, they used something that has
never seen the light of day (0x0003 - 0x02ff is "free" and will most
probably never be used for TLS), and the cipher suites they added are
in a range that's unassigned (0xE0xx).

You *are* correct on one point, though...  the Chinese standard isn't
TLS.  Like Matt says, it's a different protocol, even though it
resembles TLS v1.1 quite a bit.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Update

[Salz, Rich]

  *   The current requirement for inclusion is “national 
standard”
 or better.  Thus, this change should be accepted.

The problem is that they squatted on codepoints that the IETF controls.  So 
while it is a national standard, it is also in conflict with the IETF 
specifications.