Ilari, Thanks for your quick review.
On Tue, Dec 1, 2015 at 10:57 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Tue, Dec 01, 2015 at 10:11:17AM -0800, Eric Rescorla wrote: > > > > This clears out the big pipeline stall from PR#316, but probably has > > created some bustage. Expect a series of cleanup commits and some > > other things that were head-of-line blocked this week and then > > draft-11 in the next week or so. Please file PRs and/or github > > issues for any issues you see. > > Looks like the note about the PSK+ClientCert "attack" got lost > somewhere. See the last graf of: http://tlswg.github.io/tls13-spec/#certificate-verify I pointed to the e-mail by Sam's group and also prohibit entirely the use of cert-based client auth in pure PSK, since that seemed safer. If you think more is needed here I would be happy to add it. While I don't think that is important as the underlying > issue is fixed, I think there might be a note about dangers of using > server certificates in any mode where transcript and configuration > do not jointly imply SS. > > Actually, scanning the editor's copy, it looks VERY broken to me: > I don't see how server certificate verify (indirectly) signs on the old > configuration. Such signing is required for security, as otherwise > SS is not impiled by signature, breaking authentication. > > Previously, the document was clear about this... > I'm sorry, but I'm not following the issue you are raising here. Perhaps you could expand further? Here's my reasoning. 1. The server delivers the server configuration in handshake #0 and signs the entire transcript with the certificate verify. At this point the client has assurance of the server's g^s. 2. In handshake #1, the client sends g^x and there is authentication for g^xs and hence the client knows that any data it is sending to the server in 0-RTT is actually going to the server. 3. The server provides g^y in his ServerHello and then g^xy and g^xs are jointly used to produce the traffic keys and also to form a MAC over the handshake. As Hugo pointed out originally, this alone should be sufficient to authenticate the server's side of the connection and you could omit the server CertificateVerify (Hugo, please correct me if I have misunderstood). 4. However, for consistency reasons (per the discussion in Prague), the server *also* signs the entire transcript. This authenticates g^y (even though the MAC with g^xs already authenticated it) and proves possession of the signing key. Trying to read between the lines, is your concern that the server is now no longer explicitly signing over the ServerConfiguration in its CertificateVerify [Note that the client continues to do so]? The idea behind removing that was to make the 1-RTT part of the handshake more uniform regardless of whether 0-RTT data was used. I'm certainly open to putting that back in if it's needed, but can you explain your concern in more detail? > In addition, PR#354 (https://github.com/tlswg/tls13-spec/pull/354) > > implements the rekey mechanism that we discussed in Yokohama. There > > was broad agreement to adopt something like this. I would appreciate > > it if a few people could give it a sanity check, but absent strong > > objections, I intend to merge this PR on Friday. > > The restrictions on when the rekey message can be sent: Do those > essentially boil down to "any time after sending Finished"? > Except not during 0-RTT. Also, I think the requirement to immediately send the KeyUpdate > is problematic. I think it should be requirement to send it as > next record(s). > The two aren't the same: The first seemingly requires scheduling > extra flights, which can be problematic. The second can piggyback > on existing flights. > Good suggestion. PR welcome. :) -Ekr > > > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
