Re: [TLS] consensus call: draft-ietf-tls-ticketrequests

[Christopher Wood <[e-mail]>]

On Wed, Mar 4, 2020, at 3:42 PM, Martin Thomson wrote:
> I have a third option (mu?) which differs from previous proposals.
> 
> I have been somewhat convinced by the arguments about how resumption is 
> different and can tolerate the complexity of the additional counter.  
> That is, endpoints can request replacement of consumed tickets (1 for 
> when a connection attempt succeeds, N if they race N connections and 
> only keep one; 1 + M if they want to replace M wasted tickets from M 
> previous failed connection attempts).
> 
> The text about reuse in PR 18 is not good, however.  (PR 18 is also 
> very wordy, but that's something I will leave to the editors of the 
> draft.)
> 
> I can live with a solution that has two numbers, but only on the 
> understanding that 0 means "no tickets".  That means no text on reuse, 
> except to discourage it.  It means implying that resumption=0 means 
> that the client plans to initiate a full handshake in future rather 
> than explicitly endorsing reuse.  As Russ mentions, we might cite the 
> relevant sections of RFC 8446 when it comes to reuse, but for me that 
> would have to be in the context of saying not to do that.

+1 -- I support two separate numbers given these constraints. 

Best,
Chris

> 
> On Thu, Mar 5, 2020, at 03:06, Sean Turner wrote:
> > one more time ...
> > 
> > All,
> > 
> > The purpose of this message is to help the chairs judge consensus on 
> > the way forward for draft-ietf-tls-ticketrequests. The issue at hand is 
> > whether the client-initiated ticket request mechanism [0] should be 
> > modified to add support for ticket reuse, see [1] lines 160-214. As we 
> > see it, the way forward involves either one draft or two. To that end, 
> > we would like your input (YES or NO) on the following question by 2359 
> > UTC 18 March 2020:
> > 
> >  Must the ticket reuse use case be addresses
> >  in draft-ietf-tls-ticketrequests?
> > 
> > Full disclosure: RFC 8446 recommends against ticket reuse to help 
> > protect clients from passive observers correlating connections [2]. The 
> > PR supports ticket reuse for use cases for a server-to-server 
> > connection that has fixed source addresses and no connection racing; if 
> > adopted the WG will need to ensure that the security considerations are 
> > properly documented.
> > 
> > Note: There have been at least three threads on this draft [3][4][5]. 
> > Please, let’s try to avoid re-litigating the points made therein.
> > 
> > Joe & Sean
> > 
> > [0] https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/
> > [1] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18
> > [2] https://tools.ietf.org/html/rfc8446#appendix-C.4
> > [3] https://mailarchive.ietf.org/arch/msg/tls/2cpoaJRushs09EFeTjPr-Ka3FeI/
> > [4] https://mailarchive.ietf.org/arch/msg/tls/-7J3gMmpHNw9t3URzxvM-3OaTR8/
> > [5] https://mailarchive.ietf.org/arch/msg/tls/FjhqbYYTwzgiV9weeCuxn0tHxPs/
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
> >
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>