Re: [TLS] RFC 5878 - why?

Trevor Perrin <trevp@trevp.net> Tue, 17 September 2013 15:21 UTC

Return-Path: <trevp@trevp.net>
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 C8F0611E8474 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 08:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POJvcaa4V6Bf for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 08:21:22 -0700 (PDT)
Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id D315311E848B for <tls@ietf.org>; Tue, 17 Sep 2013 08:21:21 -0700 (PDT)
Received: by mail-we0-f182.google.com with SMTP id q59so5394410wes.27 for <tls@ietf.org>; Tue, 17 Sep 2013 08:21:21 -0700 (PDT)
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:date :message-id:subject:from:to:cc:content-type; bh=K2K/Rmh5If580SRewOxrfMdXaC0m0g+7wqG4GUU5Pbk=; b=PQBLdydHhkggaLpXiLd9bpnM1CJrcCFK7MTflXv0Bh7r9zqbJJziG+6Jd5yV/KP/HB U4KTNjSP8B38Gx1FIA8PafkIRT9tWT6i6KTuLlu2dCfRPOJV+QLNnVyrin/Dn/ydL6mV +UbEALT//TtB6AGfG/Vt1R00yzX6+4sBprj5/c9Ubvg7Ka0QMHDvuJIAVSW88WTR2YEC GWu/x8jGyZClfRvxj5RbFidULhQx7pgHaRliBwNdU0InQlgnMJ68GZpkQOyfztVUn1W2 QKs9FxFRjLKPndCKh1uh0ebf8K+XnqzeLZ5kHBGuUa440IE5t48FpVTbwR+sAcaOtcFC 7FRw==
X-Gm-Message-State: ALoCoQmjvljoDYfiLPG09ftKqW+ecr0bXJyhb6azT+5jmgXmL+IblqNlBiu5GE8KdMX7kKSRO28+
MIME-Version: 1.0
X-Received: by 10.180.160.203 with SMTP id xm11mr2955388wib.17.1379431280950; Tue, 17 Sep 2013 08:21:20 -0700 (PDT)
Received: by 10.216.61.13 with HTTP; Tue, 17 Sep 2013 08:21:20 -0700 (PDT)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <20130917130830.1EB191A974@ld9781.wdf.sap.corp>
References: <20130917130050.E26CF1A974@ld9781.wdf.sap.corp> <20130917130830.1EB191A974@ld9781.wdf.sap.corp>
Date: Tue, 17 Sep 2013 08:21:20 -0700
Message-ID: <CAGZ8ZG2NuA8V=ar_-bJr0miAuGahdxjVqH2R440qH1NbfFeg=w@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: mrex@sap.com
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 17 Sep 2013 15:21:27 -0000

On Tue, Sep 17, 2013 at 6:08 AM, Martin Rex <mrex@sap.com> wrote:
> Martin Rex wrote:
>> Marsh Ray wrote:
>> > > Trevor Perrin
>> > > Sent: Monday, September 16, 2013 9:16 PM
>> > > Subject: [TLS] RFC 5878 - why?
>> > >
>> > > Does anyone know of a reason to use RFC 5878?  Extension data can already
>> > > be sent in TLS handshakes:
>> >
>> > But probably the bigger reason is that some percentage of TLS servers
>> > in the wild will crash or (worse) hang when they receive a Client Hello
>> > with too much data. Nobody is really sure how much data is safe to send
>> > in the Client Hello, so getting preapproved with a small extension is
>> > safest.
>>
>> I hope that, rather than crashing, the most widespread behaviour among
>> servers will be to simply abort the handshake with a fatal Handshake
>> failure alert when the ClientHello handshake message exceeds some
>> reasonable size (maybe 16 KByte).  Ours does.
>
>
> Actually, another reason that comes to mind when looking at the
> handshake message flowchart here:
>
>   http://tools.ietf.org/html/rfc5878#page-4
>
> taking into account the last sentence before that chart:
>
>    Successful session resumption uses the same authorization information
>    as the original session.
>
> and compare it with the handshake message flowchart for the
> abbreviated TLS handshake (aka session resume):
>
>   http://tools.ietf.org/html/rfc2246#page-32
>
>
> For a potentially large TLS extension that carries fairly static data,
> you might not want to have to send it on every proposed TLS session resume.


Like I said to Marsh, see the flowchart in my first message.

It's trivial to exchange "authorization data" - or any sort of
extension data - in the ServerHello extension, and also in a 4680
SupplementalData message sent by the client after receiving
ServerHelloDone.

5878 is not needed to avoid sending large items in ClientHello.


Trevor