On Saturday 05 December 2015 23:54:25 Peter Gutmann wrote:
> Hubert Kario writes:
> >miTLS does accept Application Data when it is send between Client
> >Hello and Client Key Exchange and rejects it when it is sent between
> >Change Cipher Spec and Finished.
>
> Given that
Our state machine design in miTLS was quite deliberate, and based on our
interpretation of the TLS 1.2 spec. It is possible that we got this
interpretation wrong, but maybe the protocol authors can clarify the intended
behavior.
However, I think that looking at the Handshake protocol message
On Saturday 05 December 2015 19:20:11 Watson Ladd wrote:
> On Sat, Dec 5, 2015 at 6:54 PM, Peter Gutmann
wrote:
> > Hubert Kario writes:
> >>miTLS does accept Application Data when it is send between Client
> >>Hello and Client Key Exchange and
On Sunday 06 December 2015 02:33:39 Peter Gutmann wrote:
>
> No matter how you colour it, accepting
> Application Data after a Client Hello is wrong. Is there any random,
> non-formally-verified implementation that would do that?
The discussion is about renegotiated handshakes, and yes there is
Watson Ladd writes:
>On Sat, Dec 5, 2015 at 6:54 PM, Peter Gutmann
>wrote:
>> Hubert Kario writes:
>>
>>>miTLS does accept Application Data when it is send between Client Hello and
>>>Client Key Exchange and rejects it when
On Sat, Dec 5, 2015 at 8:18 PM, Peter Gutmann wrote:
> Watson Ladd writes:
>>On Sat, Dec 5, 2015 at 6:54 PM, Peter Gutmann
>>wrote:
>>> Hubert Kario writes:
>>>
miTLS does accept Application
Watson Ladd writes:
>miTLS did not claim to be consistent with the RFC. Rather it claimed to be
>secure, and to interoperate with most other implementations in circumstances
>tested. The informal nature of the RFC makes it impossible to carry out
>formal verification
On Friday 16 October 2015 22:36:10 Kurt Roeckx wrote:
> On Fri, Oct 16, 2015 at 04:05:34PM +0200, Hubert Kario wrote:
> > On Friday 16 October 2015 09:16:01 Watson Ladd wrote:
> > > Unfortunately I don't know how to verify this. Can miTLS cover
> > > this
> > > case?
> >
> > you mean, you want an
On Fri, Oct 16, 2015 at 04:05:34PM +0200, Hubert Kario wrote:
> On Friday 16 October 2015 09:16:01 Watson Ladd wrote:
> > Unfortunately I don't know how to verify this. Can miTLS cover this
> > case?
>
> you mean, you want an implementation that can insert application data in
> any place of the
On 15/10/15 14:00, Martin Rex wrote:
> Is the particular interop problem that you want to address
> caused by a necessity to really process application data and
> handshake data with arbitrary interleave,
>
> or is it rather a problem of getting back into half-duplex operation,
> i.e. a client
Is the particular interop problem that you want to address
caused by a necessity to really process application data and
handshake data with arbitrary interleave,
or is it rather a problem of getting back into half-duplex operation,
i.e. a client being able to continue receiving application data
On 15/10/15 00:04, Watson Ladd wrote:
> On Wed, Oct 14, 2015 at 6:43 PM, Matt Caswell wrote:
>>
>>
>> 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
On 15/10/15 00:06, Martin Thomson wrote:
> On 14 October 2015 at 15:43, Matt Caswell wrote:
>> "highly dangerous idea"
>
> Wrong Martin.
Oops. Sorry.
> I agree that there is a need for caution, but in
> reality, it's not like you can use renegotiation to hand-off to
>
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).
>
>
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
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
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
Hello,
Does anyone have any views on the below?
Thanks
Matt
On 30/09/15 11:06, Matt Caswell wrote:
> Hi all
>
> I have a question on how to interpret RFC 5246 with regards to the
> interleaving of app data and handshake records.
>
> RFC 5246 (and RFC 4346 before it) contains these words:
>
>
On Tue, Oct 13, 2015 at 10:12:45AM +0100, Matt Caswell wrote:
>
> On 30/09/15 11:06, Matt Caswell wrote:
> > Hi all
> >
> > I have a question on how to interpret RFC 5246 with regards to the
> > interleaving of app data and handshake records.
>
> Hello,
>
> Does anyone have any views on the
Resending from my account that is actually subscribed to this list!
Apologies if you receive this twice...
Forwarded Message
Subject: Clarification on interleaving app data and handshake records
Date: Wed, 30 Sep 2015 11:02:55 +0100
From: Matt Caswell
To:
20 matches
Mail list logo