done: https://github.com/tlswg/tls13-spec/issues/1219
On Tue, Feb 23, 2021 at 4:36 PM Christopher Wood <c...@heapingbits.net> wrote: > Thanks, Martin! Perhaps we can file an issue and track this as part of > rfc8446bis? > > https://github.com/tlswg/tls13-spec/issues > > Best, > Chris > > On Tue, Feb 23, 2021, at 4:32 PM, Martin Duke wrote: > > 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
