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

Watson Ladd <> Tue, 02 August 2016 14:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12A9412D66F for <>; Tue, 2 Aug 2016 07:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V8UNnKjkmcPA for <>; Tue, 2 Aug 2016 07:02:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 415DA12D665 for <>; Tue, 2 Aug 2016 07:02:56 -0700 (PDT)
Received: by with SMTP id s189so123128902vkh.1 for <>; Tue, 02 Aug 2016 07:02:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kxGHFgedChIbkH+Hs+GG+Zw6X1XSCe+rQnLUqBNGjFU=; b=bSq7vjBWDU/aNvY2M9Vv6IV3+vBQJrwoLtJjlDtEglqy3KTlB23XqWXfyheRVKwGnB y3f+l1FQeihFken+6KZROz2/WvAkJ4IlVeRC9y5J8Ni8MI/PPxpNh66uLieNIt5xfQlZ XJ10CkBprFN7BYbBuooKSo8McdWhMxX62W97P9w41AfQxWzyST1cUb3GNUK8fPhyyhlY 60Yr+qlAqMTII1ONUEMlVzDCMLVasf3HICSOIPnCMVroceP43dKopGi93jpK+/EdMp3f 2iGcieWCzY4Q5LoFtLd1qyKo6k7fKoqF3JoOZsx1B+wwQ4vRTMqyc5ncCyHOwR+SQJ2E CGFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kxGHFgedChIbkH+Hs+GG+Zw6X1XSCe+rQnLUqBNGjFU=; b=MCz6j5Ligmj+uVwdiiyOhdK0y1r+ICprxUoWxBhhyVm1xXTyb5na7v2h/mUYvgmL7r dFUvTJsiH82P3TGwvEObA81ojvccMqgRCIG9BM1VNt3PQw/v5jXpidFuBWDw69JEJo56 GTDml2wCqEQzygTmnKnY/D8+KcqE4/w01f1rqJE2Kk1ApA1w6gug6HujGjEwbyFXte5D Xt8R2z9Mhk0v6avURlVIEyuZLHsOS3vy5vhqVC0qm0bf0fg4V8vOKTUFh1BltgKlovrA TCBjKtZL4Z1lnJqWs386a608UdmxL4+AFsgSoG2e5IujiAuDusMGr8iub5b7YyShWzb2 dDXA==
X-Gm-Message-State: AEkoousCQ8vEBrOWrdH5rEXFMrc9WTNyv4HtVPsum8gdfugf0t38ZN6blAGlwEizj05E9hkmf+6aCrbyTIMPnw==
X-Received: by with SMTP id b77mr21370165vkd.31.1470146575295; Tue, 02 Aug 2016 07:02:55 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 2 Aug 2016 07:02:54 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Watson Ladd <>
Date: Tue, 2 Aug 2016 07:02:54 -0700
Message-ID: <>
To: "Bauer Johannes (HOME/EFS)" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
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:02:59 -0000

On Tue, Aug 2, 2016 at 6:33 AM, Bauer Johannes (HOME/EFS)
<> wrote:
> Dear mailing list,
> regarding RFC5746 ( 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.

Yes, and since it doesn't read them out, it should use write only
memory as an optimization.

Watson Ladd