Is it common that 0.5 RTT data will be sent by the server in a fresh
session? I.e. not after a resumption and therefore without the client
previously sending early data?
Even so, it does also seem like a slightly troubling scenario, since the
client has no (in-band) mechanism to determine the authentication was
successful (or even at what point it arrived). Again, this could be
rectified by forcing the client/server to update their keys, and even
better if they include the client's authentication messages.
However, NewSessionTicket messages do not have this problem since the
server wont send these before processing the client Finished, but it
could still be an issue in the post-hs scenario.
Just want to reiterate: thanks all for helping to clarify this behaviour
we've encountered. Hopefully it proves a useful insight into the
guarantees (or lack thereof) provided by client authentication. Also it
is really useful in helping us to refine our model :)
Sam
On 11/02/17 01:49, Andrei Popov wrote:
What about Eric’s other point:
ØI am not sure that the regular TLS handshake guarantees these
Øproperties either. The reason is that the server is permitted to
Øsend data prior to receiving the client's second flight (0.5 RTT
Ødata).
With the server sending data prior to receiving the client’s second
flight, it seems that property B is not there when using in-handshake
client authentication as well?
Cheers,
Andrei
*From:*TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Sam Scott
*Sent:* Friday, February 10, 2017 12:53 PM
*To:* Eric Rescorla <e...@rtfm.com>
*Cc:* tls@ietf.org
*Subject:* Re: [TLS] Awkward Handshake: Possible mismatch of
client/server view on client authentication in post-handshake mode in
Revision 18
Hi Ekr,
That's a good summary of the situation. Indeed we weren't previously
considering TLS as able to enforce the ordering of messages which does
seem to mitigate our scenario for property A. We haven't really had a
chance to take that into consideration for property B, but at a glance
it does still seem to be an issue.
As mentioned in my other email, one scenario we encountered this was
if (using your message numbering as reference) messages 5 or 9
happened to be a NewSessionTicket. In this case, the client might be
under the impression that they have a session ticket for a mutually
authenticated channel.
Thanks,
Sam
On 10/02/17 20:39, Eric Rescorla wrote:
Cas, Sam,
I thought I understood your concern here but maybe I don't.
Say we have the following sequence of messages
1. C->S: ClientHello
2. S->C: ServerHello...ServerFinished
3. C->S: ClientFinished
4. C->S: App message
5. S->C: App message
6. S->C: CertificateRequest
7: C->S: Certificate...Finished
8: C->S: App message
9: S->C: App message
As you indicate, there's some ambiguity from the client's perspective
(property B) about whether messages 5 and 9 were sent by the server
prior to or after receiving message 7, and also message 8. This
ambiguity exists even without an attacker and may or may not be
resolved at the application layer. An attacker can exploit this
ambiguity by holding messages 7 and 8 and (as long as application
semantics permit this).
Where I get confused is about property A. As I understand your
claim, an attacker can hold message 7 but deliver message 8 and
therefore, even if the client knows that 9 was in response to 8,
he doesn't know that the server received 7. As Ilari says, I don't
believe that this is correct because TLS enforces message ordering.
I agree that the specification doesn't explicitly say this, but
it's implicit in the processing rules via the following:
1. The encryption for each TLS record depends on the record sequence
number (RSN).
2. Records do not carry their RSN, so when you decrypt a message, you
must use the last RSN + 1
3. When you fail to decrypt a message (which is what happens if
you have
the wrong RSN) you are required to tear down the connection
(https://tlswg.github.io/tls13-spec/#record-payload-protection).
For this reason, if the attacker removes message 7, then 8 will not
be decryptable, and so ordering is preserved. As Ilari says, this
isn't
true in DTLS 1.3 which we'll presumably have to deal with one way
or the other before standardization (my plan would be just to forbid
post-handshake auth). Do you disagree with this? If so, perhaps you
could explain.
-Ekr
P.S. I am not sure that the regular TLS handshake guarantees these
properties either. The reason is that the server is permitted to
send data prior to receiving the client's second flight (0.5 RTT
data). See:
https://tlswg.github.io/tls13-spec/#protocol-overview
On Fri, Feb 10, 2017 at 11:45 AM, Sam Scott <sam.scot...@gmail.com
<mailto:sam.scot...@gmail.com>> wrote:
Hi Ilari,
Thanks for the comments.
Assuming the client sends a valid certificate that the server
accepts, then the server cannot finish the handshake or begin
processing incoming application data until authenticating the
client. This *almost* gives us property (A). In practice, the
client is aware that the server has successfully authenticated
since the protocol continues.
In the case that the server has implemented the reject option
(rejecting a certificate but still continuing), and indeed
rejects the certificate, then the server should send an alert
message (or NAK of some form) for the property to hold in the
initial handshake.
However, even if we take the certificate reject + continue
scenario into account for the initial handshake, then it is
clear that this decision can only be made by the server in the
initial handshake, while in the post-handshake client auth, an
attacker can decide this (by dropping the message).
The reason we don't believe an explicit ACK is needed is
because upgrading to a new pair of keys explicitly provides
this. Specifically, the client will send all subsequent data
to the server under a new key. The server will not be able to
decrypt this data until they receive the client authentication
messages and upgrade the keys.
This can be strengthened if the client's updated write key is
computed using the authentication messages.
We agree that TLS enforcing ordering of messages provides
similar guarantees. However, we are analysing the
specification as it is presented, which does not guarantee this.
Thanks,
Sam
_______________________________________________
TLS mailing list
TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
