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. - It says 'Endpoints SHOULD generate a compatible "ipskx" for each target ciphersuite they offer.' but then the example shows two ciphers that equire only one derived key. Do you mean "hash algorithm" instead of "ciphersuite"? TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are different ciphersuites according to RFC 8446. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
