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

Watson Ladd <watsonbladd@gmail.com> Tue, 02 August 2016 14:02 UTC

Return-Path: <watsonbladd@gmail.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 12A9412D66F for <tls@ietfa.amsl.com>; Tue, 2 Aug 2016 07:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 V8UNnKjkmcPA for <tls@ietfa.amsl.com>; Tue, 2 Aug 2016 07:02:56 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415DA12D665 for <tls@ietf.org>; Tue, 2 Aug 2016 07:02:56 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id s189so123128902vkh.1 for <tls@ietf.org>; Tue, 02 Aug 2016 07:02:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.31.128.80 with SMTP id b77mr21370165vkd.31.1470146575295; Tue, 02 Aug 2016 07:02:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.39.194 with HTTP; Tue, 2 Aug 2016 07:02:54 -0700 (PDT)
In-Reply-To: <9edc2222b4e141538875ff62ca3be22e@FE-MBX1015.de.bosch.com>
References: <9edc2222b4e141538875ff62ca3be22e@FE-MBX1015.de.bosch.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Tue, 2 Aug 2016 07:02:54 -0700
Message-ID: <CACsn0c=GN_f1UhoyzbRATgn_+C-0nK_aqx_MSaY2PnSuKeXcog@mail.gmail.com>
To: "Bauer Johannes (HOME/EFS)" <Johannes.Bauer@bosch.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pvyc9-E9v21Cfu7NTst6F4nA3sE>
Cc: "tls@ietf.org" <tls@ietf.org>
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:02:59 -0000

On Tue, Aug 2, 2016 at 6:33 AM, Bauer Johannes (HOME/EFS)
<Johannes.Bauer@bosch.com> wrote:
> 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.

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

Sincerely,
Watson Ladd