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

[Bernd Eckenfels]

How about only passing it to an extended handshake listener. The material does not have to be cached (the app can do it if needed) and renegotiation works the same way. This can also be helpful for things like logging the master secret (for wireshark decryption). It can even handle auditing of session resumptions

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: security-dev <security-dev-bounces at openjdk.java.net> on behalf of Xuelei Fan <xuelei.fan at oracle.com>
Sent: Saturday, August 26, 2017 11:25:50 PM
To: Martin Balao; security-dev at openjdk.java.net
Subject: Re: Code Review Request: JDK-6491070 (Support for RFC 5929-Channel Bindings)

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>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170826/352e3325/attachment.htm>