RandomCookie.java (was Re: Code Review Request: TLS 1.3 Implementation)

Weijun Wang weijun.wang at oracle.com
Thu Jun 7 03:17:58 UTC 2018



> On Jun 7, 2018, at 12:19 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> On 6/5/2018 10:37 PM, Weijun Wang wrote:
>> RandomCookie.java:
>> +    private boolean isT12Downgrade() {
>> +        return Arrays.equals(randomBytes, 24, 31, t12Protection, 0, 7);
>> +    }
>> +
>> +    private boolean isT11Downgrade() {
>> +        return Arrays.equals(randomBytes, 24, 31, t11Protection, 0, 7);
>> +    }
>> The "to" in Arrays::equals is exclusive, so please update 31 -> 32, 7 -> 8.
> Good catch!
> 
>> Also, at the end of https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.3
>>    RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH Implementations of
>>    draft versions (see Section 4.2.1.1) of this specification SHOULD NOT
>>    implement this mechanism on either client and server.  A pre-RFC
>>    client connecting to RFC servers, or vice versa, will appear to
>>    downgrade to TLS 1.2.  With the mechanism enabled, this will cause an
>>    interoperability failure.
>> Has the current implementation implemented (and turned on) this mechanism?
> Yes, the mechanism is turned on.

Should it depend on the value of "jdk.tls13.version"?

--Max

> 
> Thanks,
> Xuelei
> 
>> Thanks
>> Max
>>> 
>>> 
>>>>>> On Jun 5, 2018, at 12:12 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01
>>> 




More information about the security-dev mailing list