Re: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension

[Xuelei Fan]

Updated webrev according to recent feedbacks:
http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/
http://cr.openjdk.java.net./~xuelei/7068321/README_05.txt

The major differences:
1. add constant SSLParameters.SNI_HOST_NAME, and specify the format of
unknown SNI type (sni-integer) in ExtendedSSLSession.
   Then we don't need to document the types and values in Java
Cryptography Architecture Standard Algorithm Name Documentation.

2. Other updates according to feedback from Brad, Weijun, and Sean.
   Please let me know I missed misunderstood something.

Thanks,
Xuelei

On 8/12/2012 8:50 PM, Xuelei Fan wrote:
 Hi,
 
 Please review the spec of JEP 114, TLS Server Name Indication (SNI)
 Extension.
 
 http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/
 
 Please read the README to help you understanding the the specification:
 
http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt
 
 The major differences comparing with previous webrev are:
 1. client mode and server mode will use separated API set.
For client, the related APIs are:
  setServerName(String type, String value)
  clearServerName(String type)
  disableServerName(String type)
  enableServerName(String type)
  isDisabledServerName(String type)
  getServerNames()
 
For server side, the related APIs are:
  setServerNamePattern(String type, Pattern pattern)
  clearServerNamePattern(String type)
  getServerNamePatterns()
 
 2. close the door to use the generated socket in client mode.
 
SSLSocketFactory.createSocket(Socket s,
InputStream consumed, boolean autoClose)
 
The returned socket was set in server mode.
 
 Regards,
 Xuelei
 

Re: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension

[Sean Mullan]

SSLSocketFactory

- The new createSocket throws an IAE if the socket is an SSLSocket, but the
existing createSocket method doesn't. That seems a bit odd, what do we 
currently do?

--Sean


On 8/12/12 8:50 AM, Xuelei Fan wrote:
 Hi,
 
 Please review the spec of JEP 114, TLS Server Name Indication (SNI)
 Extension.
 
 http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/
 
 Please read the README to help you understanding the the specification:
 
http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt
 
 The major differences comparing with previous webrev are:
 1. client mode and server mode will use separated API set.
For client, the related APIs are:
  setServerName(String type, String value)
  clearServerName(String type)
  disableServerName(String type)
  enableServerName(String type)
  isDisabledServerName(String type)
  getServerNames()
 
For server side, the related APIs are:
  setServerNamePattern(String type, Pattern pattern)
  clearServerNamePattern(String type)
  getServerNamePatterns()
 
 2. close the door to use the generated socket in client mode.
 
SSLSocketFactory.createSocket(Socket s,
InputStream consumed, boolean autoClose)
 
The returned socket was set in server mode.
 
 Regards,
 Xuelei
 

Re: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension

[Sean Mullan]

SSLParameters:

In your README, you write:

Unknown server name type will be expressed as sni-integer, and the
value of the name is encoded as UTF-8 string.

This needs to be documented in the APIs. I think you should also be more
specific about what integer means - I assume this is the type value in the SNI
extension?

- It might be useful to add a public String constant for the host_name type,
ex: SSLParameters.SNI_HOST_NAME.

setServerName:

In client mode, it is recommended that, by default, providers should include
the server name indication whenever the server can be located by a supported
name type.

If we say recommended it means that it isn't a violation of the specification
if a provider doesn't do this, and that makes it impossible to test compliance
and harder for apps to depend on consistent behavior across different providers.
I think we should strongly consider changing recommended and should to
required and must here. Is there any reason why a provider wouldn't want to
do this?

--Sean

On 8/12/12 8:50 AM, Xuelei Fan wrote:
 Hi,
 
 Please review the spec of JEP 114, TLS Server Name Indication (SNI)
 Extension.
 
 http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/
 
 Please read the README to help you understanding the the specification:
 
http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt
 
 The major differences comparing with previous webrev are:
 1. client mode and server mode will use separated API set.
For client, the related APIs are:
  setServerName(String type, String value)
  clearServerName(String type)
  disableServerName(String type)
  enableServerName(String type)
  isDisabledServerName(String type)
  getServerNames()
 
For server side, the related APIs are:
  setServerNamePattern(String type, Pattern pattern)
  clearServerNamePattern(String type)
  getServerNamePatterns()
 
 2. close the door to use the generated socket in client mode.
 
SSLSocketFactory.createSocket(Socket s,
InputStream consumed, boolean autoClose)
 
The returned socket was set in server mode.
 
 Regards,
 Xuelei
 

Re: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension

[Brad Wetmore]

Still looking over the changes, but a few preliminary comments.

On 8/12/2012 5:50 AM, Xuelei Fan wrote:

Hi,

Please review the spec of JEP 114, TLS Server Name Indication (SNI)
Extension.

 http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/

Please read the README to help you understanding the the specification:

http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt


I forgot to mention this previously:

 Oracle provider now only supports one server name type, host_name.
 The value of name is encoded as UTF-8 string.

RFC 6066 requires ASCII, earlier versions (RFC 4366) have this as UTF-8. 
 Do you want to allow for UTF-8 here?



The major differences comparing with previous webrev are:
1. client mode and server mode will use separated API set.
For client, the related APIs are:
  setServerName(String type, String value)
  clearServerName(String type)
  disableServerName(String type)
  enableServerName(String type)
  isDisabledServerName(String type)
  getServerNames()


Please read my note on the 2nd round review before reading this, 
specifically the section that starts I'm not following your confusion.


So wow, what happened here?  I thought we were so very close on 
finalizing the API, and it was just a matter of tweaking the wording to 
have a null value disable the type from being sent.


setServerName(String type, String value) {
if type == value
throw IAE;
if value == null
map.remove(type);
return;
else if value.equals()
throw IAE;
else
map.put(value);
}

Then in the Handshakers, only those type/values that are present in the 
map are be pulled out for constructing the SNI extensions.


If you want to go with this new API style with clear/disable/enable, I 
can see where you are coming from, but that was unexpected.  Before I 
review for accuracy, I want to make sure you really want to tweak things 
so extensively.  I think what you had previously fit the bill pretty well.



For server side, the related APIs are:
  setServerNamePattern(String type, Pattern pattern)
  clearServerNamePattern(String type)
  getServerNamePatterns()


and same for this one.

I'll look over the rest once I get your answer to the above.


2. close the door to use the generated socket in client mode.

SSLSocketFactory.createSocket(Socket s,
InputStream consumed, boolean autoClose)

The returned socket was set in server mode.


Brad

Re: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension

[Xuelei Fan]

On 8/14/2012 10:01 PM, Sean Mullan wrote:
 SSLSocketFactory
 
 - The new createSocket throws an IAE if the socket is an SSLSocket, but the
 existing createSocket method doesn't. That seems a bit odd, what do we 
 currently do?

For the existing createSocket, it does not work when the socket is an
instance of SSLSocket. It is expected to read and write raw SSL records
from the socket. But if it is SSLSocket, the I/O are for application
data over the TLS layer.

I want to describe it clear in the new API.

Xuelei


 --Sean
 
 
 On 8/12/12 8:50 AM, Xuelei Fan wrote:
 Hi,

 Please review the spec of JEP 114, TLS Server Name Indication (SNI)
 Extension.

 http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/

 Please read the README to help you understanding the the specification:

http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt

 The major differences comparing with previous webrev are:
 1. client mode and server mode will use separated API set.
For client, the related APIs are:
  setServerName(String type, String value)
  clearServerName(String type)
  disableServerName(String type)
  enableServerName(String type)
  isDisabledServerName(String type)
  getServerNames()

For server side, the related APIs are:
  setServerNamePattern(String type, Pattern pattern)
  clearServerNamePattern(String type)
  getServerNamePatterns()

 2. close the door to use the generated socket in client mode.

SSLSocketFactory.createSocket(Socket s,
InputStream consumed, boolean autoClose)

The returned socket was set in server mode.

 Regards,
 Xuelei

Re: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension

[Xuelei Fan]

On 8/15/2012 12:54 AM, Sean Mullan wrote:
 SSLParameters:
 
 In your README, you write:
 
 Unknown server name type will be expressed as sni-integer, and the
 value of the name is encoded as UTF-8 string.
 
 This needs to be documented in the APIs.
As we document the known server name types in Java doc. I thought it may
be enough to document unknown ones in java doc also. But I understand
your point if we define constants, SSLParameters.SNI_HOST_NAME.

 I think you should also be more
 specific about what integer means - I assume this is the type value in the 
 SNI
 extension?
 
Yes.

 - It might be useful to add a public String constant for the host_name type,
 ex: SSLParameters.SNI_HOST_NAME.
 
Good point.

 setServerName:
 
 In client mode, it is recommended that, by default, providers should include
 the server name indication whenever the server can be located by a supported
 name type.
 
 If we say recommended it means that it isn't a violation of the 
 specification
 if a provider doesn't do this, and that makes it impossible to test compliance
 and harder for apps to depend on consistent behavior across different 
 providers.
 I think we should strongly consider changing recommended and should to
 required and must here. Is there any reason why a provider wouldn't want 
 to
 do this?
 
From my point, it is mainly for compatibility. Third parties old
providers may not support SNI or may not provider default values. For
example, if the following is an old block of code:

SSLParameters sslParameters = new SSLParameters();
sslParameters.setCipheSuites(...);
...
SSLSocket sslSocket =
sslSocketFactory.createSocket(www.example.com, 443);
sslSocket.setParameters(sslParameters);

SunJSSE in JDK 7 will have the default value www.example.com, but
other vendors may not.  So I think if I use a strong tone,
must/required, applications may run into problems with old
providers.  I hope an application specify the value explicit in order to
avoid provider dependency.

Xuelei

 --Sean
 
 On 8/12/12 8:50 AM, Xuelei Fan wrote:
 Hi,

 Please review the spec of JEP 114, TLS Server Name Indication (SNI)
 Extension.

 http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/

 Please read the README to help you understanding the the specification:

http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt

 The major differences comparing with previous webrev are:
 1. client mode and server mode will use separated API set.
For client, the related APIs are:
  setServerName(String type, String value)
  clearServerName(String type)
  disableServerName(String type)
  enableServerName(String type)
  isDisabledServerName(String type)
  getServerNames()

For server side, the related APIs are:
  setServerNamePattern(String type, Pattern pattern)
  clearServerNamePattern(String type)
  getServerNamePatterns()

 2. close the door to use the generated socket in client mode.

SSLSocketFactory.createSocket(Socket s,
InputStream consumed, boolean autoClose)

The returned socket was set in server mode.

 Regards,
 Xuelei

Re: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension

[Xuelei Fan]

On 8/15/2012 8:31 AM, Brad Wetmore wrote:
 Still looking over the changes, but a few preliminary comments.
 
 On 8/12/2012 5:50 AM, Xuelei Fan wrote:
 Hi,

 Please review the spec of JEP 114, TLS Server Name Indication (SNI)
 Extension.

  http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/

 Please read the README to help you understanding the the specification:

 http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt
 
 I forgot to mention this previously:
 
 Oracle provider now only supports one server name type, host_name.
 The value of name is encoded as UTF-8 string.
 
 RFC 6066 requires ASCII, earlier versions (RFC 4366) have this as UTF-8.
  Do you want to allow for UTF-8 here?
 
Good point! I think we may send ASCII, but accept UTF-8. Need to
consider it more during implementation.

 The major differences comparing with previous webrev are:
 1. client mode and server mode will use separated API set.
 For client, the related APIs are:
   setServerName(String type, String value)
   clearServerName(String type)
   disableServerName(String type)
   enableServerName(String type)
   isDisabledServerName(String type)
   getServerNames()
 
 Please read my note on the 2nd round review before reading this,
 specifically the section that starts I'm not following your confusion.
 
 So wow, what happened here?  I thought we were so very close on
 finalizing the API, and it was just a matter of tweaking the wording to
 have a null value disable the type from being sent.
 
 setServerName(String type, String value) {
 if type == value
 throw IAE;
 if value == null
 map.remove(type);
 return;
 else if value.equals()
 throw IAE;
 else
 map.put(value);
 }
 
 Then in the Handshakers, only those type/values that are present in the
 map are be pulled out for constructing the SNI extensions.
 
 If you want to go with this new API style with clear/disable/enable, I
 can see where you are coming from, but that was unexpected.  Before I
 review for accuracy, I want to make sure you really want to tweak things
 so extensively.  I think what you had previously fit the bill pretty well.

 For server side, the related APIs are:
   setServerNamePattern(String type, Pattern pattern)
   clearServerNamePattern(String type)
   getServerNamePatterns()
 
 and same for this one.
 
Sorry about that. It's not an easy trad-off for me between fewer APIs
and clearer APIs. The underlying motivation pushed me to extend the APIs
is that we may don't want the developers to find the usage of null
from java doc, and remember what the null value means. The new APIs
are more clear to me.

Sorry. No main framework changes, hope it is the final revision of the
APIs. ;-)

Thanks,
Xuelei

 I'll look over the rest once I get your answer to the above.
 
 2. close the door to use the generated socket in client mode.

 SSLSocketFactory.createSocket(Socket s,
 InputStream consumed, boolean autoClose)

 The returned socket was set in server mode.
 
 Brad
 

Re: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension

[Xuelei Fan]

On 8/13/2012 11:34 AM, Weijun Wang wrote:
  511  * If a server name type is not contained in the returned 
 codeMap/code,
  512  * an SSL/TLS handshaking should not be interrupted for reasons of
  513  * unrecognized server name of that type.
 
 Is this only Oracle JSSE behavior? Or every vendor should do that? Of course, 
 I have no good idea how a server can get a default pattern.
 
It's the required behavior for all providers.  According to TLS
extensions spec, a server run into unknown extensions, it should ignore
the extension and continue the transactions.  And for compatibilities, a
server also should ignore the SNI extension.  So I would like it to be a
behavior of all providers.

 SSLSocketFactory.java:
  202  * P
  203  * Please NOTE that the application is responsible for ensuring that 
 this
  204  * method must be called before any handshaking occurs, and all
  205  * consumed network data must be resumable from the 
 codeconsumed/code
  206  * parameter.  Otherwise, the behavior of the returned socket is not
  207  * defined.
 
 I think the precise meaning of any handshaking occurs is any bytes is sent 
 back to client?
 
Yes, I will do dome word smithing here.

Thanks,
Xuelei

(3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension

[Xuelei Fan]

Hi,

Please review the spec of JEP 114, TLS Server Name Indication (SNI)
Extension.

http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/

Please read the README to help you understanding the the specification:

   http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt

The major differences comparing with previous webrev are:
1. client mode and server mode will use separated API set.
   For client, the related APIs are:
 setServerName(String type, String value)
 clearServerName(String type)
 disableServerName(String type)
 enableServerName(String type)
 isDisabledServerName(String type)
 getServerNames()

   For server side, the related APIs are:
 setServerNamePattern(String type, Pattern pattern)
 clearServerNamePattern(String type)
 getServerNamePatterns()

2. close the door to use the generated socket in client mode.

   SSLSocketFactory.createSocket(Socket s,
   InputStream consumed, boolean autoClose)

   The returned socket was set in server mode.

Regards,
Xuelei

Re: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name Indication (SNI) Extension

[Weijun Wang]

ExtendedSSLSession.java:

+ * @return a non-null immutable map of requested server name types and
+ *values of the SNI capability, may be empty if the capability
+ *is not available. The iteration ordering of the map is the same
+ *as that in the requested server name indication.

Does capability is not available mean the client has not sent the extension?

SSLParameters.java:

Do you want to explicitly point out that the vendor-defined value will not show 
in the map?

289  * whenever the server can be located by a supported name type.

Maybe determined for a supported name type?

291  * For example, in the following exampless,

How about simply In the following examples,?

 459  * pre
 460  * sslParameters.setServerNamePattern(host_name,
 461  * Pattern.compile(*\\.example\\.com));
 462  * /pre
 463  * means that the server can serve as any hostname in the example.com
 464  * domain.
 
Do you mean .*\\.example\\.com?

 511  * If a server name type is not contained in the returned 
codeMap/code,
 512  * an SSL/TLS handshaking should not be interrupted for reasons of
 513  * unrecognized server name of that type.

Is this only Oracle JSSE behavior? Or every vendor should do that? Of course, I 
have no good idea how a server can get a default pattern.

SSLSocketFactory.java:

 191  * This constructor is normally used to enable SSL/TLS transactions 
over
 192  * an existing server acceped socket. The returned socket was set to 
use
 193  * server mode when handshaking (see
 194  * {@link SSLSocket#setUseClientMode(boolean)}).

s/acceped/accepted/. And, what does was mean here?

 196  * The codeconsumed/code data may be used for inspection of inbound
 197  * network data, for example, inspection of Server Name Indication 
(SNI)
 198  * (See section 3 of A HREF=http://www.ietf.org/rfc/rfc6066.txt;TLS
 199  * Extensions (RFC6066)/A).  In this contruction, the
 200  * codeconsumed/code inbound network data is provided to the 
returned
 201  * socket's normal I/O streams.

s/contruction/constructor/. I know what you mean but the words are a little 
strange. Also, maybe you need to mention consumed right in the first line of 
the method spec. That's why this method is special.

 202  * P
 203  * Please NOTE that the application is responsible for ensuring that 
this
 204  * method must be called before any handshaking occurs, and all
 205  * consumed network data must be resumable from the 
codeconsumed/code
 206  * parameter.  Otherwise, the behavior of the returned socket is not
 207  * defined.

I think the precise meaning of any handshaking occurs is any bytes is sent 
back to client?

Thanks
Max


- Original Message -
From: xuelei@oracle.com
To: security-dev@openjdk.java.net
Sent: Sunday, August 12, 2012 8:51:39 PM GMT +08:00 Beijing / Chongqing / Hong 
Kong / Urumqi
Subject: (3rd Round) Proposed API Changes for JEP 114: TLS Server Name 
Indication (SNI) Extension

Hi,

Please review the spec of JEP 114, TLS Server Name Indication (SNI)
Extension.

http://cr.openjdk.java.net./~xuelei/7068321/webrev_spec.04/

Please read the README to help you understanding the the specification:

   http://cr.openjdk.java.net./~xuelei/7068321/README_04.txt

The major differences comparing with previous webrev are:
1. client mode and server mode will use separated API set.
   For client, the related APIs are:
 setServerName(String type, String value)
 clearServerName(String type)
 disableServerName(String type)
 enableServerName(String type)
 isDisabledServerName(String type)
 getServerNames()

   For server side, the related APIs are:
 setServerNamePattern(String type, Pattern pattern)
 clearServerNamePattern(String type)
 getServerNamePatterns()

2. close the door to use the generated socket in client mode.

   SSLSocketFactory.createSocket(Socket s,
   InputStream consumed, boolean autoClose)

   The returned socket was set in server mode.

Regards,
Xuelei