[TLS] RFC5746: Renegotiation Indication for minimal servers

"Bauer Johannes (HOME/EFS)" <Johannes.Bauer@bosch.com> Tue, 02 August 2016 13:33 UTC

Return-Path: <Johannes.Bauer@bosch.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B2F7612D5CE for <tls@ietfa.amsl.com>; Tue, 2 Aug 2016 06:33:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.021
X-Spam-Status: No, score=-7.021 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bosch.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id I5tE7e-fpl01 for <tls@ietfa.amsl.com>; Tue, 2 Aug 2016 06:33:40 -0700 (PDT)
Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de []) (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 6E6D112D5CC for <tls@ietf.org>; Tue, 2 Aug 2016 06:33:39 -0700 (PDT)
Received: from vsmta14.fe.internet.bosch.com (unknown []) by imta24.fe.bosch.de (Postfix) with ESMTP id 3FDBAD80229 for <tls@ietf.org>; Tue, 2 Aug 2016 15:33:22 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bosch.com; s=2015-01-21; t=1470144802; bh=Kl4TF28wa8Ae9/gHaM+w9fdT2IhMDgamsR06G2C39sw=; l=10; h=From:From:Reply-To:Sender; b=R3ElfCt8/dXld0mdUd6lwCuVcmCHh3mDJilSXGkNsMd/OPLwjwp0qUM+b0fMaDfOw fTcrTZQ1XMrK0FnUDfQuk5FDZgpsYReeJq2GETiWSEvPW79PJpYtDlY3khxf16TJ9t Hb2cYCYADpFZArRN+lToaj3lsZI9e3ALzsU8/tFg=
Received: from FE-MBX1016.de.bosch.com (vsgw23.fe.internet.bosch.com []) by vsmta14.fe.internet.bosch.com (Postfix) with ESMTP id 1BD38A40576 for <tls@ietf.org>; Tue, 2 Aug 2016 15:33:22 +0200 (CEST)
Received: from FE-MBX1015.de.bosch.com ( by FE-MBX1016.de.bosch.com ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 2 Aug 2016 15:33:21 +0200
Received: from FE-MBX1015.de.bosch.com ([fe80::256d:ef59:31f1:323f]) by FE-MBX1015.de.bosch.com ([fe80::256d:ef59:31f1:323f%16]) with mapi id 15.00.1178.000; Tue, 2 Aug 2016 15:33:21 +0200
From: "Bauer Johannes (HOME/EFS)" <Johannes.Bauer@bosch.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: RFC5746: Renegotiation Indication for minimal servers
Thread-Index: AQHR7MJvU2wvbTQxuUivvvKs9ZJJXA==
Date: Tue, 02 Aug 2016 13:33:20 +0000
Message-ID: <9edc2222b4e141538875ff62ca3be22e@FE-MBX1015.de.bosch.com>
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: zSOzjnUdHGB2LjL8ejT/AJ1U1lojafr/0nXvwjW2mSWctWHPLT5FfQqQ QQLMh66nAA5BrDAHhD/M9MbRv5omQKXgCCul34T6AjoaSw0EjFWDwLTbOQjvDoYQveKV5AcTB2p vl8LQRyVM4l2ujUlu81axuiGAvQnCB7W827nnV41T46Ow+EhYOFaOJcCxVHYrbcPp/oilssgWud psiFoqJsudCfJw3Q6a4RAGgJ42zZ2H/p/IBt08LME+XuSw48kCgHzgwy8qV5oKogmGusPLbxchd rJv3xSnVvV8yYebEhk0ewX4BnmyOiZywmJvYiNp84dsinZ5e1gwLjM7t3iRo3hOa4C/aON5ilm8 Za1jcglnSqefas3A04EzNEDRLP/IuBnSxs/BFcImT1pl/auP23fdMkv/4CaG32tQZY6eq1ZC+gf JIXxlOJWdXCsle5PXYcJMBLTRh5xst+jJ0LNAM+DQCXqvSA0sBcCEAZkHsGczFWOYrWw6AwqEOa aKoFK30WJYm0gohzsnAKud+dx6ru51ZMzG9kZyevGgcXS9fnJLaooQW4IyHmOv0nGkb1c64rqQI +fw+pzi8zVgXoAltnS4vQrt84k3IAcCikR3vq8QCs2RtiVpRCELmpMB68Eq4y1ICPu2vPJnRx13 SnF3QgwZwCcpXYWC
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/586QFA6pI_JAReSIkYjyYdv5kiA>
Subject: [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 13:33:43 -0000

Dear mailing list,

regarding RFC5746 (https://tools.ietf.org/rfc/rfc5746.txt) I do have a question which could not be solved in our internal discussions. Therefore I would kindly ask for your comments on my issue. If I posted to the wrong place, please advise on where such a question would be relevant instead.

The question revolves around TLS servers (and clients) which do not support renegotiation at. The server side is the more interesting of the two, hence I will discuss it first. Sect 4.3 says:

   In order to enable clients to probe, even servers that do not support
   renegotiation MUST implement the minimal version of the extension
   described in this document for initial handshakes, thus signaling
   that they have been upgraded.

This hint refers to Sect. 3.6 ("Server Behavior: Initial Handshake"). It says that a server in any case (independent if it supports or does not support renegotiation at all) must send a empty renegotiation_info TLS extension as soon as it receives a client request for that info (be it either by a renegotiation_info or by the SCSV). Sending that empty renegotiation_info is really no problem even for deeply embedded TLS servers (the message is only 5 bytes and always static).

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.

This is something that, in my opinion, only applies to servers who do support renegotiation. Those which do not support renegotiation at all are exempt from that requirement. Note that it also is not a hard ("MUST") requirement, but merely informative ("needs"). At least that is my interpretation.

For deeply embedded systems, we try to save every byte of RAM -- therefore, we really would like minimal support for RFC5746 (i.e. signal that our server will never use insecure renegotation so the clients are satisfied). However, we would also not want to persist any session-relevant data in RAM (more so because it doesn't make sense to save them without renegotiation capability in the first place). However, we really like clarification if we're reading the RFC correctly in this instance.

If we're indeed reading the RFC correctly, could we maybe try to get an additional clarification in as an erratum to make this unambiguous?

Thank you very much for your time,

Johannes Bauer

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