Code Review Request: JDK-6491070 (Support for RFC 5929-Channel Bindings)

Xuelei Fan xuelei.fan at oracle.com
Sat Aug 26 21:25:50 UTC 2017


Hi Marin,

Sorry for the delay.

There are a few protocols that can benefits from exporting SSL/TLS 
handshake materials, including RFC 5929, RFC 5056, token binding and TLS 
1.3 itself.  Can we define a general API so as to exposing the handshake 
materials, so as to mitigate the inflating of JSSE APIs?  I may suggest 
make further evaluation before move on to following design and code.

 > 
http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/
I have two concerns about the design:

1. Channel binding may be not always required.
SSLSocket/SSLEngine.getTlsChannelBinding(String bindingType);

The SunJSSE provider happens to cache the finished messages in its 
implementation so you can use it for tls-unique, but it may not be true 
for other provider or other channel bindings.  Need to define a more 
reliable approach to get the handshake materials.

If the channel binding is not required, it may be not necessary to 
expose the handshake materials.  Need to define a solution to indicate 
the need of the exporting.

2. No way to know the update of the underlying handshake materials.
If renegotiation can takes place, need to define a interface to indicate 
that so that application can response accordingly.  See section 3 and 7 
of RFC 5929.

Thanks,
Xuelei

On 7/31/2017 8:53 AM, Martin Balao wrote:
> Hi,
> 
> Here it is an update for the proposed TLS Channel Bindings support in 
> OpenJDK:
> 
>   * 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/ 
> (browse online)
>   * 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/6491070.webrev.02.zip 
> (download)
> 
> Changes since v01:
> 
>   * getTlsChannelBinding API changed to return null by default (if not 
> implemented), instead of throwing an UnsupportedOperationException.
> 
>   * "tls-server-end-point" TLS channel binding now supported.
> 
> Kind regards,
> Martin.-
> 
> On Wed, Jul 26, 2017 at 4:12 PM, Martin Balao <mbalao at redhat.com 
> <mailto:mbalao at redhat.com>> wrote:
> 
>     Hi,
> 
>     Here it is my proposal for JDK-6491070 (Support for RFC 5929-Channel
>     Bindings: e.g. public API to obtain TLS finished message) [1]:
> 
>       *
>     http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/
>     <http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/>
>       *
>     http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/6491070.webrev.01.zip
>     <http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/6491070.webrev.01.zip>
> 
>     Notes:
>       * Implementation based on Channel Bindings for TLS (RFC 5929) [2]
> 
>       * Only "tls-unique" currently supported
> 
>     Look forward to your comments.
> 
>     Kind regards,
>     Martin.-
> 
>     --
>     [1] - https://bugs.openjdk.java.net/browse/JDK-6491070
>     <https://bugs.openjdk.java.net/browse/JDK-6491070>
>     [2] - https://tools.ietf.org/html/rfc5929
>     <https://tools.ietf.org/html/rfc5929>
> 
> 



More information about the security-dev mailing list