Refactoring TLS code

[Ben Smyth]

I have written a TLS 1.3 tutorial (
https://bensmyth.com/publications/2019-TLS-tutorial/) which includes source
code from JDK 11. Whilst explaining the code, I noticed some possible
refactoring that would simplify the (JDK 11 & current) code base:

- createHkdfInfo is defined three times:
SSLBasicKeyDerivation.createHkdfInfo could perhaps be dropped in favour of
SSLSecretDerivation.createHkdfInfo (noting a slight difference regarding
runtime exceptions), as can
SSLTrafficKeyDerivation.T13TrafficKeyDerivation.createHkdfInfo (noting the
need to supply 0x00 as the context).

- ServerHello.T13ServerHelloProducer.produce and
ServerHello.T13ServerHelloConsumer.consume each define code to
changeclient/server handshake traffic secrets. The code is identical up to
contexts, labels s_hs_traffic and c_hs_traffic, treatment of null in tricks
to make the compiler happy (cf. return null; and return; in
catch-branches), alpha-renaming of one variable, and whitespace (and some
obsolete, commented-out code).

- Similarly to the previous point,
Finished.T13FinishedProducer.onProduceFinished and
Finished.T13FinishedConsumer.onConsumeFinished define code to derive
traffic secrets and corresponding traffic keys, (unsurprisingly)
computations are similar. (The same is true for other secrets and traffic
keys.)

- CertificateVerify.onProduceCertificateVerify is defined for
ServerHandshakeContext and ClientHandshakeContext, both instances are
identical up to variables shc and chc (with the former using string
"server" and the latter using "client" for logging).

- Not really refactoring, but comment on ClientHello:1172 says extension
key_share is ignored, when it isn't (extension psk_key_exchange_modes,
pre_shared_key, and protocol_version are).

My apologises if this mail is considered noise (or is simply wrong)---I
figured suggestions for simplifying JDK's code base might be useful.


Best regards,

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200527/f69b884f/attachment.htm>