Re: [TLS] Proposed text for removing renegotiation

Nikos Mavrogiannopoulos <nmav@redhat.com> Tue, 10 June 2014 08:20 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 238C71A02D9 for <tls@ietfa.amsl.com>; Tue, 10 Jun 2014 01:20:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Level:
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WNDFqBrJrSHq for <tls@ietfa.amsl.com>; Tue, 10 Jun 2014 01:20:04 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9498C1A0286 for <tls@ietf.org>; Tue, 10 Jun 2014 01:20:04 -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 s5A8K2F9000608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 10 Jun 2014 04:20:02 -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 s5A8JxL4026257 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2014 04:20:01 -0400
Message-ID: <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 10 Jun 2014 10:19:59 +0200
In-Reply-To: <CABkgnnX5+fXNDy1o7Pu60rp8vSx7XfKbt337e_q=+3fb8fXHJw@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> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <CABkgnnX5+fXNDy1o7Pu60rp8vSx7XfKbt337e_q=+3fb8fXHJw@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/XGErEm-SrEuQQONNaHQMmnQg6XY
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: Tue, 10 Jun 2014 08:20:06 -0000

On Mon, 2014-06-09 at 11:17 -0700, Martin Thomson wrote:
> On 9 June 2014 00:34, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
> > 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.
> 
> 
> I think that this has been covered in the thread, but piecemeal:

Not in my opinion. The arguments being presented are very vague, as the
ones you quote below.

> * Renegotiation is a major source of security issues, both of the "we
> screwed the TLS design up" sort and of the "my application didn't
> realize that these things could change" sort.  There is a clear desire
> to remove features that enable either sort of problem.

Could you please cite these security issues. In the 17 years of the
protocol I have only seen one.

> * Renegotiation is just more protocol complexity.  Removing it
> potentially makes implementations simpler.

Where do you base this conclusion? Have you implemented it and you found
it complex, or have you tried to model it in some formal model and was
impossible? Renegotiation, is one of the most simple parts of the
protocol (Martin Rex argued for that in a previous e-mail and I concur).
Your proposal to solve this "complexity" is more complex than the
current solution.

> I think that either might be sufficient justification for removing the feature.

Not to me. I believe that unless hard evidence of the problems are
presented, this call for action here is unwarranted.

regards,
Nikos