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

Joseph Salowey <joe@salowey.net> Fri, 23 January 2015 17:21 UTC

Return-Path: <joe@salowey.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029841A1B06 for <tls@ietfa.amsl.com>; Fri, 23 Jan 2015 09:21:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBQIHsLDOGEg for <tls@ietfa.amsl.com>; Fri, 23 Jan 2015 09:21:28 -0800 (PST)
Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569F51A8848 for <tls@ietf.org>; Fri, 23 Jan 2015 09:21:28 -0800 (PST)
Received: by mail-qa0-f47.google.com with SMTP id n8so6757807qaq.6 for <tls@ietf.org>; Fri, 23 Jan 2015 09:21:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2vEfmca4CSt+Nb16frifN173qh2OOCrfE3KXxFVELgs=; b=QH4gf3tefc1PDjtdLrNGO/dJVCiiQTk/ZzQAhzklaYnxaJ9xymf+whF5r7yGYTtgMs rYFbMiL4bziCbUXD4d7Wr56YNyi/2SpyZg6SknA0GOWh63UhbD3WQmTTfDDw+hNW/2yN s+SC6v7oCAwT8pVO2fBF9PYxFRPSYEcwcKvIdgS5RpOxb8ZowuL3HYGg545jhModkxgT VnkwLjwr6hUuLeg4Ub++x7k7gK4NfWgAr0f1WeuHdKzPIi8fgOPhYXNghysjvcC6O3Uf NQ9yF+GmKSAk2psQ74q+DVBDhoejwGUuFIv4oIUF5aSbbx+ifAqZG9EdnSInkc6afP39 86cQ==
X-Gm-Message-State: ALoCoQlRYG5M58GTiMKqbo8Hq4Wp6/ab3E83l6rGisHvAmU0H5DzlqpG+thyUnC8hqlnLTjr80Y1
MIME-Version: 1.0
X-Received: by 10.140.107.164 with SMTP id h33mr15699037qgf.71.1422033687567; Fri, 23 Jan 2015 09:21:27 -0800 (PST)
Received: by 10.96.238.73 with HTTP; Fri, 23 Jan 2015 09:21:27 -0800 (PST)
X-Originating-IP: [50.206.82.141]
In-Reply-To: <CACsn0cnLLQWM-Dm97BMmcMEzH4uZBdg=sry0Rx-WRqPy55FmiA@mail.gmail.com>
References: <9A7F583F-A1AB-4EC1-9F36-88E74C5EB9E1@ieca.com> <3D67EA40-B69C-4621-A377-489E3EE5DF5C@vpnc.org> <CACsn0cnLLQWM-Dm97BMmcMEzH4uZBdg=sry0Rx-WRqPy55FmiA@mail.gmail.com>
Date: Fri, 23 Jan 2015 09:21:27 -0800
Message-ID: <CAOgPGoD=kN2aPWXhM2xUKpEuozaqZ3cvRsMUhuWNBUebcpgy5A@mail.gmail.com>
From: Joseph Salowey <joe@salowey.net>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="001a113a6cfcce78a0050d5504a0"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ewTGdIeEQMMN35bI0pHb42P2MI0>
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [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 17:21:31 -0000

On Fri, Jan 23, 2015 at 9:13 AM, Watson Ladd <watsonbladd@gmail.com> wrote:

> 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?
>
>
[Joe] Good catch. It should say that associations are the same as TLS
connections.


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




> On Fri, Jan 23, 2015 at 8:30 AM, Paul Hoffman <paul.hoffman@vpnc.org>
> 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".
> 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
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > 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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>