Subject: [MMUSIC] Terminology; RE: DTLS-O/A: DTLS fingerprint and setup role MUST NOT change unless underlying transport also changes

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 4 Mar 2015 07:55:12 +0000

Wrt:
>Hi,
>Is there are definition of ”(D)TLS rekey” somewhere?
>I find text talking about “re-doing the handshake”, but doesn’t that include re-sending the Client/ServerHello messages, which basically means re-establishing the (D)TLS >connection?
>Regards,
>Christer

The underlying MMUSIC draft requires either a) the inclusion of explicit term definitions or b) a reference to term definitions in (D)TLS RFCs.
Well, (b) isn’t possible, if, then we wouldn’t got that endless debates about rekeying, re-establishment, resumption, renegotiation, etc.
Hence (a), which could be addressed by following options:
a1) MMUSIC defines his own DTLS terms, according their best understanding of the (D)TLS RFCs
a2) MMUSIC Cc’s WG TLS in such emails and ask for resolution and explicit definitions by WG TLS experts, or
a3) whenever MMUSIC uses the term “DTLS re…”, then the term should be complemented by a reference to “RFC xyz, clause abc” at a very minimum.

The result of the SDP O/A process depends on unambiguous semantics, which isn’t the case yet IMHO.

Regards,
Albrecht

From: mmusic [mailto:[email-masked]] On Behalf Of Makaraju, Maridi Raju (Raju)
Sent: Freitag, 27. Februar 2015 14:30
To: Christer Holmberg; Roman Shpount
Cc: [email-masked]
Subject: Re: [MMUSIC] DTLS-O/A: DTLS fingerprint and setup role MUST NOT change unless underlying transport also changes

Is there are definition of ”(D)TLS rekey” somewhere?

I find text talking about “re-doing the handshake”, but doesn’t that include re-sending the Client/ServerHello messages, which basically means re-establishing the (D)TLS connection?
<Raju>
I am afraid that there is no straightforward answer to this as I do not see these terms formally defined anywhere, but used everywhere inconsistently!
I think, the term rekey, rehandshake and renegotiation all mean same thing: a new Client/Server Hello exchange within the context of current association [1] and protected by  existing cipher suite[3].
TLS 1.5 RFC[1] used the term renegotiation only. DTLS RFC [2] used rehandshake terminology only! DTLS-SRTP[3] used all three terms: rekey, rehandshake, renegotiation. I think the use of “rekey” in this context is just to make it explicit to get new keys for SRTP use, but it is still “renegotiation”.

In conclusion, I think it is preferred to use ‘renegotiation’ for this procedure.
[1] TLS1.5 https://tools.ietf.org/html/rfc5246#section-7.4.1 and other sections as well:
7.4.1<https://tools.ietf.org/html/rfc5246#section-7.4.1>.  Hello Messages
   The hello phase messages are used to exchange security enhancement
   capabilities between the client and server.  When a new session
   begins, the record layer's connection state encryption, hash, and
   compression algorithms are initialized to null.  The current
   connection state is used for renegotiation messages.

      …

      This message MAY be ignored by

      the client if it does not wish to renegotiate a session, or the

      client may, if it wishes, respond with a no_renegotiation alert.

[2] DTLS https://tools.ietf.org/html/rfc6347#section-4.2.4

   When the server desires a rehandshake, it transitions from the

   FINISHED state to the PREPARING state to transmit the HelloRequest.

   When the client receives a HelloRequest, it transitions from FINISHED

   to PREPARING to transmit the ClientHello.

[3] DTLS-SRTP https://tools.ietf.org/html/rfc5764#section-5.2
5.2<https://tools.ietf.org/html/rfc5764#section-5.2>.  Rehandshake and Rekey

   Rekeying in DTLS is accomplished by performing a new handshake over

   the existing DTLS channel. That is, the handshake messages are

   protected by the existing DTLS cipher suite.

7.3.2<https://tools.ietf.org/html/rfc5764#section-7.3.2>.  Renegotiation

   Because the rehandshake transition algorithm specified in Section 5.2<https://tools.ietf.org/html/rfc5764#section-5.2>

   requires trying multiple sets of keys if no MKI is used, it slightly

   weakens the authentication.

</Raju>

BR
Raju