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

Tue Aug 29 18:50:34 UTC 2017

Hi Xuelei,

>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.

Do you prefer an API like "public byte[] getTlsHandshakeMaterial(String
materialType)" (in SSLSocket and SSLEngine) where "materialType" can
eventually be "clientFinishedMessage"/"finishedMessage" or
"serverFinishedMessage"/"peerFinishedMessage"? I cannot think of
"serverCertificate" or "masterKey" as this is more related to a Session and
not neccessarily to a handshake. getTlsHandshakeMaterial would be a lower
level API and would move the burden of knowing which information is
required for "tls-unique" TLS channel binding to the API consumer. Looks
more like the OpenSSL approach (instead of the Python, SSLBoring or GnuTls
approaches). However, OpenSSL have specific methods for each piece of
information instead of a generic and parametrized one. I.e.:
SSL_get_finished or SSL_get_peer_finished. What other information do you
expect the Handshaker to provide?

>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.

I focused on SunJSSE provider. I'm not sure about how other providers may
implement this API and where they can get the required information from,
without knowing their internals. In regard to SunJSSE and "tls-unique"
binding type, I leveraged on existing data. If data weren't already there,
I would have to figure out how to get it from the handshake -doing the same
that was already done would have been an option-. Do you prefer the
Handshaker to provide a function to get different information and not just
the finished hash? (as for the public SSLSocket/SSLEngine
"getTlsHandshakeMaterial" API). Which other information may be useful to
get from the Handshaker? What do you mean by reliable? (given that this is
all SunJSSE internal and we have no external dependencies).

In regard to other channel bindings, it'll depend on the binding type the
way in which the information is obtained. I.e.: "tls-unique" SunJSSE
implementation leverages on cached finished messages. However,
"tls-server-end-point" leverages on stored certificates that are obtained
from the Session (not from the handshaker). Is there any specific channel
binding you are concerned with?

>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.

Do you mean a lower layer knowing if the upper layer is going to require
that information and decide to provide it or not based on that knowledge? I
think I didn't get your point here.

>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.

I intentionally skipped this -at the cost of a spurious authentication- to
avoid adding complexity to the API. An spurious authentication -which does
not appear likely to me- can easily be retried by the application. The RFC
5929 suggests APIs through which the application can *control* the flow
(i.e.: hold a renegotitation). This would expose JSSE internals. This is
more than notifying. Notification, in my opinion, adds no value: what if
the application already used the binding token before receiving the
notification? The spurious authentication will happen anyways and has to be
handled -i.e. retried-. It's just a timing issue. The real value is
controlling the flow as the RFC suggests, but at the cost of exposing JSSE
internals.

Kind regards,
Martin.-

On Sat, Aug 26, 2017 at 5:25 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:

> 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-64
> 91070/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-64
>> 91070/webrev.02/ (browse online)
>>   * http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-64
>> 91070/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-64
>> 91070/webrev.01/
>>     <http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6
>> 491070/webrev.01/>
>>       *
>>     http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-64
>> 91070/webrev.01/6491070.webrev.01.zip
>>     <http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6
>> 491070/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/20170829/6e030052/attachment.htm>