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

Sean Turner <turners@ieca.com> Fri, 23 January 2015 16:10 UTC

Return-Path: <turners@ieca.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id B237C1A9170 for <tls@ietfa.amsl.com>; Fri, 23 Jan 2015 08:10:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.567
X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id oT530qvVLIBU for <tls@ietfa.amsl.com>; Fri, 23 Jan 2015 08:10:29 -0800 (PST)
Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08D41A924A for <tls@ietf.org>; Fri, 23 Jan 2015 08:10:20 -0800 (PST)
Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id E50AFAF372697; Fri, 23 Jan 2015 10:10:19 -0600 (CST)
Received: from gator3286.hostgator.com (gator3286.hostgator.com []) by gateway09.websitewelcome.com (Postfix) with ESMTP id C505EAF3725B4 for <tls@ietf.org>; Fri, 23 Jan 2015 10:10:19 -0600 (CST)
Received: from [] (port=60119 helo= by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from <turners@ieca.com>) id 1YEgoN-0004Wl-2Q; Fri, 23 Jan 2015 10:10:19 -0600
From: Sean Turner <turners@ieca.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 23 Jan 2015 11:10:16 -0500
To: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Message-Id: <9A7F583F-A1AB-4EC1-9F36-88E74C5EB9E1@ieca.com>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Exim-ID: 1YEgoN-0004Wl-2Q
X-Source-Sender: ( []:60119
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 2
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/reUr6mshgNauBlVfMgqqVqFLvIM>
Subject: [TLS] (draft final) ITU Q3/16 Liaison Response
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jan 2015 16:10:33 -0000


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.





[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).


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.


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


They are the same.


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


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.  

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


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.