Draft: draft-ietf-emu-eap-tls13

Commentary: According to suggeestion in issue 
  has suggested that more Profiling / guidance regarding NewSessionTicket would be good . TLS 1.3 allows any number of newsessionticket to be send in any of the server flights . All ways are secure . TLS 1.3 leaves how and when to the TLS implementation . 
 This is a new request for technical change not related to the IESG DISUCUSS . Based on earlier discussions changes to the TLS layer are likely a bit controversial .  : I do n't see what is special with EAP - TLS here . I also do n't know what a good recommendation for the TLS layer would be or what can be enforced in TLS implementations . This would likely need interaction with TLS people , 
 Note also that draft - ietf - tls - ticketrequests is in the RFC Editor 's queue and goes into a bit more detail about when different numbers of tickets might be desired ( as well as a mechanism to indicate the client 's desires , though it 's not entirely clear to me whether that will be very helpful for the EAP - TLS usage ) . 
 Based on your earlier comment on draft - ietf - tls - ticketrequests , I already a reference to ietf - tls - ticketrequests in version -14 " A mechanism by which clients can specify the desired number of tickets needed for future connections is defined in [ I - D.ietf - tls - ticketrequests ] . " 
 Oops , shame on me for not checking . ( Thanks for adding the reference the last time I mentioned it ! ) 
 I think it would be fine to include a SHOULD send only one NewSessionTicket since EAP clients will typically only need one at a time . 
 I am not comfortable adding such guidance without a thorough survey of libraries . As draft - ietf - tls - ticketrequests says : " servers vend some ( often hard - coded ) number of tickets per connection . Some server implementations return a different default number of tickets for session resumption than for the initial connection that created the session . No static choice , whether fixed , or resumption - dependent is ideal for all situations . " I know that openssl allows to control number of tickets with but I do n't we think we can be sure about behavior of all libraries out there . Also some noteworthy text from draft - ietf - tls - ticketrequests : " Especially when the client was initially authenticated with a client certificate , that session may need to be refreshed from time to time . Consequently , a server may periodically force a new connection even when the client presents a valid ticket . When that happens , it is possible that any other tickets derived from the same original session are equally invalid . A client avoids a full handshake on subsequent connections if it replaces all stored tickets with new ones obtained from the just performed full handshake . The number of tickets the server should vend for a new connection may therefore need to be larger than the number for routine resumption . " 
 How about removing the normative SHOULD , something like : desired number of tickets needed for future connections is defined in [ I - D.ietf - tls - ticketrequests ] . 
 This non - normative suggestion sounds good to me . 
  's suggested text looks good . By the way , I checked boringssl : It seems to issue 2 tickets by default ( static const int kNumTickets = 2 ) . As far as I can tell , the only way to limit to 1 ticket is by changing the code manually and re - compiling the library . 
 This is resolved in PR 
 Merged PR
Paragraph (version A):
A mechanism by which clients can specify the desired number of
tickets needed for future connections is defined in I-D.ietf-tls-
ticketrequests.
Paragraph (version B):
Servers should take into account that fewer newSessionTickets will
likely be needed in EAP-TLS than in the usual HTTPS connection
scenario.  In most cases a single newSessionTicket will be
sufficient.  A mechanism by which clients can specify the desired
number of tickets needed for future connections is defined in I-
D.ietf-tls-ticketrequests.