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

+ Mike who has additional concerns with this.

Cheers,

Andrei

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Tuesday, October 11, 2016 10:22 AM
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Cc: tls@ietf.org
Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

I think it would be simpler (and deal with most cases) to only allow this for specific application
profiles (we would then allow it in HTTP/H2, perhaps with some small -bis RFC).

Here is a PR for this:
https://github.com/tlswg/tls13-spec/pull/680

Andrei, would this cause you any problem? My impression was that this use case was only
about HTTP/H2.

Thanks,
-Ekr

On Tue, Oct 11, 2016 at 9:37 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net<mailto: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<mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls
>

_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls