RE: [TLS] Open Issue: verify_data processing

[<Pasi.Eronen@xxxxxxxxx>]

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.

For example, consider a TLS server that has just sent ServerHelloDone,
and has negotiated an RSA-based ciphersuite. At this point, the only
pieces of information from the handshake messages the server can
safely discard are:

- ClientHello.compression_methods (usually 2 bytes)
- ClientHello.cipher_suites (hmm.. 22 bytes with 10 ciphersuites?)
- ClientHello.session_id (just 1 byte if not resuming)
- Any unrecognized extensions in ClientHello (usually none)

All the rest has to be kept around anyway (at this point); and I'm
assuming the server certificate is static, so it's kept around 
anyway (once, not separately for each TLS session).

In other words: at this particular point-of-time, hashing would allow
discarding ~25 bytes of information, at the cost of storing the hash
context -- which in e.g. OpenSSL is 96 bytes for SHA-1 and 216 bytes 
for SHA-512. 

If we're using RSA ciphersuites and a PRF that requires only one pass
over the data, the client can start calculating verify_data as soon as
ServerHello has been received, so it's not obvious that first
calculating
a hash and then running PRF over the hash would actually save anything. 

Best regards,
Pasi

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