Re: [TLS] Alert after sending ServerHello

2017-04-26 Thread Martin Thomson
You are allowed to out NSS. We know that it's not ideal. I wrote that code and it's unencrypted for what I think is a good reason (others very much disagree). In part, it has to do with 0-RTT. In 0-RTT, we want to ensure that the client is able to continue sending 0-RTT until the entire server

Re: [TLS] Issue #964: Shortened HKDF labels

2017-04-26 Thread Martin Thomson
Unsurprisingly, this was easy to implement. If anyone else is tracking this closely, I can share a version of NSS that includes this change (and pretends to be an implementation of -20). On 26 April 2017 at 07:50, Eric Rescorla wrote: > PR here: >

Re: [TLS] Issue #964: Shortened HKDF labels

2017-04-26 Thread Ilari Liusvaara
On Wed, Apr 26, 2017 at 04:51:01PM +1000, Martin Thomson wrote: > Unsurprisingly, this was easy to implement. If anyone else is > tracking this closely, I can share a version of NSS that includes this > change (and pretends to be an implementation of -20). Not very hard, altough I had to do some

Re: [TLS] Alert after sending ServerHello

2017-04-26 Thread Ilari Liusvaara
On Wed, Apr 26, 2017 at 03:01:40AM +, Roelof Du Toit wrote: > During interop testing with an open-source stack I ran into the following: > CH > > < SH,{EE,Cert,CV,Fin} > alert > > > The alert was due to a decode error on CV, and the stack in question > sent the alert in a

Re: [TLS] Alert after sending ServerHello

2017-04-26 Thread Ilari Liusvaara
On Wed, Apr 26, 2017 at 04:35:31PM +1000, Martin Thomson wrote: > You are allowed to out NSS. We know that it's not ideal. > > I wrote that code and it's unencrypted for what I think is a good > reason (others very much disagree). In part, it has to do with 0-RTT. > > In 0-RTT, we want to

Re: [TLS] Alert after sending ServerHello

2017-04-26 Thread Martin Thomson
On 26 April 2017 at 22:25, Martin Rex wrote: >> The code I was talking about was handling the special case that the >> server might receive either encrypted or unencrypted alert in response >> to its flight. And the difference it makes is just what error is >> declared as abort

Re: [TLS] Alert after sending ServerHello

2017-04-26 Thread Martin Rex
Ilari Liusvaara wrote: >> In effect, we assume that the entire flight is processed atomically >> and generate errors based on that. Only when the entire flight is >> processed cleanly do we install keys and respond. > > My implementation processes message-by-message. So it installs the > client

Re: [TLS] TLS RSA-PSS and various versions of TLS

2017-04-26 Thread Ilari Liusvaara
On Wed, Apr 26, 2017 at 03:23:57PM +0200, Martin Rex wrote: > > Signatures on certificates are created by CAs, rather than TLS endpoints, > so any implementation that uses TLS protocol parameters (about TLS signature > algorithms) for more than a mere cert selection hint, is actively creating >

Re: [TLS] Alert after sending ServerHello

2017-04-26 Thread Ilari Liusvaara
On Wed, Apr 26, 2017 at 10:00:19PM +1000, Martin Thomson wrote: > On 26 April 2017 at 17:19, Ilari Liusvaara wrote: > > AFAIK, the only situations where client can abort sending 0-RTT data > > is noticing lack of server EarlyData extension (so server isn't > > listening

Re: [TLS] TLS RSA-PSS and various versions of TLS

2017-04-26 Thread Martin Rex
Dr Stephen Henson wrote: > On 25/04/2017 15:36, Benjamin Kaduk wrote: >> >>RSASSA-PSS algorithms Indicates a signature algorithm using RSASSA- >> PSS [RFC3447 ] with mask >> generation function 1. The digest used in >> the mask generation

Re: [TLS] [EXT] Re: Alert after sending ServerHello

2017-04-26 Thread Roelof Du Toit
Yes, I agree that the problem is error handling. I get that it is trivial to distinguish encrypted from unencrypted, but I would appreciate it if the spec could clarify the appropriate actions in the scenario where an unencrypted (non-appdata) record is received after keys have been installed

Re: [TLS] CertficateRequest extension encoding

2017-04-26 Thread Ilari Liusvaara
On Mon, Sep 05, 2016 at 09:46:51PM +, Andrei Popov wrote: > > Do we need to make it this flexible? The idea was to avoid adding > complexity to the certificate filtering code in the TLS stack, and > instead filter by OIDs in the PKI library. PKI libraries already > inspect and match OID

Re: [TLS] Alert after sending ServerHello

2017-04-26 Thread Martin Thomson
On 26 April 2017 at 23:44, Ilari Liusvaara wrote: > But stopping on receiving EncryptedExtensions with EarlyData extension > is racy. How so? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls