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 o
On Sunday 06 December 2015 02:48:33 Peter Gutmann wrote:
> Watson Ladd writes:
> >please cite the sentence of the TLS RFC which prohibits accepting
> >application data records during the handshake.
>
> Please cite the sentence of the TLS RFC which prohibits accepting SSH
> messages during the hand
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 se
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 rejects it when it is sent
> >>between Change Ciphe
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 miTLS is a formally ver
On Sun, Dec 06, 2015 at 01:18:51AM +, Peter Gutmann wrote:
>
> I hadn't even thought it through to that point, more that you're not supposed
> to accept anything between Client Hello and Client Keyex except an optional
> Client Certificate.
Please read the start of the thread, that includes r
On Sun, Dec 6, 2015 at 1:59 AM, Yoav Nir wrote:
>
>> On 6 Dec 2015, at 4:44 AM, Watson Ladd wrote:
>>
>> If you disagree, please cite the sentence of the TLS
>> RFC which prohibits accepting application data records during the
>> handshake.
>
> OK, I’ll bite. Top of page 36:
>
> Client
> On 6 Dec 2015, at 4:44 AM, Watson Ladd wrote:
>
> If you disagree, please cite the sentence of the TLS
> RFC which prohibits accepting application data records during the
> handshake.
OK, I’ll bite. Top of page 36:
Client Server
Cli
On Sat, Dec 5, 2015 at 9:48 PM, Peter Gutmann wrote:
> Watson Ladd writes:
>
>>please cite the sentence of the TLS RFC which prohibits accepting application
>>data records during the handshake.
>
> Please cite the sentence of the TLS RFC which prohibits accepting SSH messages
> during the handsha
Watson Ladd writes:
>please cite the sentence of the TLS RFC which prohibits accepting application
>data records during the handshake.
Please cite the sentence of the TLS RFC which prohibits accepting SSH messages
during the handshake.
Please cite the sentence of the TLS RFC which prohibits exe
On Sat, Dec 5, 2015 at 9:33 PM, Peter Gutmann wrote:
> 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
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 against it.
By that argument
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 Data when it is send between Client Hello and
Client Key Exchange and rejects it when it is sen
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 it is sent between Change Cipher Spec
>>>and Finished.
>>
>> Given that
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 it is sent between Change Cipher Spec
>>and Finished.
>
> Given that miTLS is a formally verified i
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 miTLS is a formally verified implementation, would this imply that
there's a problem with the
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 h
On Friday 16 October 2015 09:16:01 Watson Ladd wrote:
> On Thu, Oct 15, 2015 at 9:12 AM, Matt Caswell
wrote:
> > 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 da
On Thu, Oct 15, 2015 at 9:12 AM, Matt Caswell wrote:
>
>
> 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
On Wednesday 14 October 2015 16:06:00 Martin Thomson wrote:
> On 14 October 2015 at 15:43, Matt Caswell wrote:
> > "highly dangerous idea"
>
> Wrong Martin. I agree that there is a need for caution, but in
> reality, it's not like you can use renegotiation to hand-off to
> someone else entirely.
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 b
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
up
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
> someone else entirely.
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 and can't avoid it, I
think
it b
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
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 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
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/
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 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 below?
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:
>
>
32 matches
Mail list logo
