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

[Benjamin Kaduk <[e-mail]>]

With respect to communicating policy from the application layer to the
TLS stack, what's wrong with David's "CertificateRequest is disallowed
by default, and the application must make a library call to enable it
for a given connection/context" proposal?  It seems fairly
straightforward in terms of API surface, to me.

You mostly mentioned this already, but this list of known message types
is another protocol surface that would need to be GREASEd.

So, on the balance, I think I'm starting to lean against this specific
proposal and more towards the text changes that David wants.

-Ben

On 10/08/2016 03:02 PM, Nick Sullivan wrote:
> I agree that "I don't like NST or KU" is not a very useful thing to
> add to the spec. I added them as part of a general move towards
> clarity and conservatism about which types of post-handshake messages
> are permissible in TLS 1.3. Right now the spec is ambiguous about what
> each side of the connection is supposed to do when it receives an
> unexpected or unknown post-handshake message. This change hopefully
> makes it crystal clear: any post-handshake message that wasn't agreed
> upon by both parties should be fatal.
>
> David suggested that the behavior with respect to post-handshake
> messages should be negotiated at the application layer. This also
> seems reasonable, but I worry about how this policy would be
> communicated from the application layer to the TLS stack. Would the
> application layer be alerted of incoming CertificateRequests and
> either terminate the connection or reply with an empty certificate and
> finished message? If we want to support "2018" post-handshake
> messages, will we just end up re-inventing this post_handshake
> extension in a later draft to advertise support? Different
> post-handshake messages have different uses, so I see how this more
> case-by-case application-dependent policy could be more expressive
> than what I proposed, but I worry we may end up with something more
> complex than necessary.
>
> In any case, post-handshake authentication as currently described is
> problematic. I'd be open to seeing a text change along the lines of
> what David proposed instead of the wire change I'm proposing as long
> as it includes some guidance around how it should interact with
> policies from the application layer.
>
>
>
> On Sat, Oct 8, 2016 at 9:55 AM Eric Rescorla <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     I could go either way on this. It seems like this pushes
>     complexity from the client to the server. 
>
>     Consider the case of NST. Presently, a client which doesn't want
>     resumption can just ignore NST,
>     but in your proposed change, the server needs to read this
>     extension and then conditionally send
>     NST, and the client still needs the logic to detect unexpected
>     handshake messages and abort
>     on them.
>
>     As I said, I could go either way, and I do think it's potentially
>     useful to be able to say "I won't do
>     post-handshake client auth" and even more useful to be able to say
>     "I would do post handshake
>     message X which will be invented in 2018" (but of course we can
>     register an extension for
>     that then), but less useful to say "I don't like NST or KU"
>
>     -Ekr
>
>
>     On Sat, Oct 8, 2016 at 9:32 AM, Nick Sullivan
>     <[e-mail] <mailto:[e-mail]>>
>     wrote:
>
>         I'm not proposing any new post-handshake authentication
>         mechanisms or anything relating to HTTP/2 renegotiation in
>         this change. I'm simply making support for the existing
>         post-handshake messages optional.
>
>         With this change, if the client does not opt in, unexpected
>         CertificateRequests are fatal to the connection. Same with
>         unexpected KeyUpdates and SessionTickets. This will hopefully
>         reduce the complexity of TLS 1.3 implementations that don't
>         need these features.
>
>         Nick
>
>         On Sat, Oct 8, 2016 at 8:06 AM David Benjamin
>         <[e-mail] <mailto:[e-mail]>> wrote:
>
>             On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara
>             <[e-mail]
>             <mailto:[e-mail]>> wrote:
>
>                 On Sat, Oct 08, 2016 at 01:03:21AM +0000, 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.
>
>
>
>                 Post-handshake authentication is the only one of these
>                 that is genuinely
>
>                 annoying. This is because you can't even reject it
>                 without a MAC, that
>
>                 additionally continues the handshake hash.
>
>
>
>                 KeyUpdate is rather simple, and NST can just be
>                 ignored (leading to some
>
>                 waste in bandwidth).
>
>
>             Yeah, after the fix to how KeyUpdate is acked, I don't
>             think we'd have problems with either of the way, while
>             post-handshake auth is indeed horrific.
>              
>
>
>                 Furthermore, the post-handshake authentication
>                 mechanism doesn't look to
>
>                 be featureful enough for kind of post-handshake auth
>                 e.g. HTTP/2 wants,
>
>                 And there are serious questions about how it should
>                 interact with
>
>                 applications.
>
>
>             An extension also doesn't really capture things if we
>             intend for, say, this to be used for legacy protocols like
>             HTTP/1.1 (where we don't have as rich a framing layer) but
>             not HTTP/2 (where we do and can use it as a substrate for
>             all this silliness). I was anticipating that, if this ends
>             up being used in the HTTP world like renego is, it would
>             be like our renego stuff: off by default, forbidden in
>             HTTP/2, and with all interleave forbidden.
>
>             Further, what useful thing could a server even do with
>             this extension? Decline to do post-handshake auth doesn't
>             work. Either the application protocol doesn't use
>             post-handshake auth (please pick this one) or it does. One
>             doesn't need to send a client_writes_first extension in
>             HTTP/1.1.
>
>             Post-handshake auth another knob on the TLS <->
>             application protocol boundary. This means each application
>             protocol must specify for itself what post-handshake auth
>             means: what to do with the context field, when it may be
>             received, what it does to application flow, etc. Then the
>             spec must be clear that if the application protocol does
>             not opt in, CertificateRequest is forbidden. A
>             CertificateRequest at an unexpected point (say, half-way
>             through a HTTP/1.1 body) is also forbidden. Also make it
>             clear this is for legacy protocols and new ones do not use it.
>
>             This is analogous to how HTTP/2 forbids renego at the spec
>             level. (TLS 1.2 got the "defaults" for renego wrong.) No
>             one ever wrote down the exact rules for the
>             client-auth/renego hack in HTTP/1.1, but whatever spec
>             does this for post-handshake auth should do the same for
>             renego.
>
>             It is a lot of spec work for such a tiny-seeming feature,
>             but this is consistent with how messy the feature actually is.
>
>             David
>
>
>         _______________________________________________
>         TLS mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/tls
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=4JAV0BkSLZSEEXJ9R5Q05mVpYdsy9VXbdJ8bSwOSLFM&s=UaYcBI3XziRGVy1WUuEI3hHeHMVXitoDfwb65g7xmkQ&e=>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls