Re: [TLS] Followup on Update

[Ilari Liusvaara <[e-mail]>]

On Tue, Feb 24, 2015 at 04:44:22PM -0800, Eric Rescorla wrote:
> Folks,
> 
> I'd like to get a sense of the WG on whether they want to pursue the Update
> mechanism [0].
> 
> There are several possibilities here, including:
> 
> - Just do basic Update

This seems pretty okay to me.

If there is some cryptographic concerns (that I can't see, and would
really appeciate if those were pointed out[1]) of server sending data
with pending certificate request[2], could those be addressed by
having the client Update the connection after sending certificate
and its verification?

Regarding misuse potential of that, the client is unidentified at
the point, so it seems pretty hard to misuse.

Now, with some non-DHE key exchanges (mainly PAKE) you might have
identified but unauthenticated client. I think it is reasonable
for the TLS library to return error for attempts to obtain the
client identification before it is authenticated. The present
rule does not help here, since the authentication does not involve
a client certificate.


> - Move session ticket establishment to Update

How does client know when it can resume a session? It takes 1RTT
to get connection to state where it can transmit data, but 2RTT
to state where it can resume (since server needs to have received
client's second flight, or resume is not going to work right).


> - Mode client authentication to Update

This scares me. Not the crypto parts, but the misuse potential. Even
doing it once seems as bad to me as doing it N times.

If the protocol is something like imaps, submission(stmp) or ircs,
then sure it looks safe.

But try to use it e.g. with active HTTP/2 connection, and thing just
go badly wrong. This is because adding/dropping certificates with
multiplexed protocol needs substantial coordination at application
layer to do safely.


[1] And if there are such, I think SSH should carefully be analyzed,
because it does pretty much exactly this.

[2] Would be useful for e.g. protocol feature negotiation, since
ALPN does not scale. E.g. consider wanting to use HTTP/2 with
tokbind (ChannelID) + Websockets.


-Ilari