IETF Logo Mail Archive

Re: [TLS] Proposed text for removing renegotiation

"Kemp, David P." <DPKemp@missi.ncsc.mil> Wed, 11 June 2014 16:08 UTC

Return-Path: <DPKemp@missi.ncsc.mil>
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 F1A801A01E7 for <tls@ietfa.amsl.com>; Wed, 11 Jun 2014 09:08:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level:
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 rfMR9l5bOX7d for <tls@ietfa.amsl.com>; Wed, 11 Jun 2014 09:08:02 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862ED1A01A5 for <tls@ietf.org>; Wed, 11 Jun 2014 09:08:02 -0700 (PDT)
Received: from Odysseus.missi.ncsc.mil (odysseus.missi.ncsc.mil [144.51.60.172]) by stingray.missi.ncsc.mil with ESMTP id s5BG81PZ043738 for <tls@ietf.org>; Wed, 11 Jun 2014 12:08:01 -0400 (EDT)
Received: from PINTO.missi.ncsc.mil ([fe80::60c7:cec6:b35c:deed]) by Odysseus.missi.ncsc.mil ([fe80::a8ee:8532:895b:b420%14]) with mapi id 14.03.0181.006; Wed, 11 Jun 2014 12:08:01 -0400
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Proposed text for removing renegotiation
Thread-Index: AQHPhVGEfA6PTH75QESiVYAkFY18F5tsDc0A///9z+A=
Date: Wed, 11 Jun 2014 16:08:00 +0000
Message-ID: <5B1D7E570380A64989D4C069F7D14BC8CB7F66D6@PINTO.missi.ncsc.mil>
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>
In-Reply-To: <CACsn0cmM4KpMgwXo0iTygsQ+En6N3J46jPY-Q3hfwzqG431M1w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [144.51.60.29]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8cnds29ac99FcgT26rxxAOw234E
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 16:08:10 -0000

A decision on the proper place to do access control has nothing to do with the skill of implementers.

If a web server (or any service provider) doesn't know how to grant access to resources based on authenticated user identity, user attributes, resource attributes and access policy, then a perfect bug-free network stack is not going to help them.

If a "certificate changes", then either the application should have requested renegotiation synchronously or it should have asynchronously established conditions for when the stack renegotiates and registered to be notified when it happens.  The proper response to renegotiation is identical to the proper response to negotiating the first time.

"We know more than the application layer people" - pure hubris.  TLS/IPSEC practitioners should definitely know more about cryptography, which application developers should be able to largely ignore as a black box.  But access control to application resources is inherently an application function for which TLS library coding expertise is no substitute.


-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Watson Ladd
Sent: Wednesday, June 11, 2014 7:46 AM
To: Nikos Mavrogiannopoulos
Cc: tls@ietf.org
Subject: Re: [TLS] Proposed text for removing renegotiation

On Wed, Jun 11, 2014 at 5:45 AM, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
> 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.

Always the wrong answer: we know more then the application layer people do about security, just as the networking people know more than we do about sending packets through the network.

v2.23.0 | Report a Bug | By Email