After further consideration, the problem at hand is best resolved by 8446, which has a generalized problem with subfield lengths that don't add up to the field length. I will remove the DISCUSS
Nevertheless, here's a PR that may help implementers avoid a problem: https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/41 On Tue, Jan 19, 2021 at 10:40 AM Martin Duke <martin.h.d...@gmail.com> wrote: > Ekr, > > I appreciate that this is hard to represent in 8446 notation. Would it be > possible to add some text in 4.1 that says "Due to the maximum size of the > PSK extension, the external_identity and context fields MUST sum to a > length of 2^16-5", or something to that effect? > > IMO, it would be unfortunate if the PSK Importer interface allowed > parameters that result in undefined behavior on the wire. > > If this is unworkable or very very dumb for some other reason, I am > willing to accept that feedback. > > Martin > > On Thu, Jan 7, 2021 at 4:57 PM Eric Rescorla <e...@rtfm.com> wrote: > >> >> >> On Thu, Jan 7, 2021 at 4:39 PM Benjamin Kaduk <ka...@mit.edu> wrote: >> >>> On Mon, Jan 04, 2021 at 03:40:34PM -0800, Martin Duke via Datatracker >>> wrote: >>> > Martin Duke has entered the following ballot position for >>> > draft-ietf-tls-external-psk-importer-06: Discuss >>> > >>> > When responding, please keep the subject line intact and reply to all >>> > email addresses included in the To and CC lines. (Feel free to cut this >>> > introductory paragraph, however.) >>> > >>> > >>> > Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>> > for more information about IESG DISCUSS and COMMENT positions. >>> > >>> > >>> > The document, along with other ballot positions, can be found here: >>> > https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/ >>> > >>> > >>> > >>> > ---------------------------------------------------------------------- >>> > DISCUSS: >>> > ---------------------------------------------------------------------- >>> > >>> > This is probably just my own ignorance, but I see two potential >>> problems in Sec >>> > 4.1. >>> > >>> > - 'The identity of "ipskx" as sent on the wire is ImportedIdentity, >>> i.e., the >>> > serialized content of ImportedIdentity is used as the content of >>> > PskIdentity.identity in the PSK extension.' IIUC ImportedIdentity has >>> a maximum >>> > length of 2^17 + 2. But the Identity field in the PSK option has a >>> maximum >>> > length of 2^16-1. I presume this never actually happens, but the spec >>> should >>> > handle the boundary condition, perhaps by limiting the first two >>> fields of >>> > Imported Identity to sum to 2^16-5 bytes or something. >>> >>> I'll leave this one for the authors. >>> >> >> I can see how someone would want this, but in practice that's not how it's >> generally done in TLS. Trying to compute the precise upper bounds gets >> complicated very fast when there are multiple fields. We do generally >> try to get the lower bound right, though even then there have been >> mistakes: >> >> https://github.com/ekr/tls13-spec/pull/56/files >> >> -Ekr >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
