Re: [TLS] RFC5746: Renegotiation Indication for minimal servers

2016-08-02 Thread Benjamin Kaduk
On 08/02/2016 09:32 AM, Bauer Johannes (HOME/EFS) wrote: > > So I take it my interpretation is correct -- these values are only ever > required for renegotiation and serve no other purpose? I.e. the hint can > safely be ignored in this case and the implementation will still be fully > RFC5746-co

Re: [TLS] RFC5746: Renegotiation Indication for minimal servers

2016-08-02 Thread Bauer Johannes (HOME/EFS)
Hi Watson, On Tue, Aug 2, 2016 at 16:02, Watson Ladd wrote: >> However, there is also this in Sect. 3.6 which has caused some confusion and >> lengthy discussion among my colleagues and myself: >> >>o When the handshake has completed, the server needs to save the >> client_verify_data

Re: [TLS] RFC5746: Renegotiation Indication for minimal servers

2016-08-02 Thread Watson Ladd
On Tue, Aug 2, 2016 at 6:33 AM, Bauer Johannes (HOME/EFS) wrote: > Dear mailing list, > > regarding RFC5746 (https://tools.ietf.org/rfc/rfc5746.txt) I do have a > question which could not be solved in our internal discussions. Therefore I > would kindly ask for your comments on my issue. If I po

Re: [TLS] Keeping TLS extension points working

2016-08-02 Thread David Benjamin
To expand on that a little, since it seems comments (a) and (b) are really the same one: The purpose of having an explicitly reserved list (b) is precisely so we do not have to do a second handshake (a). The purpose here is to ensure we exercise the little-used codepaths, not introduce new ones. T

[TLS] RFC5746: Renegotiation Indication for minimal servers

2016-08-02 Thread Bauer Johannes (HOME/EFS)
Dear mailing list, regarding RFC5746 (https://tools.ietf.org/rfc/rfc5746.txt) I do have a question which could not be solved in our internal discussions. Therefore I would kindly ask for your comments on my issue. If I posted to the wrong place, please advise on where such a question would be r

Re: [TLS] Post-handshake Finished when rejecting a CertificateRequest

2016-08-02 Thread Eric Rescorla
On Tue, Aug 2, 2016 at 5:25 AM, Ilari Liusvaara wrote: > On Tue, Aug 02, 2016 at 08:40:08PM +1000, Martin Thomson wrote: > > On 2 August 2016 at 17:48, Ilari Liusvaara > wrote: > > > Also, what exact base key does that Finished use? Client's current > > > traffic secret at the beginning of the F

Re: [TLS] Post-handshake Finished when rejecting a CertificateRequest

2016-08-02 Thread Ilari Liusvaara
On Tue, Aug 02, 2016 at 08:40:08PM +1000, Martin Thomson wrote: > On 2 August 2016 at 17:48, Ilari Liusvaara wrote: > > Also, what exact base key does that Finished use? Client's current > > traffic secret at the beginning of the Finished (the sequence of > > traffic secrets is the same client and

Re: [TLS] Post-handshake Finished when rejecting a CertificateRequest

2016-08-02 Thread Martin Thomson
On 2 August 2016 at 17:48, Ilari Liusvaara wrote: > Also, what exact base key does that Finished use? Client's current > traffic secret at the beginning of the Finished (the sequence of > traffic secrets is the same client and server, but the values may > be out of sync.)? Presumably it's the tr

Re: [TLS] Post-handshake Finished when rejecting a CertificateRequest

2016-08-02 Thread Ilari Liusvaara
On Tue, Aug 02, 2016 at 03:03:13PM +1000, Martin Thomson wrote: > https://github.com/tlswg/tls13-spec/issues/572 > > Discuss. Yeah, noticed that when trying to implement stuff. I do not see any point in sending Finished in that case. Not sending Finished would also make implementations that don't