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