On Sat, Feb 11, 2017 at 6:52 AM, Sam Scott <sam.scot...@gmail.com> wrote:
> 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? > Yes, I think it will be, especially in cases where the server says the same thing to every client (e.g., HTTP settings frames). Probably a less often in cases where the initial handshake will demand client auth. 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, > Specifically: the EMS is derived from the client's entire transcript through the client's Finished, so you can't compute it until then. but it could still be an issue in the post-hs scenario. > Yes, NST is asynchronous wrt post-handshake auth, just like app data messages. -Ekr > 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 <tls-boun...@ietf.org>] *On > Behalf Of *Sam Scott > *Sent:* Friday, February 10, 2017 12:53 PM > *To:* Eric Rescorla <e...@rtfm.com> <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> 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 > https://www.ietf.org/mailman/listinfo/tls > > > > > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
