Matt Caswell wrote:
>
> Does anyone have any views on the below?
Yup. Interleaving application & handshake records is a
highly dangerous idea (and fortunately some TLS implementations
will abort if you try).
http://www.ietf.org/mail-archive/web/tls/current/msg07648.html
http://www.ietf.org/mai
On 14/10/15 16:44, Martin Rex wrote:
> Matt Caswell wrote:
>>
>> Does anyone have any views on the below?
>
> Yup. Interleaving application & handshake records is a
> highly dangerous idea (and fortunately some TLS implementations
> will abort if you try).
>
> http://www.ietf.org/mail-archive/
On Wed, Oct 14, 2015 at 4:05 PM Matt Caswell wrote:
> On 14/10/15 16:44, Martin Rex wrote:
> > Matt Caswell wrote:
> >>
> >> Does anyone have any views on the below?
> >
> > Yup. Interleaving application & handshake records is a
> > highly dangerous idea (and fortunately some TLS implementations
As discussed at the Interim, I've submitted a separate PR for TLS 1.3
CertificateRequest changes: https://github.com/tlswg/tls13-spec/pull/290
PR #290 includes the following changes:
1. Removes certificate_types, which are no longer needed.
2. Adds client cert selection by certificate extension v
On Wed, Oct 14, 2015 at 4:42 PM Martin Thomson
wrote:
> On 14 October 2015 at 13:29, David Benjamin wrote:
> > If you really absolutely must support interleave and can't avoid it, I
> think
> > it being allowed everywhere except between CCS and Finished is probably
> the
> > closest you can get
On 14/10/15 21:42, Martin Thomson wrote:
> On 14 October 2015 at 13:29, David Benjamin wrote:
>> If you really absolutely must support interleave and can't avoid it, I think
>> it being allowed everywhere except between CCS and Finished is probably the
>> closest you can get to coherent semantic