IETF Logo Mail Archive

Re: [TLS] RFC5746: Renegotiation Indication for minimal servers

Benjamin Kaduk <bkaduk@akamai.com> Tue, 02 August 2016 14:57 UTC

Return-Path: <bkaduk@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719F112D787 for <tls@ietfa.amsl.com>; Tue, 2 Aug 2016 07:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.987
X-Spam-Level:
X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
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 be6nA0OaI4rI for <tls@ietfa.amsl.com>; Tue, 2 Aug 2016 07:57:23 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7921B12D67D for <tls@ietf.org>; Tue, 2 Aug 2016 07:57:23 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3CF70433421; Tue, 2 Aug 2016 14:57:22 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 2709343341C; Tue, 2 Aug 2016 14:57:22 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1470149842; bh=fZ0FJWh1Y+SAK7F9rPStV22EGfJdSfPjT7xMsG373Ik=; l=2563; h=To:References:From:Date:In-Reply-To:From; b=hRQCDIHB8AThFjoPR5ouo3J6Q3J843TMvPVhccfPypner8sUpaQn5VHXdc5kjVl8b 7KeQMF0yqGkHOrdTLxuBj9qG0Feh1q/jFVRUAORisy2MBtXy8MA5JN2ZM0AJEHRn+M 6zGDaX80H06U4LeWYKYTEAZLqTOpnNOZKn6NsFds=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id F20441FC86; Tue, 2 Aug 2016 14:57:21 +0000 (GMT)
To: "Bauer Johannes (HOME/EFS)" <Johannes.Bauer@bosch.com>, "tls@ietf.org" <tls@ietf.org>
References: <9edc2222b4e141538875ff62ca3be22e@FE-MBX1015.de.bosch.com> <CACsn0c=GN_f1UhoyzbRATgn_+C-0nK_aqx_MSaY2PnSuKeXcog@mail.gmail.com> <1470148363699.24362@bosch.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <4ff68fa1-0d8e-ed1e-064c-8bb5bbf5935a@akamai.com>
Date: Tue, 02 Aug 2016 09:57:21 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <1470148363699.24362@bosch.com>
Content-Type: multipart/alternative; boundary="------------0CFAC254830D4D1F59D0B388"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Tr4mw4-ANE8Yr5kN1B-9ev8Bc80>
Subject: Re: [TLS] RFC5746: Renegotiation Indication for minimal servers
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 02 Aug 2016 14:57:25 -0000

On 08/02/2016 09:32 AM, Bauer Johannes (HOME/EFS) wrote:
>
> So I take it my interpretation is correct -- these values are only ever required for renegotiation and serve no other purpose? I.e. the hint can safely be ignored in this case and the implementation will still be fully RFC5746-compliant?
>
> All joking aside, this has seriously led to some discussions where implementation of said RFC was rejected because of the overhead it might cause. And even among some people who write SSL stacks for a living.
>
> So while, if the RFC is read correctly (it's "need", not "MUST"), this is obvious, it really is confusing in practice. Since wide adoption of this RFC is of interest to everyone, I think an official clarification might help tremendously. Even if it's really obvious for people who design TLS :-)
>

The next step is for someone to write proposed text that would be more
clear.  Maybe you have thoughts about how things could change?

-Ben

v2.23.0 | Report a Bug | By Email