I've updated the PR based on feedback from Dave, Ilari, and Martin. https://github.com/tlswg/tls13-spec/pull/211
I'll merge this PR on 8/11 unless there are serious objections. As usual please send minor changes as github comments and/or PRs. -Ekr On Tue, Aug 4, 2015 at 5:40 AM, Eric Rescorla <e...@rtfm.com> wrote: > > > On Mon, Aug 3, 2015 at 11:51 PM, Ilari Liusvaara < > ilari.liusva...@elisanet.fi> wrote: > >> On Sat, Jul 25, 2015 at 09:07:49PM +0200, Eric Rescorla wrote: >> > >> > >> > We agreed on how to do this in Prague. The sticking point was >> establishing >> > the cipher suite. I have WIP text on my machine for both of these which >> I >> > will be >> > sending early next week, once I get enough sleep to be able to clean it >> up, >> > so I'd ask people to sit tight till then. >> > >> >> Okay, now the PR (#211) seems to be up, let's review > > > Oops. It wasn't supposed to be done. I meant to make it a PR against my > own branch so that I could get early comments from MT, but obviously that > didn't work out. Regardless, thanks for your comments. > > > - Lacks client-driven client authentication[1]. All client auth is server >> driven, which I think isn't very useful in real world (there are all >> sorts of bad hacks[2] trying to work around lack of client-driven auth). >> > > This is just extending existing practice for 1-RTT handshakes. > > I tend to agree with you that it would be good to change that, but I > didn't want > to do that in this PR, because it would be a big semantic change in TLS. > I suggest you start a new thread on this topic, or perhaps add it to > Andrei's > client auth thread? > > > - EncryptedExtensions looks to be mandatory in some exchanges, optional >> in others. I agree it should be mandatory in all (issue #213). >> > > Me too. That's just editing error. > > > >> - "The client's cryptographic determining parameters match the parameters >> that the server has negotiated based on the rest of the ClientHello." >> ... Does that mean the client has to guess what ciphersuite the server >> will choose (more than pure-PSK vs. GDHE, which is unvaoidable with >> just one encrypted block)? >> > > The client knows what the server selected based on his previous offer and > the server's configuration (which by hypothesis is still extant) so the > server > should choose the same value again. > > >> - Am I reading the syntax wrong, or does the extensions field in server >> configuration only allow exactly one extension (shouldn't it be zero >> or more)? >> > > Yes. good catch. > > > Also, regarding issue #212, unless the Certificate is handled specially, >> it would mean that the signature does not cover certificate. And not >> signing the certificate (esp. the public key within) causes problems >> in some exotic cases (I don't know if any of those cases pop up in TLS >> 1.3). >> > > This seems like a good argument. > > > >> I think it would simplify the security analysis a bit if CertificateVerify >> was always immediately before Finished and covered everything before that >> point. >> > > Isn't this always the case presently? Are you just thinking we should say > it's > a rule? > > -Ekr > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
