Subject: [TLS] (draft final) ITU Q3/16 Liaison Response

From: Sean Turner <[email-masked]>
Date: Fri, 23 Jan 2015 11:10:16 -0500

All,

We received a liaison from ITU-T Q3/16 that contain some questions that we need to reply to.  Joe and I have drafted a response but would like to know if you have any comments on the following before 2015-01-30.  On the 30th, we’ll craft some appropriate liaison language as boiler plate and ship it back to the ITU.

Q1-Q4 are their questions and A1-A4 are our responses.

Cheers,

spt

----------------

Q1.

[What is] the distinction between (D)TLS session and (D)TLS connection (which implies a definition for each term, beyond the available descriptions / glossary from RFC side).

A1.

A TLS session is shared cryptographic state established by a full TLS handshake between two peers.  The session’s cryptographic state is used to establish the cryptographic key material for a TLS connection.  A TLS connection is a transport relationship established between two peers that contains the cryptographic state to cryptographically protect data sent and received on the connection established through a full or abbreviated (session resumption) TLS handshake.  A TLS session may span one or more TLS connections.  Every TLS connection is associated with one TLS session.  If session resumption (abbreviated handshake) is not used then the TLS session and TLS connection will essentially be the same.  A TLS session is identified by a Session ID in the client and server hellos.  A TLS connection is usually identified by a host addresses and port numbers.

Q2.

The DTLS association concept, e.g., is it equivalent to a DTLS session or DTLS connection or something in addition?

A2.

They are the same.

Q3.

The TLS renegotiation procedure: what is the definition and at which level (TLS session or TLS connection level) does this procedure occur?

A3.

The TLS renegotiation procedure establishes new cryptographic state for the TLS connection.  It may also establish a new TLS session if the renegotiation uses the full TLS handshake.  
 
Please note that renegotiation is an optional feature for pre-TLS 1.3 clients and servers.

Please also note that renegotiation is being dropped in TLS 1.3.  Clients and servers will use a different mechanism to update the cryptographic state.  
 
Q4.

The TLS resumption procedure: what is the definition and relation to TLS renegotiation?

A4.

Resumption refers to the use of the state from an existing TLS session to establish a new TLS connection using an abbreviated handshake.  During resumption the cryptographic parameters (algorithms etc.) remain the same.  TLS renegotiation is the process of executing a new TLS handshake to establish new cryptographic parameters for a TLS connection (effectively a new TLS connection using the same host addresses and ports as the previous one).  If the handshake is a full handshake then both a new session and a new connection are established and the renegotiated session may have different parameters.  
 
Please note that session resumption is an optional feature.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 23 Jan 2015 08:30:38 -0800

These look good. However, it may be premature to say "renegotiation is being dropped in TLS 1.3" since we are far from finishing TLS 1.3. Maybe change this to "renegotiation is likely to be dropped in TLS 1.3". Similarly, it might be good to add at the end of A4: "Resumption is very likely to be changed in TLS 1.3, which is work in progress at this time".

--Paul Hoffman

---

From: Watson Ladd <[email-masked]>
Date: Fri, 23 Jan 2015 09:13:35 -0800

I do not understand A2. There are three possible antecedents for they,
and it is not clear which two are the same. Is a DTLS association a
DTLS connection, or is it a DTLS session? Or are DTLS sessions and
associations the same?

A3 needs to be substantially fleshed out: given that sessions are
cryptographic states, doesn't every renegotiation involve a new
session? (I understood the intended answer is that the same connection
changes which session it is a part of, but that session may not be new
as it may be resumed.) A4 does better at this.

On Fri, Jan 23, 2015 at 8:30 AM, Paul Hoffman <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 23 Jan 2015 09:21:27 -0800

> DTLS connection, or is it a DTLS session? Or are DTLS sessions and
[Joe] Good catch. It should say that associations are the same as TLS
connections.

> as it may be resumed.) A4 does better at this.
[Joe] Maybe we should just use the text in A4 as the response to both Q3
and Q4.

A3 and A4:

Resumption refers to the use of the state from an existing TLS session to
establish a new TLS connection using an abbreviated handshake.  During
resumption the cryptographic parameters (algorithms etc.) remain the same.
TLS renegotiation is the process of executing a new TLS handshake to
establish new cryptographic parameters for a TLS connection (effectively a
new TLS connection using the same host addresses and ports as the previous
one).  If the handshake is a full handshake then both a new session and a
new connection are established and the renegotiated session may have
different parameters.

Please note that session resumption and renegotiation are optional
features.  Session resumption is very likely to be changed in TLS 1.3,
which is work in progress at this time

> > These look good. However, it may be premature to say "renegotiation is
> being dropped in TLS 1.3" since we are far from finishing TLS 1.3. Maybe
> change this to "renegotiation is likely to be dropped in TLS 1.3".
> Similarly, it might be good to add at the end of A4: "Resumption is very
> likely to be changed in TLS 1.3, which is work in progress at this time".
> >
> > --Paul Hoffman
> >

---

From: Sean Turner <[email-masked]>
Date: Fri, 23 Jan 2015 13:27:01 -0500

> These look good. However, it may be premature to say "renegotiation is being dropped in TLS 1.3" since we are far from finishing TLS 1.3. Maybe change this to "renegotiation is likely to be dropped…

Yeah that’s a good point, we’re not done with TLS1.3 so we shouldn’t presuppose how it’s going to turn out.

spt

---

From: [email-masked] (Martin Rex)
Date: Fri, 23 Jan 2015 20:50:15 +0100 (CET)

Sean Turner wrote:
> Paul Hoffman <[email-masked]> wrote:
>> 
>> These look good. However, it may be premature to say
>>    "renegotiation is being dropped in TLS 1.3"
>> since we are far from finishing TLS 1.3. Maybe change this to
>>     "renegotiation is likely to be dropped in TLS 1.3".
> 
> Yeah that's a good point, we're not done with TLS1.3 so we
> shouldn't presuppose how it's going to turn out.

You probably should also take into account that TLSv1.2 (rfc5246)
"highly recommends" supporting TLS renegotiation:

https://tools.ietf.org/html/rfc5246#appendix-D.4

   D.4.  Implementation Pitfalls

     [...]

   -  Do you support renegotiation, both client and server initiated?
      While renegotiation is an optional feature, supporting it is
      highly recommended.

While you can get away with (and are better off) with _not_ supporting
renegotiation on the server side, you may encounter frequent interop problems
when you do not implement it on the client side -- because it is used
by a lot of servers (at least in TLS).

Some TLS clients even have serious difficulties dealing properly
with a CertificateRequest handshake message in the initial handshake,
because there seem to be more sites requesting client certificates
through renegotiation than in the initial handshake.

-Martin