On Fri, Feb 10, 2017 at 12:52 PM, Sam Scott <sam.scot...@gmail.com> wrote:
> 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. > I agree. It doesn't mitigate B at all unless there are application semantics that do so (which is the same as it doesn't mitigate it, I guess). > 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. > Yes, I agree with this. -Ekr > 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
