Right now, we ignore transport parameters if we don't understand tham. We use the same decoder when we parse remembered transport parameters when validating 0-RTT.
In the case that we remove support for a transport parameter (say, a draft version we no longer want to keep around), then we have to reject 0-RTT if there are any transport parameters we don't know about. Otherwise, the client might assume that it's OK to use that feature, but we just removed it.
The fix: when parsing back transport parameters for 0-RTT, disabling the code that ignores unknown types. We should be safe for regular updates (i.e., we won't unnecessarily disable 0-RTT) provided that we don't save unknown types. This should not be a fatal error, but it should result in disabling 0-RTT.
Not urgent, and it's a server bug, which we don't prioritize, but worth keeping in mind any time we might consider removing a transport parameter.
Right now, we ignore transport parameters if we don't understand tham. We use the same decoder when we parse remembered transport parameters when validating 0-RTT.
In the case that we remove support for a transport parameter (say, a draft version we no longer want to keep around), then we have to reject 0-RTT if there are any transport parameters we don't know about. Otherwise, the client might assume that it's OK to use that feature, but we just removed it.
The fix: when parsing back transport parameters for 0-RTT, disabling the code that ignores unknown types. We should be safe for regular updates (i.e., we won't unnecessarily disable 0-RTT) provided that we don't save unknown types. This should not be a fatal error, but it should result in disabling 0-RTT.
Not urgent, and it's a server bug, which we don't prioritize, but worth keeping in mind any time we might consider removing a transport parameter.