Re: TLS ALPN Proposal v2

2015-06-04 Thread Xuelei Fan
On 6/5/2015 8:37 AM, Bradford Wetmore wrote: >> I'd like to use: >> >> - * Gets the application protocol value(s) received from the peer >> - * for this connection. >> + * Gets a {@link List} of requested application protocol value(s) >> + * for this connection. > > I've never seen a link insi

Re: TLS ALPN Proposal v2

2015-06-04 Thread Xuelei Fan
Hi, See inlines, please. On 6/5/2015 5:30 AM, Simone Bordet wrote: > Hi, > > On Thu, Jun 4, 2015 at 6:50 PM, Xuelei Fan wrote: >> Hm, I see your point now. But I may not agree with your ALPN "MUST >> happen after" protocol/cipher suite negotiation conclusion. >> >> I parse this section as, a H

Re: TLS ALPN Proposal v2

2015-06-04 Thread Bradford Wetmore
On 6/2/2015 11:23 PM, Xuelei Fan wrote: src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java = List getReceivedApplicationProtocols() -- C1. It might be useful to know the cl

Re: RFR 7191662: JCE providers should be located via ServiceLoader

2015-06-04 Thread Valerie Peng
Build experts, Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 This is for merging the java.security.Provider file from various providers and use the (mer

Re: TLS ALPN Proposal v2

2015-06-04 Thread Simone Bordet
Hi, On Thu, Jun 4, 2015 at 6:50 PM, Xuelei Fan wrote: > Hm, I see your point now. But I may not agree with your ALPN "MUST > happen after" protocol/cipher suite negotiation conclusion. > > I parse this section as, a H2 server must be strong enough(comply to > RFC7540), and a H2 client must also

RSA intrinsics [Was: RFR(L): 8069539: RSA acceleration]

2015-06-04 Thread Andrew Haley
I'm sorry this is a rather long email, and I pray for your patience. I'm getting close to something I can put forward for review. The performance is encouraging. [ Some background: The kernel of RSA and Diffie-Hellman key exchange is Montgomery multiplication. Optimizing RSA basically comes dow

Re: TLS ALPN Proposal v2

2015-06-04 Thread Xuelei Fan
On 6/5/2015 12:12 AM, Simone Bordet wrote: > Hi, > > On Thu, Jun 4, 2015 at 5:53 PM, Xuelei Fan wrote: >> On 6/4/2015 8:19 PM, Simone Bordet wrote: >>> This is not possible for HTTP/2. >>> Application protocol negotiation MUST happen *after* the TLS protocol >>> and the TLS cipher are negotiated.

Re: TLS ALPN Proposal v2

2015-06-04 Thread Simone Bordet
Hi, On Thu, Jun 4, 2015 at 5:53 PM, Xuelei Fan wrote: > On 6/4/2015 8:19 PM, Simone Bordet wrote: >> This is not possible for HTTP/2. >> Application protocol negotiation MUST happen *after* the TLS protocol >> and the TLS cipher are negotiated. >> > Why? Is it a spec of HTTP/2? It is a point I d

Re: TLS ALPN Proposal v2

2015-06-04 Thread Michael McMahon
On 04/06/15 15:18, Simone Bordet wrote: Hi, On Thu, Jun 4, 2015 at 3:08 PM, Michael McMahon wrote: On 04/06/15 13:19, Simone Bordet wrote: Hi, On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote: Per section 4, RFC 7301: "... The "application_layer_protocol_negotiation" ServerHello e

Re: TLS ALPN Proposal v2

2015-06-04 Thread Xuelei Fan
On 6/4/2015 8:19 PM, Simone Bordet wrote: > Hi, > > On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote: >> Per section 4, RFC 7301: >> "... The >>"application_layer_protocol_negotiation" ServerHello extension is >>intended to be definitive for the connection (until the connection is >>

Re: TLS ALPN Proposal v2

2015-06-04 Thread Simone Bordet
Hi, On Thu, Jun 4, 2015 at 3:08 PM, Michael McMahon wrote: > On 04/06/15 13:19, Simone Bordet wrote: >> >> Hi, >> >> On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote: >>> >>> Per section 4, RFC 7301: >>>"... The >>> "application_layer_protocol_negotiation" ServerHello extension is >>>

Re: TLS ALPN Proposal v2

2015-06-04 Thread Michael McMahon
On 04/06/15 13:19, Simone Bordet wrote: Hi, On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote: Per section 4, RFC 7301: "... The "application_layer_protocol_negotiation" ServerHello extension is intended to be definitive for the connection (until the connection is renegotiated) a

Re: TLS ALPN Proposal v2

2015-06-04 Thread Simone Bordet
Hi, On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote: > Per section 4, RFC 7301: > "... The >"application_layer_protocol_negotiation" ServerHello extension is >intended to be definitive for the connection (until the connection is >renegotiated) and is sent in plaintext to permit net

Re: TLS ALPN Proposal v2

2015-06-04 Thread Simone Bordet
Hi, On Wed, Jun 3, 2015 at 2:56 AM, Bradford Wetmore wrote: > Hi, > > I have just posted the second iteration of the ALPN proposal which hopefully > addresses all of the comments raised here. It is in javadoc format, but > things can certainly be adjusted: > > http://cr.openjdk.java.net/~wet

Re: [9] Review request for 8072515: Test Task: Develop new tests for JEP 219: Datagram Transport Layer Security (DTLS)

2015-06-04 Thread Konstantin Shefov
Hi Xue-Lei Thanks for reviewing! I will reduce the line size, make JPRT testing and push then. -Konstantin On 06/04/2015 04:57 AM, Xuelei Fan wrote: Looks fine to me. It's nice to keep each line not exceed 80 characters. For example - * @run main/othervm -Dtest.security.protocol=DTLS -Dt