On Fri, Jul 08, 2016 at 11:06:46AM +0000, Fossati, Thomas (Nokia - GB) wrote: > Hi Nikos, > > On 08/07/2016 10:55, "Nikos Mavrogiannopoulos" <n...@redhat.com> wrote: > >On Fri, 2016-07-08 at 09:29 +0000, Fossati, Thomas (Nokia - GB) wrote: > > > >As long as both the client and the server are able to notify each other > >that they only support L=1 I'd be content with it. > > In the straw man I proposed above, it is sufficient for the server to say > L=1. In that case the client will trigger a re-handshake when its Id > rollover policy says so.
The client can't re-handshake. It probably would be able to obtain a new ID to replace the "burned" one. This way the client only needs enough IDs to obtain a new one before all IDs are exhausted. However, turns out this doesn't actually work as well as hoped in practice. The problem is that client can't really change address voluntarily (even if it is behind CGNAT, it probably can't change the outgoing address until CGNAT triggers involuntary rebinding, and client can't react to such rebindings fast enough. So it would be limited to cases where the client has non-NAT connection and is renumbered. And such pretty rarely happens. Given the above, I wonder if just having main and backup ID would be enough: When changing addresses, backup ID becomes main ID, and client asks server for a new ID that becomes the new backup ID. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
