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

[Stefan Santesson <stefan at aaa-sec.com>]

Martin,

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.

/Stefan


On 09-11-20 10:54 PM, "Martin Rex" <mrex at sap.com> wrote:

> 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
> _______________________________________________
> TLS mailing list
> TLS at ietf.org
> https://www.ietf.org/mailman/listinfo/tls