Hi Deb,
On 9/2/25, 4:54 AM, "Deb Cooley via Datatracker" <[email protected]> wrote:
Deb Cooley has entered the following ballot position for
draft-ietf-emu-bootstrapped-tls-08: No Objection
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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NpxR!nodWFNbSD0KgYcavuVVK5XMx7bbs-zZYyFJFWXAsiBc_r4xZr2F6c_56zehzT0bBddPXT0UTnNd9z2Ye$
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-emu-bootstrapped-tls/__;!!NpxR!nodWFNbSD0KgYcavuVVK5XMx7bbs-zZYyFJFWXAsiBc_r4xZr2F6c_56zehzT0bBddPXT0UTnIc4aA6Q$
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Finally a specification I understand! :^)
While these comments are non-blocking, I'd like to see them addressed.
Section 1.4: NAI? [I'd add this to Section 1.1
Done, there was a similar comment received on this.
Section 6, third bullet: SHA-256 is very suitable for this function in the
foreseeable future (to address the review comment). ECDSA for
authentication
will need to be replaced when CRQCs are readily available (i.e. attack in
real
time is possible). - no change requested for either.
Yes, but given that the largest prime number a QC has factored as of today is,
I believe, 21 (not 21 bits, the number 21) I think this draft will live a long
life before the required changes is necessary. But noted.
Section 6 or 7: I would add, 'The BSK public key MUST NOT be freely
available
on the network'. Trust for this method is completely dependent on this,
stating this early and often isn't a bad thing.
Good point.
Section 7: The compressed ECDSA key pair needs to be correctly generated
and
validated. I think this could be a simple statement with a reference to FIPS
186-5, section 6.2, while RFC 5480 covers compressed points.
We are not specifying compressed ECDSA, it uses compressed ECDH. That said, we
should be referencing RFC 6090.
Normative References: You also need a reference for ECDSA and generation of
key pairs. Possibly:
https://urldefense.com/v3/__https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf__;!!NpxR!nodWFNbSD0KgYcavuVVK5XMx7bbs-zZYyFJFWXAsiBc_r4xZr2F6c_56zehzT0bBddPXT0UTnD8CMBnd$
Normative References: You need a reference for ECDSA w/ compressed points.
Possibly: RFC5480 (I don't think RFC 8813 covers this part).
I think RFC 6090 should suffice. Please let us know if that doesn't address
your comment.
regards,
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
_______________________________________________
Emu mailing list -- [email protected]
To unsubscribe send an email to [email protected]
