Return-Path: 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 ; 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 ; 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 ; Fri, 23 Jan 2015 09:21:28 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id n8so6757807qaq.6 for ; 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: References: <9A7F583F-A1AB-4EC1-9F36-88E74C5EB9E1@ieca.com> <3D67EA40-B69C-4621-A377-489E3EE5DF5C@vpnc.org> Date: Fri, 23 Jan 2015 09:21:27 -0800 Message-ID: From: Joseph Salowey To: Watson Ladd Content-Type: multipart/alternative; boundary=001a113a6cfcce78a0050d5504a0 Archived-At: Cc: Paul Hoffman , "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 17:21:31 -0000 --001a113a6cfcce78a0050d5504a0 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 23, 2015 at 9:13 AM, Watson Ladd 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 > 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 > --001a113a6cfcce78a0050d5504a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 23, 2015 at 9:13 AM, Watson Ladd <watsonbladd@gmail.co= m> wrote:
I do not understand A2. There a= re 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 a= ssociations are the same as TLS connections. =C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> 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 s= hould just use the text in A4 as the response to both Q3 and Q4. =C2=A0

A3 and A4:

Resumption refers to the use of the state from an existing TL= S session to establish a new TLS connection using an abbreviated handshake.= =C2=A0 During resumption the cryptographic parameters (algorithms etc.) rem= ain the same.=C2=A0 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).=C2=A0 If the handshake is a full handshake then both a = new session and a new connection are established and the renegotiated sessi= on may have different parameters.

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

<= /div>

=C2=A0
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 "renegotiati= on 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: "Resum= ption 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=C2=A0 Liberty nor Safety."
-- Benjamin Franklin

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--001a113a6cfcce78a0050d5504a0--