2016-10-27 14:30 GMT+09:00 Eric Rescorla <e...@rtfm.com>: > > > On Thu, Oct 27, 2016 at 4:27 PM, Kazuho Oku <kazuho...@gmail.com> wrote: >> >> Hi, >> >> Thank you for posting draft-18, and thank you for the simplification of >> RMS. >> >> I have finished implementing resumption and early-data in picotls. The >> effort started just before draft-17 was published, so it would be fair >> to say that my effort is solely based on the up-to-date specification. >> >> I am happy to report that all I have found is one minor issue. >> >> The issue I saw is discordance between PSKIdentity.identity and >> NewSessionTicket.ticket. >> >> In draft-18, PSKIdentity.identity is defined as <0..2^16-1>. OTOH >> NewSessionTicket.ticket is <1..2^16-1>. >> >> Is there any reason to only allow a zero-length identity for the former? >> >> My understanding is that when resuming a session, the value of >> NewSessionTicket.ticket is sent as PSKIdentity.identity. So to me, it >> seems more natural if the permitted range of the two arrays were >> equal. >> >> Please forgive me for the fuss if the difference is intentional. > > > Well, you could have an external PSK which I suppose might be zero length. > > But I also wouldn't argue if we required this to be nonzero length.
Thank you for the clarification. Yes, having a zero-length external PSK makes sense. And for the same reason, I would argue that having a zero-length session identifier makes sense as well. For a client-server pair that only talk to the other, a zero-length session identifier would work well. So if we are going to align the ranges of the two arrays, it might make more sense to allow zero-length for both of them, instead of disallowing it. Please forgive me for the nit-pick. > -Ekr > >> >> 2016-10-26 14:43 GMT+09:00 Eric Rescorla <e...@rtfm.com>: >> > Folks, >> > >> > I have just posted draft-ietf-tls-tls13-18. >> > >> > The only wire format change from -17 is that I removed the extra key >> > derivation stage computing resumption_psk from RMS. This was a >> > holdover from when we also had a resumption context. Now PSK for >> > connection N+1 = RMS from connection N. Thanks to Kazuho for >> > suggesting this simplification. >> > >> > This draft also makes a number of minor editorial changes that >> > should make for easier reading. >> > >> > The two remaining open technical issues I am aware of are both >> > requirements issues: >> > >> > 1. Can you resume with a different SNI than the one that the >> > connection was initiated with [current answer is "no"]? >> > >> > 2. Do you need an application profile to do post-handshake >> > client auth [current answer is "no"]? >> > >> > There has been a bunch of discussion of these on the list but no >> > consensus declarations from the chairs. These are easy to change >> > in the draft once the chairs make the call. >> > >> > As always, comments welcome. >> > >> > -Ekr >> > >> > P.S. NSS will be skipping draft-17 and going right to -18. This >> > should happen before Seoul. >> > >> > >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >> > >> >> >> >> -- >> Kazuho Oku > > -- Kazuho Oku _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
