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

"Bauer Johannes (HOME/EFS)" <> Tue, 02 August 2016 14:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1B1F12D75F for <>; Tue, 2 Aug 2016 07:33:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DGkBIqHJikhc for <>; Tue, 2 Aug 2016 07:33:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B481712D62C for <>; Tue, 2 Aug 2016 07:33:10 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 396CED80212 for <>; Tue, 2 Aug 2016 16:32:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=2015-01-21; t=1470148372; bh=nDZnItBVtxKd+iNers7baYZGvLoLOZUcvlPkWcju4/I=; l=10; h=From:From:Reply-To:Sender; b=rBB9sLfRypfOMpt5mIy4ZmlTOUpEyNqKLvrHeCoNnkZcaPAcwJl/BDRWszK9w+5/U Y8mDHS5WR7pmKyCiI70qVhBxtC9g8g5uzWfqniJqiHq5B+eo2Sjb1gxRAUQRfltspS LWP3smkTtIShA4nT0mkA6eEw0SaRbs5s/n2AoxFU=
Received: from ( []) by (Postfix) with ESMTP id 1B1F71B80249 for <>; Tue, 2 Aug 2016 16:32:52 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 2 Aug 2016 16:32:51 +0200
Received: from ([fe80::256d:ef59:31f1:323f]) by ([fe80::256d:ef59:31f1:323f%16]) with mapi id 15.00.1178.000; Tue, 2 Aug 2016 16:32:51 +0200
From: "Bauer Johannes (HOME/EFS)" <>
To: "" <>
Thread-Topic: [TLS] RFC5746: Renegotiation Indication for minimal servers
Thread-Index: AQHR7MJvU2wvbTQxuUivvvKs9ZJJXKA1khQAgAAp0U4=
Date: Tue, 2 Aug 2016 14:32:51 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: de-DE
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TMASE-MatchedRID: u7Yf2n7Ca/0OwH4pD14DsPHkpkyUphL9NRv92EahEcGae6AcsiK/zS67 0e2gJiRY/OqQkvG7OOLDCwrx7OfXzR77VnTa7axqnW/laudJFeHuHZGuwo6K7cWkDW4kV3WaVhb DEH23DRPAwRlxCkpvJc/TS0hmvgWiirAuOoI0LM9/TWpwlAOFXilayzmQ9QV0iJR9DUWlpdWsDv qgCInmxur3/Mxc2X121ErQgs4x3dQkbusa5WEazm/CU2X9JBM7MUUuEZQPwBZQ3OD8q9D1sNanw ebW+WZ+a0m6sXM91wvYBuOPSxM8lywVHyAZiiCXXTIj5rfOJxUzKi5mdHI8OJsoi2XrUn/JUXy2 kgFQ7coqtq5d3cxkNUJ3Dv3/4w3bXeNO/ufOMQDA2Y+Ets8zRBfgCUkfIo4rBBLu/70QB7DAvpL E+mvX8g==
Archived-At: <>
Subject: Re: [TLS] RFC5746: Renegotiation Indication for minimal servers
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Aug 2016 14:33:16 -0000

Hi Watson,

On Tue, Aug 2, 2016 at 16:02, Watson Ladd wrote:
>> However, there is also this in Sect. 3.6 which has caused some confusion and lengthy discussion among my colleagues and myself:
>>    o  When the handshake has completed, the server needs to save the
>>       client_verify_data and server_verify_data values for future use.
>Yes, and since it doesn't read them out, it should use write only
>memory as an optimization.

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 :-)


Johannes Bauer

Engineering Field Services (HOME/EFS)
Robert Bosch Smart Home GmbH | Schockenriedstr. 17 | 70565 Stuttgart-Vaihingen | GERMANY |
Tel. +49(711)81112906 |
Registergericht: Amtsgericht Stuttgart, HRB 754585;
Geschäftsführung: Dr. Peter Schnaebele, Veronika Danner