> 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 sending valid but unexpected
> d
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 point do you decide
The pattern is perfectly normal and might be assumed to be coming from an
interactive terminal.
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?
And how about 100s of such clients t
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 handshake, always send all th
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 example
On 28/12/17 18:06, Eric Rescorla wrote:
> I must be missing your point. According to the spec as it stands even
> with a stateful server I MUST ignore a CCS that comes first. Since this
> is a stateful server it may end up negotiating TLSv1.2 - which requires
> us to abort the han
