On Tue, Feb 23, 2016 at 3:49 PM, Karthikeyan Bhargavan <
karthik.bharga...@gmail.com> wrote:
> There are some fears about 0.5-RTT data that do not necessarily apply to
> post-client authentication, at which point at least both parties have sent
> their Finished messages.
>
> When the server is sending 0.5-RTT data, this is effectively false-start;
> the client hasn’t confirmed its choice of ciphersuites yet, and downgrade
> attacks may become possible.
> To be principled, we should look at the current browser best practices for
> false start and make sure that 0.5-RTT data abides by them.
> For example, one may argue that 0.5-RTT is actually a bit worse than
> false-start in TLS 1.2 where at least the peer’s presence and DH key has
> been authenticated before false start data is sent.
> There is no such guarantee in 0.5-RTT.
>
> The question is whether this is just a server-side concern, or does the
> client need to be aware of 0.5-RTT.
> I don’t know the answer to that, but if we wanted to setup a 0.5-RTT rule,
> I would say that it should *only*
> be sent during PSK-resumption handshakes, because the PSK authenticates
> the peer, and because
> the server is likely responding to some 0-RTT data sent by the client/
>
> Again maybe this breaks some server push scenarios that I am not aware of.
>
> Best,
> Karthik
>
> PS: The OPTLS proof does not require ClientFinished, but they do not
> consider downgrades or client auth.
>
That's right, we do not consider downgrades or client authentication but
Martin's suggestion explicitly only applies to the case where the server
does not require client authentication so the analysis holds in that case.
As for downgrades, this will be discovered by the server when receiving the
client's Finished message. So the only problem I see is that the server
might have been "tricked" to send the 0.5-RTT data with less protection
than intended by the (honest) client. But for that there is no need for
downgrade. The attacker could have generated the exchange with the weaker
ciphersuite by himself (acting as a client). If the server accepts that
ciphersuite it means he is willing to send that particular data with that
level of security to *anyone*. That is the meaning of not requiring client
authentication.
One useful feature of client's finished is to catch 0-RTT replays. But
even then I am not sure what damage can be done to the 0.5 data. Either the
attacker knows the client's keying material (say PSK) and can generate the
client finished by himself or he doesn't know that keying material but then
it cannot decrypt 0.5 data.
Am I missing something on these particular points?
On the whole, cryptographers including the authors of OPTLS would be
> happier with 0.5-RTT keys
> not being the same as 1-RTT keys. Again, so far, this is a matter
> of taste and proof modularity.
>
Agreed.
Hugo
> > On 23 Feb 2016, at 11:27, Martin Thomson <martin.thom...@gmail.com>
> wrote:
> >
> > Karthik raised some concerns here, and I think that we have some
> > thinking to do. But I don't think that it is intractable, nor even
> > hard, to reason about this problem.
> >
> > The only thing that the client's second flight provides is
> > authentication. The Finished isn't needed if there is no client auth
> > [P]. Hugo's presentation at TRON did not include a client Finished in
> > the earlier, simpler examples.
> >
> > Thus, based on Watson's observation that the client authentication is
> > removable, we might conclude that the handshake is complete from the
> > perspective of a server that does not require client authentication.
> > There are still reasons we might like to keep the client
> > authentication in the handshake, but those are decisions we can make
> > on engineering grounds.
> >
> > If post-handshake client authentication is OK, then 0.5 RTT is equally
> > OK [X]. I would assert that any decision about changing keys after
> > the client Finished applies to post-handshake client auth (or vice
> > versa).
> >
> > If that logic is sound, then I see no reason we can't have some very
> > simple advice:
> >
> > 1. if the server does not request client authentication, it can send
> > application data immediately following its Finished
> >
> > 2. if the server requests client authentication, it MUST NOT send
> > application data until it receives and validates the client's first
> > flight. UNLESS the server is certain that the data it sends does not
> > depend on the client's identity (that is, it would send this
> > application data to anyone).
> >
> >> From an API perspective, I believe that we should recommend that there
> > be a separate function for sending in condition 2, just as we are
> > going to recommend that there is a separate function for sending 0-RTT
> > data (as well as there being one to receive on the server end).
> >
> > Based on this, we should recommend different points in time for the
> > server API to report that the handshake is "complete" at a server. In
> > condition 1, the handshake is complete after the server Finished is
> > sent; in condition 2, the handshake is complete after the client
> > Finished is received.
> >
> >
> > [P] Note that a client Finished does confirm a PSK. Though you might
> > reasonably argue that successfully generating valid application data
> > works equally well in that regard.
> > [X] Post-handshake client authentication has only been analyzed very
> > lightly, so we have to caveat that statement too.
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
