Re: [TLS] Open Issue: verify_data processing

[Martin Rex <martin.rex@xxxxxxx>]

Pasi.Eronen@xxxxxxxxx wrote:
> 
> Vipul Gupta wrote:
> > I would also prefer hashing. Our research team has successfully
> > created a TLS stack for tiny, wireless sensor devices like the
> > Berkeley "motes" with only 4KB of RAM (see
> > http://research.sun.com/spotlight/2004-12-20_vgupta.html
> > http://research.sun.com/projects/crypto/guptav_sizzle_pmc.pdf).
> > If the spec were modified to require storing the handshake messages
> > in full, then TLS (and derivatives like DTLS) would pretty much
> > be ruled out for this emerging class of devices.
> 
> Is it obvious that hashing the messages requires less memory? Much of
> the information in the handshake messages is either static, or has to
> be kept around anyway -- and running hashes requires state, too.

The memory requirements are significantly higher if the protocol
stack needs to keep all of the handshake messages around, and
a lot more code is required resulting in more bugs.

How much of the information from small&friendly handshake
message are retained with the session state is entirely irrelevant
here.  Some of the values may not be stored in the original form,
i.e. some implementations will store some protocol values as
byte values, others will store it as integers of varying sizes
(which may reverse the order of LSB/MSB in memory), and it
would result in extremely bloated and error-prone code if an
implementation tried to compute the hash over the handshake
messages from unparsed session state information.

There were proposals to allow additional handshake messages,
the client hello can carry an extension which the server does not
need to recognize, but which goes into the hanshake message hash.
Then there is a cert request message with a list of trusted CAs
which may be fairly long, and cert messages may actually contain
fairly long certificate chains, not only one single certificate.


Personally, I found the original scheme much more appealing
(smaller memory footprint, smaller code), where
the protocol stack did NOT need to keep the handshake messages
around.

Is there a real-world security benefit (not a pure academic one)
justifying such a burden-some change?


-Martin

_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls