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

[Xuelei Fan]

On 6/6/2018 8:17 PM, Weijun Wang wrote:
> 
> 
>> 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"?
> 
No, the system property is only used to set the the version number.

As we don't want to ship draft TLS 1.3, we don't actually follow the 
above draft special spec ("SHOULD NOT implement this mechanism").

Xuelei

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