W3C home > Mailing lists > Public > ietf-tls@w3.org > October to December 1996

Re: draft agenda for San Jose meeting

From: Tim Dierks <timd@consensus.com>
Date: Tue, 3 Dec 1996 00:29:29 -0800
Message-Id: <v0300780daec99426f1f7@[206.86.17.90]>
To: Tom Weinstein <tomw@netscape.com>
Cc: Christopher Allen <ChristopherA@consensus.com>, Matt Hur <matt.hur@cybersafe.com>, ietf-tls@w3.org
At 4:26 PM -0800 12/2/96, Tom Weinstein wrote:
>If we are actually going to consider protocol changes at this time, or
>for the future, I'd also suggest a generalization of the block padding
>format.  I'd specify that blocks be padded with random data, and that
>that all blocks have (possibly zero-length) padding.  I'd also relax
>restriction on maximum padding length.  This would make it harder to
>perform a traffic analysis attack, but still allow implementations to
>forgo the padding if so desired.

I think this is a good suggestion, except that I would specify the contents
of the block data rather than using random data. I don't believe that
random data adds significantly to the security of the protocol, as any
significant communication will be well beyond the unicity distance; thus,
the verifiable plaintext of the padding won't aid attackers. The benefit of
using predictable data is that the peer can verify that padding is being
done as expected, which allows a greater rigidity around implementations,
which I believe aids security analysis.

If you'd like to avoid the padding data being known plaintext, you could
specify it in some what that it is unknown, yet verifiable. However, the
protocol should be strong against known-plaintext attacks anyway, as such
attacks are commonly available to attackers.

 - Tim

Tim Dierks - timd@consensus.com - www.consensus.com
     Software Haruspex - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite
Received on Tuesday, 3 December 1996 04:03:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:12 UTC