On Tue, Dec 1, 2015 at 11:19 AM, Eric Rescorla <e...@rtfm.com> wrote:
> 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]? > And, I should note the server's certificate. -Ekr > 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
