Re: [TLS] Proposed text for removing renegotiation

Steve Checkoway <s@pahtak.org> Fri, 13 June 2014 17:44 UTC

Return-Path: <s@pahtak.org>
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 D11F81B2992 for <tls@ietfa.amsl.com>; Fri, 13 Jun 2014 10:44:16 -0700 (PDT)
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 oNwMZ69URYW5 for <tls@ietfa.amsl.com>; Fri, 13 Jun 2014 10:44:14 -0700 (PDT)
Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11BCF1B2957 for <tls@ietf.org>; Fri, 13 Jun 2014 10:44:13 -0700 (PDT)
Received: by mail-vc0-f180.google.com with SMTP id im17so2552148vcb.25 for <tls@ietf.org>; Fri, 13 Jun 2014 10:44:12 -0700 (PDT)
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:content-type; bh=SyLIRMgRlXvBrur1soOasQrEMnXl3S1Zejqe5cvlcyU=; b=NJUFI3uqGBD5BMy3phHmNTZ7FJeKhbM2lmVfl4/4F9c8yU3OdAyE9qnWPrwLVggMbg w5M0TsFnu3S0DecYPyjVlQflhFWPIw0haIZVFF2/0AwnSYmXsMO2eYpz1vCAY4GVQY59 EB4CB8NF4IPAxDtCt8MoxZ4OPnKG2PVkYtSRl1YEqHl4NposeKfD5MIR6OIPIwShuP1O bDpi1Qa0b7zyADkGfpwo6b2xEq4tBTdhEcJj9HmnxfoWTZ2vs2NY9augXpTY3Q1H+sfz POTxZDDYfLjD7FVZs72jn+bWlVgJfP+g3Hxvc5bSG+gh/Bz2rgcrA1oZsziJ44nOIfKn gKKg==
X-Gm-Message-State: ALoCoQl/D6h75XIhjYw1m2YVSE7ByUSY6MlTmMsdwmN1XxOdoRDEEie+7JZjCA+Iu59gCV6Hr0b3
MIME-Version: 1.0
X-Received: by 10.58.210.68 with SMTP id ms4mr2729034vec.6.1402681451952; Fri, 13 Jun 2014 10:44:11 -0700 (PDT)
Received: by 10.52.249.79 with HTTP; Fri, 13 Jun 2014 10:44:11 -0700 (PDT)
X-Originating-IP: [132.162.120.50]
In-Reply-To: <CACsn0ck6OxPm8BwuNeAn+wpayaefkAzZtiyjkaQ1sB_4hp0C_Q@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> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <CACsn0cmM4KpMgwXo0iTygsQ+En6N3J46jPY-Q3hfwzqG431M1w@mail.gmail.com> <1402648977.6191.36.camel@dhcp-2-127.brq.redhat.com> <CACsn0ck6OxPm8BwuNeAn+wpayaefkAzZtiyjkaQ1sB_4hp0C_Q@mail.gmail.com>
Date: Fri, 13 Jun 2014 13:44:11 -0400
Message-ID: <CACgsDcCmyOVqyeBruoj3hKS_5YNT+PM6_x=KWhpceAJAi513Rw@mail.gmail.com>
From: Steve Checkoway <s@pahtak.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=047d7bd6ad42ad54e204fbbb39d8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/t2t4aOPVtjvIGMftHFtZnraO2nE
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: Fri, 13 Jun 2014 17:44:17 -0000

On Fri, Jun 13, 2014 at 7:34 AM, Watson Ladd <watsonbladd@gmail.com> wrote:


> The issue is the following: most applications do something like this
> parse_request(conn)
> check_if_request_authorized(conn)
>
> This assumes that the authentication state doesn't change in between
> the two lines, or midway through the parse.
> With renegotiation it can.


Although I'm leaning toward removing renegotiation (and potentially adding
rekeying or authentication), I'm not sure your example demonstrates an
issue. Regardless of the authentication state during parse_request, the
relevant issue is is the other side authorized at the point of the
check_if_request_authorized.

Where do you see a TOCTTOU violation?

 --
Steve Checkoway