(again not quoting the text that was accompanied by a no-derived-works disclaimer)
For my present purposes of getting a general sense of the trend, I don't really care if we assume 5000 bytes/second full-duplex or half-duplex, though my understanding is that this type of unit has a single radio module that functions as half-duplex. Thanks for reframing the numbers to the smaller-scoped system. Keygen times on the order of tenths of seconds may need closer analysis (and a non-straw-man use-case) to really assess, if we're in a domain that only has single- or two-digit numbers of seconds to achieve the entire higher-level protocol action (over multiple round trips, etc). And I assume that the bit where ML-KEM-768 is approximately 3% faster than X25519 plus ML-KDM-768 is for a microbenchmark scenario where we are just doing key exchanges and nothing else, so may end up in the noise for some traffic patterns (but for an application protocol that's just a one-shot request/response using small messages, might not be in the noise). I 100% agree that there's a difference between having tangible use-cases for which a protocol proposal provides clear benefit and hand-waving about constrained devices. I do think that constrained devices have several more axes of "cost" to consider than are in play for the vast majority of devices participating in the Web ecosystem, such as code footprint, but those different axes of "cost" do not obviate the proposer of a protocol mechanism from demonstrating that there is benefit along one or more such axes from the proposal. This ties back to my own review comment on the draft, in that the draft does nothing to discuss the tradeoffs of hybrid vs non-hybrid or give some justification for what secnario(s) might prompt someone to prefer the non-hybrid ML-KEM. John should be fairly well-posititioned to bring in some concrete constrained-device use cases that would inform a more precise analysis, if he wants to pursue constrained devices as an example use case that would justify this protocol mechanism. (I am not.) Thanks, Ben _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
