Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

Nick Sullivan <nicholas.sullivan@gmail.com> Tue, 11 October 2016 17:26 UTC

Return-Path: <nicholas.sullivan@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 2B07F129557 for <tls@ietfa.amsl.com>; Tue, 11 Oct 2016 10:26:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 t4gDIhF0Z7dN for <tls@ietfa.amsl.com>; Tue, 11 Oct 2016 10:26:14 -0700 (PDT)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 61D3E12952B for <TLS@ietf.org>; Tue, 11 Oct 2016 10:26:14 -0700 (PDT)
Received: by mail-io0-x230.google.com with SMTP id j37so32318741ioo.3 for <TLS@ietf.org>; Tue, 11 Oct 2016 10:26:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1A7D4AyPrXOzF4AlzfBzqekmd+yl8buFxJW0WdXQhww=; b=Sa2CKZKvGi2Lybt++sMQte//+VoSiuO96Zuw/t7JPMygL+Cluum8BsoSUnRMya5Un8 XZ8IEIeHgr7n3zs722EyG3U6nAQ5xKnq1KUK6drQJJ1h+AFKLHgEQOZhfH8x5rHAbTur 5VtEQfscpIHMIgIe5cL5/9GpB9JuxPnJj2LqG2r7pq7t8/SKiLruYuqoYincN3qXlVR0 aUHwI4+XtHinkGC5fmWgLo+cUyOUTU1cm+kqOrjaMx+Adn2VnrL6DzPYDrjrAF6DDYMC L5N36OLPzG4DYAPf6vqcL45JzBfkDS5ed4qqVEIixuRntBjC+l1JnBSpwMsIhhhmjxE/ SOXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=1A7D4AyPrXOzF4AlzfBzqekmd+yl8buFxJW0WdXQhww=; b=I8mKPmss9c1SE4iiM/GzioUuT/78OYsKSQnEC7e9RwA4EBvRAY8TPSQ+j+ZAG6kZDq acpZgkUJ3+duQI9bPIwLaEKnYr+qmQTZzKWFbA3aAODxwd/GhiR/i+mmigbKaqBu+rcz SL0ImUk7sXDX0Bz8MuBtev2NVudup/oLW+a67rVLkP2HQxxPGXNVI0VnFxg65imPauIG 2X0tav9J4xeMwIDw66bkISEBey2oGlyRX4pg8AS+7bteezNnO2fodwLCqowwjtYuQiia aEO/GNvigKrdT0Jm9+UHmZOUc7qPnpSFL20dZeGZw0pc6spkNGa/Q+8HGqvro+FsniLX xplA==
X-Gm-Message-State: AA6/9Rl/7fp+RBH+cnlmtIaV1dkhUU9YVC1bVO4opOZPPNyh6zsMUw2DewueJEp+GymSEr90dhvfdG2Tp22Tqg==
X-Received: by 10.107.185.8 with SMTP id j8mr2622247iof.3.1476206773700; Tue, 11 Oct 2016 10:26:13 -0700 (PDT)
MIME-Version: 1.0
References: <CAOjisRznhk-Fww=EnRg7zXO-zaHWyNgi0g+reRBj+y3ZOhwMhw@mail.gmail.com> <d267aa85-56fc-b7b0-dc1f-3373f3b0c563@gmx.net>
In-Reply-To: <d267aa85-56fc-b7b0-dc1f-3373f3b0c563@gmx.net>
From: Nick Sullivan <nicholas.sullivan@gmail.com>
Date: Tue, 11 Oct 2016 17:26:02 +0000
Message-ID: <CAOjisRxMAyzEVG_0THV9q6R9EHtPNKk94OB+pOzH_Q3kyi-ZQg@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, "tls@ietf.org" <TLS@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c076a6a5cd83d053e9a2cf1
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/SKsOWzB4LJWTs_TCdMSAgsuKPuo>
Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)
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, 11 Oct 2016 17:26:16 -0000

The major thing that this proposal achieves is that it makes post-handshake
auth an optional part of the implementation. Instead of this, I would also
be in favor of a simpler change that modifies the text to say that
post-handshake CertificateRequest messages are fatal by default and only
permitted if the application permits their use in a given context (say if
the application is HTTP 1.1, only directly after requests).

Embedded implementations may choose to simply fail on unexpected
CertificateRequests, and that way not have to implement any code around
post-handshake finished messages or updating the transcript when one
arrives.

This default wording should also apply to other types of post-handshake
messages, though NST and KU could be exceptions that should always be
supported and non-fatal.


On Tue, Oct 11, 2016 at 9:37 AM Hannes Tschofenig <hannes.tschofenig@gmx.net>;
wrote:

> Hi Nick,
>
> given my discussion with Martin in this thread
> https://www.ietf.org/mail-archive/web/tls/current/msg21481.html I like
> your idea of making the post-handshake messages optional since it allows
> me to develop a TLS 1.3 client that is smaller in code size.
>
> Ciao
> Hannes
>
>
> On 10/08/2016 03:03 AM, Nick Sullivan wrote:
> > There has been a lot of discussion lately about post-handshake messages
> > that do not contain application data and how to handle them. This PR is
> > an attempt to make the story more explicit by adding a new
> > post_handshake extension to TLS 1.3.
> >
> > Supporting all types of post-handshake messages can require extra
> > complexity and logic, even when the features that these messages enable
> > are not needed. Some types of connections/implementations don't need to
> > support key updates (some unidirectional connections), session tickets
> > (pure PSK implementations) and post-handshake client auth (most
> > browsers). These are all currently SHOULDs in the spec and they don't
> > need to be.
> >
> > In order to simplify the logic around dealing with post-handshake
> > messages, this proposal makes support for each of these modes explicit
> > via a new handshake extension. This change also makes the path to
> > introducing other types of post-handshake messages in future drafts more
> > explicit.
> >
> > PR:
> > https://github.com/tlswg/tls13-spec/pull/676
> >
> > Nick
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
>