Re: [TLS] Proposed text for removing renegotiation

Nikos Mavrogiannopoulos <nmav@redhat.com> Wed, 11 June 2014 08:45 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 3CAF81B2830 for <tls@ietfa.amsl.com>; Wed, 11 Jun 2014 01:45:10 -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 oOFCMViZLQLM for <tls@ietfa.amsl.com>; Wed, 11 Jun 2014 01:45:08 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2703A1A037C for <tls@ietf.org>; Wed, 11 Jun 2014 01:45:08 -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 s5B8j6Vs032691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Jun 2014 04:45:06 -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 s5B8j4aM012486 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2014 04:45:05 -0400
Message-ID: <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Watson Ladd <watsonbladd@gmail.com>
Date: Wed, 11 Jun 2014 10:45:04 +0200
In-Reply-To: <CACsn0cm5OzzjOh5nSXcu-cx+ZYFeJiJ5eGvgwjsWPUeX4ozz2g@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> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <CACsn0cm5OzzjOh5nSXcu-cx+ZYFeJiJ5eGvgwjsWPUeX4ozz2g@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/0QtLzljRqJtX6AgYO5nkLzMyBJ8
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: Wed, 11 Jun 2014 08:45:10 -0000

On Tue, 2014-06-10 at 14:04 -0300, Watson Ladd wrote:

> Quick: what is the proper response when the Certificate changes
> between a negotiation and a renegotiation?

That is on the application protocol to decide.

> What is the relation between the two connections? Can there ever be
> sensible semantics for this?
> Renegotiation makes reads block on writes, a problem for all
> event-based systems. Exposing renegotiation to application level code
> is hard.

It has been done already, and not only once. Could you provide evidence
of this hardness that you claim?

> Show me a formalization of renegotiation semantics, and I might be
> convinced otherwise. 

I think it is up to the one proposing the change to provide evidence of
the contrary and there has been none so far. Otherwise we do things like
prove me TLS secure  combination or we drop it completely. Formal models
lag behind protocols.

> But to say that it is
> "not complex" belies the experience of implementors, theorists, and
> the past 17 years of security

It's good to know that you are representing them. Could you share your
experience with implementing or modeling TLS? Or at least cite some
document that backs up the claims that you make.

regards,
Nikos