Re: [TLS] TLS 1.3 : small fragments attack

> On 30 Dec 2017, at 7:03, Peter Gutmann wrote: > > Jitendra Lulla writes: > >> The client can have a rogue TLS implementation with the following intentional >> changes: >> >> 0. Choose CBC with AES256-SHA56 or any other heavier (in terms of

Re: [TLS] TLS 1.3 : small fragments attack

> On Dec 30, 2017, at 12:38 AM, Peter Gutmann wrote: > > I think your idea in general is a good one, standards should include sanity > limits on what you should and shouldn't accept (I've managed to cause crashes > and reboots and whatnot on different servers by

Re: [TLS] TLS 1.3 : small fragments attack

Jitendra Lulla writes: >But what if such records, from the same session, come in a quantity of 1 >or more per second which could be generated by uploading a 500 MB file by the >client? My comment was meant as a general observation on how hard anomaly-detection is. At what

Re: [TLS] TLS 1.3 : small fragments attack

! On Sat, 12/30/17, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: Subject: Re: [TLS] TLS 1.3 : small fragments attack To: "tls@ietf.org" <tls@ietf.org>, "Jitendra Lulla" <lull...@yahoo.com> Date: Saturday, December 30, 2017, 5:03 AM Jite

Re: [TLS] TLS 1.3 : small fragments attack

Jitendra Lulla writes: >The client can have a rogue TLS implementation with the following intentional >changes: > >0. Choose CBC with AES256-SHA56 or any other heavier (in terms of processing >power requirements) and non paralleliz'able cipher suite. > >1. After the

[TLS] TLS 1.3 : small fragments attack

Hi, Is it possible for the standards/RFCs to dictate de-prioritization of certain troublesome TLS processing patterns? The RFCs -- may suggest identification of such patterns, -- may suggest implementation of certain low priority processing queues/threads/executions. Following is an