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

[Mike Bishop <[e-mail]>]

There are a couple of scenarios we need to keep in mind:

1.       Existing HTTP/1.1 exchanges over upgraded TLS clients.  If we need a brief RFC that says post-handshake client auth is allowed for HTTP/1.1 over TLS 1.3, that’s fine.

2.       Client authentication in HTTP/2.  Slightly longer RFC for this (but possibly the same one) that says post-handshake client auth is allowed for HTTP/2, then describing how to use the context (and new HTTP/2 frames, if needed) to bind the PHA exchange to one or more streams.

3.       Secondary server authentication in HTTP/2.  This approach still doesn’t give a clean way to do this, unless we use exporters and roll our own.  That has proven to be a little hazardous to everyone’s peace of mind, but remains something we can refine in the future.

What concerns me more, though, is the prospect that a lot of TLS implementations would simply omit support.  Obviously, it’s not used in most HTTP sessions, and you may be an implementation whose niche doesn’t require supporting it – but since the application profile allows it, you still need to know how to decline if asked.  If it’s allowed in HTTP, which I assume is a supported workload for most implementations, then it’s allowed in your application profile and therefore prohibiting it by default doesn’t seem like it buys you much.  Having a simple way to disclaim support, either at connection time or upon receiving a challenge, seems like it provides more simplicity for the implementations that want to omit it.

From: Andrei Popov
Sent: Tuesday, October 11, 2016 11:09 AM
To: Eric Rescorla <[e-mail]>; Hannes Tschofenig <[e-mail]>; Mike Bishop <[e-mail]>
Cc: [e-mail]
Subject: RE: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

+ Mike who has additional concerns with this.

Cheers,

Andrei

From: TLS [mailto:[e-mail]] On Behalf Of Eric Rescorla
Sent: Tuesday, October 11, 2016 10:22 AM
To: Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tls
>

_______________________________________________
TLS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls