Spec review of JEP 114: TLS Server Name Indication (SNI) Extension (original) (raw)

Chris Hegarty chris.hegarty at oracle.com
Tue Sep 4 09:49:50 UTC 2012

Xuelei,

Thanks for addressing my comments. This looks fine to me.

-Chris.

On 04/09/12 06:01, Xuelei Fan wrote:

webrev: http://cr.openjdk.java.net/~xuelei/7068321/webrevspec.10/

On 9/3/2012 9:22 PM, Chris Hegarty wrote: Xuelei,

This looks very good. Just a few minor comments: - SNIServerName hexes could be UPPERCASE, since it is a constant. Yes. - Trivially, SNIHostName(String) calls IDN.toASCII(hostname) twice It is not clear to me from this constructor whether it should pass a hostname "as understood by the client", or an encoded hostname. The method description seems to be at odds with the implementation ( at least from me reading ). Maybe this could be a little clearer by saying "as understood by the client". Good suggestion. The spec is updated to make it clear that the hostname can be a user-friendly Internationalized Domain Name (IDN). - SNIHostName.hostname seems simply be a String version of the SNIServerName.encoding. Also, there is no way of returning the original hostname as passed in the constructor. Generally, the encoded hostname (byte array) is come from the client requested server name indication. In such a case, it is unknown whether it is encoded in UTF-8 per RFC4366 (old spec for SNI), or ASCII per RFC6066. We are not always able to easily get the original hostname because of the encoding tolerant. SNIHostName.getName() is mainly used in SNIMatcher to decide whether a hostname is recognizable. Revised the spec,and change the name of getName() method to getAsciiName to make it more clear. - SNIHostName.equals, Is it possible to craft a concrete SNIServerName implementation that would be considered equal to a SNIHostName? No, it is a coding error. Thanks! It would seem that hostname may not be considered in the equality. - There is scope for null parameter checking in the implementation to use j.u.Objects.requireNonNull(Object,String) Good, it makes some things easier. - Is it possible to change SNIStandardTypes to use an enum, similar to java.net.SocketOption & java.net.StandardSocketOptions, rather than an int. It would still be extendable, but more "Java like". We also need to parse unknown server name types. Using integer is more straightforward. Thanks, Xuelei -Chris. On 03/09/2012 03:05, Xuelei Fan wrote: Hi,

This is the spec review for JEP 114 [1]. webrev: http://cr.openjdk.java.net/~xuelei/7068321/webrevspec.10/ Network team, per RFC 6066, the hostname in TLS SNI extension need to be encoded in ASCII. In SNIHostName, to get the ASCII-Compatible Encoding (ACE), java.net.IDN is used to convert from general String and UTF-8 encoded byte array to ASCII string. We need expertise in networking, would you please review the spec of SNIHostName? Thanks, Xuelei [1]: http://openjdk.java.net/jeps/114

More information about the security-dev mailing list