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
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
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
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
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
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
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
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
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
