Re: [TLS] Proposed text for removing renegotiation

Nikos Mavrogiannopoulos <nmav@redhat.com> Tue, 10 June 2014 16:04 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 8CD131A01CE for <tls@ietfa.amsl.com>; Tue, 10 Jun 2014 09:04:23 -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 6uancVF1pZ0W for <tls@ietfa.amsl.com>; Tue, 10 Jun 2014 09:04:22 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 34CA81A01A7 for <tls@ietf.org>; Tue, 10 Jun 2014 09:04:22 -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 s5AG4Lft021866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 10 Jun 2014 12:04:21 -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 s5AG4JR4000473 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2014 12:04:20 -0400
Message-ID: <1402416258.11505.7.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: "Salz, Rich" <rsalz@akamai.com>
Date: Tue, 10 Jun 2014 18:04:18 +0200
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130F43560C@USMBX1.msg.corp.akamai.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> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130F43560C@USMBX1.msg.corp.akamai.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/mw-5ZSyyGuGsMNouRLRZx-73CgQ
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 16:04:23 -0000

On Tue, 2014-06-10 at 10:53 -0400, Salz, Rich wrote:
> > Could you please cite these security issues. In the 17 years of the protocol I have only seen one.
> 
> Which one are you omitting -- Marsh's  or triple-handshake?

The triple handshake identified many issues in TLS but no issue in the
renegotiation. Renegotiation cannot solve the protocol's vulnerability
the triple handshake exploits.

Nevertheless, you can see the importance of renegotiation in the triple
handshake attack  by checking the preconditions for the attack. The
authors on their website clarify on the vulnerabilities they identified
and quoting them for renegotiation: "During renegotiation, both the
server and client certificates can change. This is allowed by TLS (and
supported in its main implementations) but no definitive guidance is
given to applications on how to deal with such changes".

Mentioning the lack of application level guidance (for applications that
need and make use of it) as a reason to drop renegotiation, is a bit far
fetched.

regards,
Nikos