IETF Logo Mail Archive

Re: [TLS] Proposed text for removing renegotiation

"Salz, Rich" <rsalz@akamai.com> Fri, 13 June 2014 18:10 UTC

Return-Path: <rsalz@akamai.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 AC9F81B293F for <tls@ietfa.amsl.com>; Fri, 13 Jun 2014 11:10:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level:
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 ffAE2D007S88 for <tls@ietfa.amsl.com>; Fri, 13 Jun 2014 11:10:00 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 043881A01E7 for <tls@ietf.org>; Fri, 13 Jun 2014 11:10:00 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BE003165694; Fri, 13 Jun 2014 18:09:58 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id B309C165690; Fri, 13 Jun 2014 18:09:58 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 8608C1E045; Fri, 13 Jun 2014 18:09:58 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Fri, 13 Jun 2014 14:09:58 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Steve Checkoway <s@pahtak.org>, "tls@ietf.org" <tls@ietf.org>
Date: Fri, 13 Jun 2014 14:09:57 -0400
Thread-Topic: [TLS] Proposed text for removing renegotiation
Thread-Index: Ac+HLyHgIZBWn4+uTBi1EEggjKJnXgAAnjaw
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7181DE20AFB@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> <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> <CACgsDcCmyOVqyeBruoj3hKS_5YNT+PM6_x=KWhpceAJAi513Rw@mail.gmail.com>
In-Reply-To: <CACgsDcCmyOVqyeBruoj3hKS_5YNT+PM6_x=KWhpceAJAi513Rw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7181DE20AFBUSMBX1msgcorp_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WyBbck537CQ0LqDjbBX4R0Lye5c
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 18:10:01 -0000

Ø  Where do you see a TOCTTOU violation?

I don’t think it’s guaranteed that there’s a violation, but it is very hard to get this right. Compared to, say, filesystem operations on a local operating system, things are sequential and atomic; a process can’t do setuid() while open() is checking to see if the process has the required permission. And also the kernel ALWAYS knows the identity of the program. This is different from network/web applications, which are often not expecting identity checks, and where the “framework runtime” is doing things while the business logic is processing a request, often in the name of speedXXXXX better user experience.

                /r$

--
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rsalz@jabber.me<mailto:rsalz@jabber.me>; Twitter: RichSalz

v2.26.15 | Report a Bug | By Email | System Status