A practical limit of around 4000 octets for SvcParams seems likely to be fine. A hard limit of 250 octets has a real chance of becoming a practical problem. I would encourage you to reconsider the format.
As a concrete example, SvcParams are used to deliver public keys for ECH. Currently, only elliptic-curve keys are used, but if a future iteration relied on RSA public keys, they would not fit within this limit. On Wed, Oct 12, 2022 at 1:41 PM Alan DeKok <[email protected]> wrote: > On Oct 12, 2022, at 1:32 PM, Ben Schwartz <bemasc= > [email protected]> wrote: > > > > The Encrypted-DNS-SvcParams TLV seems to be limited to 253 octets. This > is a problem, since it is meant to hold a SvcParams object that is allowed > to be much larger (up to ~65000 octets in principle). > > The length is less than 253 octets, as it is encapsulated inside of > another attribute "wrapper". So the practical limit is probably 250 or > less. > > RADIUS provides for encoding more than 253 octets in an attribute. See > https://www.rfc-editor.org/rfc/rfc8044#section-3.16 > > However, this capability exists only for "top level" attributes, and > cannot be used here. > > Further, RADIUS packets are generally limited to 4K octets total. So > even if the limits on this attribute are removed, then there's still a > practical limit of around 4000 octets. > > Alan DeKok. > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
