On 7/07/2016, at 10:37 am, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > On 07/07/16 09:13, Nikos Mavrogiannopoulos wrote: >> does not make the situation any worse >> than we have today. > > I don't accept that is the correct goal. That form of > argument is what lead to us standardising the HTTP > Forwarded header field, which IMO was a disimprovement. > (An argument I lost in the end in that case [1], but > 'twas close, and back in 2012 so might go the other > way today;-) > > I would argue that the correct goal is to make things > better whenever possible, with that being especially > important for protocols like (D)TLS on which many > other things depend. > > I do agree that any scheme developed would need to > meet the state management requirements of servers. > I'm not convinced those requirements call for a new > super-cookie though:-)
What about making it an optional value, with clients that don’t need such behaviour specifying an all-zero value? I have a use case where I control both clients and servers and would like to automatically and simply deal with changing IPs/ports on both sides, and would much rather have this functionality built into DTLS than having to somehow preface the DTLS packet with this ID added. If we were to go down this route, I would ask that there is a mechanism for an endpoint (server or client) to verify the legitimacy of the IP/port change before handing the data to an upper layer. E.g. Recipient (server or client) receives the ID from a new source (Initiator), sends an encrypted challenge to the new source/initiator, and the initiator replies with an encrypted challenge response at which point the recipient can validate and adjust its return path. Regards, Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
