So it seems like that would add a third class of extension: 1. Required extensions (type + value), not serialized 2. Required extensions (type only) [<--new], serialized as length+value 3. Optional extensions, serialized as type+length+value
There is some appeal to the logical completeness. The main complication would be serialization, just because you now have two serialized representations of an extension, length+value and type+length+value. You would probably want to serialize in two vectors (one of each type), to avoid switching within the Extension struct, which means that you'd always have two vector lengths instead of one, thus at least one byte of wire overhead for having the mechanism at all. Net/net, I'm not sure the need justifies the complexity. --Richard On Tue, Mar 10, 2020 at 12:28 AM Martin Thomson <m...@lowentropy.net> wrote: > On Tue, Mar 10, 2020, at 14:17, Watson Ladd wrote: > > One thing I noticed from my reading is there is no gain from knowing > > an extension will be present if one doesn't also know the value. > > That is only true if the extension has a value. (See also flags) > > > I could imagine SNI being very useful to include, and knowing the order > > of extension values permits their omission, keeping only the length. > > I believe that is the idea: put the extension at a fixed location so that > you don't have to signal its type, just its value. > > > This does mean very little freedom to add new unknown extensions. > > I don't think that is necessarily true. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
