You're right. I just missed it. Added to the editor's copy. Thanks, -Ekr
On Thu, Oct 20, 2016 at 12:43 PM, Kazuho Oku <kazuho...@gmail.com> wrote: > Hello, > > It's great to see draft-17 being published. Thank you all for the effort. > > Maybe the addition of extensions field to the Certificate message got > lost in the changelog? > https://github.com/tlswg/tls13-spec/pull/654 > > My understanding has been that it was a post-16 change and it changes > the wire protocol. > > > 2016-10-21 1:32 GMT+09:00 Eric Rescorla <e...@rtfm.com>: > > Folks, > > > > I have just uploaded draft-ietf-tls-tls13-17. > > > > The major change in this draft is the removal of the 0-RTT Finished > > and resumption_context constructs and their replacement with the > > psk_binder. This has a number of side effects: > > > > - Binds in the original transcript into the resumed handshake > > whenever resumption-PSK is used. > > > > - Provides proof of possession of the RMS by the client (subject > > to replay issues). I've moved the obfuscated_ticket_age field > > out of the early_data_indication so that it now provides the > > same limited anti-replay for non-0-RTT PSK. > > > > - Removes the need for any early handshake encryption. This change, > > along with the dual key ladders we introduced in -16, also allowed > > us to simplify the traffic key expansion so we don't need explicit > > labels for each key (they are already used in Derive-Secret). > > > > > > Other changes included: > > - Tweaking the PSK key exchange modes a bit (and removing the > > inoperative ability to specify PSK auth modes, while leaving > > a hook to do it later). > > > > - Cleaned up the cipher suite requirements for resumption and 0-RTT. > > You can resume/do PSK as long as the PSK KDF matches, but to do 0-RTT > > you need the whole cipher suite must match. > > > > > > This revision resolves all the outstanding technical PRs [0] and all but > > one of the non-parked technical issues (#144, whether we should remove > the > > redundant TLSCipherText.opaque_type and TLSCipherText.record_version > > fields). We are pursuing measurements to resolve whether this will > > be a compat problem but we don't have them yet. > > > > As usual, comments welcome. We are already working on implementing > > -17 in NSS/Firefox and should have it before Seoul. > > > > -Ekr > > > > Full Changelog > > - Remove the 0-RTT Finished, resumption_context, and replace with a > > psk_binder field in the PSK itself (*) > > > > - Restructure PSK key exchange negotiation modes (*) > > > > - Add max_early_data_size field to TicketEarlyDataInfo (*) > > > > - Add a 0-RTT exporter and change the transcript for the regular exporter > > (*) > > > > - Merge TicketExtensions and Extensions registry. Changes > > ticket_early_data_info code point (*) > > > > - Replace Client.key_shares in response to HRR (*) > > > > - Remove redundant labels for traffic key derivation (*) > > > > - Harmonize requirements about cipher suite matching: for resumption you > > need to match KDF but for 0-RTT you need whole cipher suite. This > > allows PSKs to actually negotiate cipher suites. (*) > > > > - Explicitly allow non-offered extensions in NewSessionTicket > > > > - Explicitly allow predicting ClientFinished for NST > > > > - Clarify conditions for allowing 0-RTT with PSK > > > > > > [0] The two remaining outstanding PRs are: > > #680: Forbid post-handshake authentication except when permitted by > > application profile. This is almost entirely a requirements-level > > change, though it would allow clients to send "unexpected_message" > > when receiving an unexpected CertificateRequest. > > > > #612: TLS 1.3 -> TLS 2.0 > > This has no change on the wire format. > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > -- > Kazuho Oku >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
