<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div id="x_compose-container" itemscope="" itemtype="https://schema.org/EmailMessage" style="direction:ltr">
<span itemprop="creator" itemscope="" itemtype="https://schema.org/Organization"><span itemprop="name"></span></span>
<div>
<div style="direction:ltr">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 </div>
<div><br>
</div>
<div class="x_acompli_signature">Gruss<br>
Bernd<br>
-- <br>
<a dir="ltr" href="http://bernd.eckenfels.net">http://bernd.eckenfels.net</a></div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> security-dev <security-dev-bounces@openjdk.java.net> on behalf of Xuelei Fan <xuelei.fan@oracle.com><br>
<b>Sent:</b> Saturday, August 26, 2017 11:25:50 PM<br>
<b>To:</b> Martin Balao; security-dev@openjdk.java.net<br>
<b>Subject:</b> Re: Code Review Request: JDK-6491070 (Support for RFC 5929-Channel Bindings)</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi Marin,<br>
<br>
Sorry for the delay.<br>
<br>
There are a few protocols that can benefits from exporting SSL/TLS <br>
handshake materials, including RFC 5929, RFC 5056, token binding and TLS <br>
1.3 itself. Can we define a general API so as to exposing the handshake <br>
materials, so as to mitigate the inflating of JSSE APIs? I may suggest <br>
make further evaluation before move on to following design and code.<br>
<br>
> <br>
<a href="http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/">http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/</a><br>
I have two concerns about the design:<br>
<br>
1. Channel binding may be not always required.<br>
SSLSocket/SSLEngine.getTlsChannelBinding(String bindingType);<br>
<br>
The SunJSSE provider happens to cache the finished messages in its <br>
implementation so you can use it for tls-unique, but it may not be true <br>
for other provider or other channel bindings. Need to define a more <br>
reliable approach to get the handshake materials.<br>
<br>
If the channel binding is not required, it may be not necessary to <br>
expose the handshake materials. Need to define a solution to indicate <br>
the need of the exporting.<br>
<br>
2. No way to know the update of the underlying handshake materials.<br>
If renegotiation can takes place, need to define a interface to indicate <br>
that so that application can response accordingly. See section 3 and 7 <br>
of RFC 5929.<br>
<br>
Thanks,<br>
Xuelei<br>
<br>
On 7/31/2017 8:53 AM, Martin Balao wrote:<br>
> Hi,<br>
> <br>
> Here it is an update for the proposed TLS Channel Bindings support in <br>
> OpenJDK:<br>
> <br>
> * <br>
> <a href="http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/">
http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/</a> <br>
> (browse online)<br>
> * <br>
> <a href="http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/6491070.webrev.02.zip">
http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/6491070.webrev.02.zip</a>
<br>
> (download)<br>
> <br>
> Changes since v01:<br>
> <br>
> * getTlsChannelBinding API changed to return null by default (if not <br>
> implemented), instead of throwing an UnsupportedOperationException.<br>
> <br>
> * "tls-server-end-point" TLS channel binding now supported.<br>
> <br>
> Kind regards,<br>
> Martin.-<br>
> <br>
> On Wed, Jul 26, 2017 at 4:12 PM, Martin Balao <mbalao@redhat.com <br>
> <<a href="mailto:mbalao@redhat.com">mailto:mbalao@redhat.com</a>>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> Here it is my proposal for JDK-6491070 (Support for RFC 5929-Channel<br>
> Bindings: e.g. public API to obtain TLS finished message) [1]:<br>
> <br>
> *<br>
> <a href="http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/">
http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/</a><br>
> <<a href="http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/">http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/</a>><br>
> *<br>
> <a href="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</a><br>
> <<a href="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</a>><br>
> <br>
> Notes:<br>
> * Implementation based on Channel Bindings for TLS (RFC 5929) [2]<br>
> <br>
> * Only "tls-unique" currently supported<br>
> <br>
> Look forward to your comments.<br>
> <br>
> Kind regards,<br>
> Martin.-<br>
> <br>
> --<br>
> [1] - <a href="https://bugs.openjdk.java.net/browse/JDK-6491070">https://bugs.openjdk.java.net/browse/JDK-6491070</a><br>
> <<a href="https://bugs.openjdk.java.net/browse/JDK-6491070">https://bugs.openjdk.java.net/browse/JDK-6491070</a>><br>
> [2] - <a href="https://tools.ietf.org/html/rfc5929">https://tools.ietf.org/html/rfc5929</a><br>
> <<a href="https://tools.ietf.org/html/rfc5929">https://tools.ietf.org/html/rfc5929</a>><br>
> <br>
> <br>
</div>
</span></font>
</body>
</html>