My replies with [DC] inline below. On Wed, Sep 3, 2025 at 1:31 AM Harkins, Dan <[email protected]> wrote:
> > 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. > [DC] yeah, yeah... but that will happen before SHA-256 is a problem. > > 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. > [DC] I did a quick check of the draft and there are literally no references to ECDH, only ECDSA. So..... either I'm right, or you are. If you are right, there are bigger changes required. > > 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. > [DC] see above... > > 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]
