Re: [TLS] merging recent ideas into one new proposal

[Martin Rex <mrex at sap.com>]

Stefan,

Stefan Santesson wrote:
> 
> The repurposing of basic protocol elements smells too much like
> an ugly hack to me. It give me all kinds of bad vibes.
> 
> I liked the old proposal better.

Thanks for the feedback.  When I just started to describe the architecture
of storing the verify_data of the previous Finished message in the
Hello.Random, I realized that interop-testing this would not provide
any proof that an implementation was no longer vulnerable,
i.e. it's a fail UNsafe design just like TLS extension RI.


So I'm going to complete the I-D with the last design, based
on "manually" adding the verify_data to the handshake hashes
and S->C signaling through server_version.


-Martin

PS: I still like Steve's idea, though.  It would be fairly symmetric
in signaling: the Client offers a magic cipher suite for a modified
protocol first in his list of cipher_suites and the server agrees
to use it and sends it back in ServerHello.cipher_suite.

With the same symmetry, 32-bit of Hello.Random are re-purposed.
The negotiation through the ciphersuite would make this re-purposing
of the Hello.Random bits non-ambiguous and one could add
16 bidirectional signaling bits of extensibility for use by TLS WG.

If the information that you want to negotiate with your peer amounts
to essentially one bit, then a TLS extension is a pretty big
wrapping.  What would you say if your super-market would 
sell 1 quart of milk only in a box of lead that weighs 80lbs ?