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. 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... > 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"? 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. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
