I was just on the phone with Nasko Oskov and he came up with another
very interesting idea about how to get the verify data into the
handshake message hash of the renegotiation. I like that idea
even better than mine! So combined with Steve's idea to
signal S->C through ServerHello.cipher_suite, this is the result:
And this will fit into the SSL Version 2 ClientHello
(which is still permitted by RFC-5246 Appendix E !).
TLS/SSL ClientHello.Random maps to V2 ClientHello.challenge,
they're both 32-bytes
So the entire new scheme looks like this:
We put the first 12 bytes of the verify_data of the finished
messages into the Hello.Random of renegotiation handshakes.
This will obviate the need to hash them manually, they will
go into the handshake message hash through the respective
Randoms.
A new (single) magic ciphersuite ID, where the client requests
to talk the updated protocol. This must be first in the
ClientHello.cipher_suites.
ClientHello.Random
original new, initial HS new, renegotiation HS
{
uint32 gmt_unix_time uint32 gmt_unix_time uint32 gmt_unix_time
opaque random[32] uint16 new_flags uint16 new_flags
uint16 reserved uint16 reserved
opaque random[12] opaque random[12]
opaque random[12] opaque cli.verify_data[12]
}
= 32 bytes = 32 bytes = 32 bytes
When an updated server sees the new magic ciphersuite ID, then it
writes the magic cipher suite ID into ServerHello.cipher_suite
in order to confirm to the client the use of the changed protocol
and writes the real negotiated cipher suite ID into the new definition
of the ServerHello.Random:
ServerHello.Random
original new, initial HS new, renegotiation HS
uint32 gmt_unix_time uint32 gmt_unix_time uint32 gmt_unix_time
opaque random[32] uint16 new_flags uint16 new_flags
uint16 cipher_suite uint16 cipher_suite
opaque random[12] opaque random[12]
opaque random[12] opaque srv.verify_data[12]
}
= 32 bytes = 32 bytes = 32 bytes
For those wondering whether it is a good idea or safeto actually
cut into the Hello.Random that much?
I'm not a cryptographer, but I think it is safe.
The 2x 16 bit that I'm cutting with flags and relocated ciphersuite
is admittedly a loss in randomness. But it should be bearable.
What about the 12 bytes for the verify_data in the renegotiation
handshake? That should actually _not_ have an impact!
What are the necessary properties for Random, which serves as
a challenge for both communication peers.
- unique ? yes
- non-predictable ? yes
- secret ? no, it is sent in the clear
For the authentication of the previous session in the renegotiation
handshake, we actually assume for the verify_data of the finished
messages the following attributes:
- unique
- non-predictable
Of course, we should run this by cryptographers, but to me, it
does _not_ fundamentally flawed, but OK.
And what do I need that 16 bits of flags for?
Well, I think they do come in handy to grow a little fruit.
Those of the low hanging kind. :)
Possible uses of that Bitfield:
#define TLS_FLAG_SECURE_RENGOTIATE (1u<< 0)
#define TLS_FLAG_RENEGOTIATE_SAME_IDENTITY (1u<< 1)
#define TLS_FLAG_INITIAL_HANDSHAKE (1u<< 2)
#define TLS_FLAG_WILL_NOT_RENEGOTIATE (1u<< 3)
#define TLS_FLAG_HAVE_NO_CERT (1u<< 4)
-Martin
