Re: [TLS] Proposed text for removing renegotiation

Nikos Mavrogiannopoulos <nmav@redhat.com> Mon, 09 June 2014 07:34 UTC

Return-Path: <nmav@redhat.com>
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 90D4D1A0005 for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 00:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.654
X-Spam-Level:
X-Spam-Status: No, score=-5.654 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 yikFm1lDlenC for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 00:34:23 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3F41A0002 for <tls@ietf.org>; Mon, 9 Jun 2014 00:34:23 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s597YM7p026697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 9 Jun 2014 03:34:22 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s597YKIu024401 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 03:34:22 -0400
Message-ID: <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 09 Jun 2014 09:34:20 +0200
In-Reply-To: <CABcZeBPe45BM-uXd7DEBD_BBn=jhk8KkYB=facp+NMb2e4nBiw@mail.gmail.com>
References: <CAFewVt65X1V6=A_HP_pcg=6nXNVFLxQmSsPB2rq1KvmGPRz+og@mail.gmail.com> <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <CACsn0cmcc6kXvOuqkZaDj7+QPdpY9qqQ58bs3s-JBGXdNJSZyw@mail.gmail.com> <CABcZeBPe45BM-uXd7DEBD_BBn=jhk8KkYB=facp+NMb2e4nBiw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ki92ZgEMsGQCpNihAK44VtrOj2A
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Proposed text for removing renegotiation
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: Mon, 09 Jun 2014 07:34:24 -0000

On Sat, 2014-06-07 at 08:41 -0700, Eric Rescorla wrote:

> 
> separate "TLS Record Protocol" (Section 6) and "TLS Handshaking
> Protocols" (Section 7) with the handshake protocol establishing a
> Master Secret for the entire session which is then used to derive
> distinct record keys every time you reconnect (resume) in the same
> session, with diversity provided by the random values. So, arguably,
> TLS already behaves this way, with the exception of dealing with
> cryptographic exhaustion of the transport keys (e.g., GCM counter
> rollover).
> MT's basic suggestion is to fix the cryptographic exhaustion

Could somebody elaborate on what is that issue and why does it need to
be solved? (it is not even mentioned in the TLS 1.3 charter) As someone
who follows the mailing list that proposal comes out of the blue with no
context whatsoever.

regards,
Nikos