LAMPS Session at IETF 103 Tuesday, 6 November 2018 at 9:00 Minutes from notes taken by Rich Salz Executive Summary RFC-6844bis has been sent to IESG. The hash of root key cert draft is in Working Group Last Call. The shakes documents continue to progress, and it was recommended that KMAC-based deterministic ECDSA work be moved to CFRG. The CMS hash signature document is waiting for the McGrew hash signature document to get to the RFC editor queue. Please review the CMS mix with PSK document as it is close to last call. The X.509 hash signatures document has been forwarded to LAMPS by secdispatch (requires re-charter). Whether Alexey's e-mail header protection document should also be adopted via re-charter will also be discussed on the list. 0) Minute Taker, Jabber Scribe, Bluesheets Participants were reminded about the NOTE WELL. 1) Agenda Bash No agenda changes. 2) Documents in WG Last Call a) draft-ietf-lamps-rfc6844bis (Jacob and Phillip) Comments received on the list shortly before the meeting were incorporated into the draft the day before the meeting. The updated draft has been sent to the IESG. b) draft-ietf-lamps-hash-of-root-key-cert-extn (Russ) The document is current in Working Group Last Call; the last call ends on 12 November. Please review the document and comment on the list. 3) Active Working Group Documents a) draft-ietf-lamps-pkix-shake (Panos and Quynh) b) draft-ietf-lamps-cms-shakes (Quynh and Panos) A number of updates were made to the draft based on Jim's comments on the list: - KMAC not HMAC - MGF1 function - updated the IANA section - added security considerations - fixed various nits The chairs consulted with CFRG on the MGF1 function change, and CFRG agreed it was reasonable. There was a discussion about the "k" value in deterministic ECDSA. Eric Rescorla objected to "patching" deterministic ECDSA to use KMAC as part of this document, as modifying ECDSA is CFRG's responsibility, and is outside of LAMPS' jurisdiction. While it would be useful to have a version of ECDSA that uses KMAC, such an construction would be more generally useful in IETF standards, and should be examined by CFRG for possible problems. Stanislav offered to work with CFRG to get KMAC-based deterministic ECDSA into a separate RFC 6979-bis. Once that is approved, the reference to RFC 6979 will allow it to be used in this document. The use of KMAC tags less than 256 bits was discussed. The issue was dropped due to lack of interested in implementing such tags. c) draft-ietf-lamps-cms-hash-sig (Russ) The draft was updated to address comments on the list. Russ believes the document is ready for Working Group Last Call once the McGrew hash signatures document (draft-mcgrew-hash-sigs) gets into the RFC editor queue. d) draft-ietf-lamps-cms-mix-with-psk (Russ) The draft allows a pre-shared key (PSK) to be mixed into CMS messages to prevent future decryption of messages by an attacker who can break asymmetric encryption (for example, with a quantum computer) but does not have access to the pre-shared key. Privacy is not worse because there are already equivalent ways to identify that two messages have the same recipient (by using the key identifiers of the recipients). Eric Rescorla pointed out it is also possible to determine that two messages have the same sender, but this is not a blocker for adoption. The document is close to Working Group Last Call, please review and comment on the list. 4) Other Business (if time allows) a) draft-vangeest-x509-hash-sigs (Daniel) As with draft-ietf-lamps-cms-hash-sig, the primary use case is certificates for code signing. The draft allows use of hash signatures in X.509 certificates. The primary use case is code signing certificates used for secure software update, where the size of the signature is less of a drawback, and where it is very important that software updates can be delivered securely in the future even with the potential existence of quantum computers. The draft closely parallels draft-ietf-lamps-cms-hash-sig, and the author intends to keep it updated so the drafts are aligned. The draft is being sent to secdispatch, where it is anticipated it might be sent to LAMPS (Note: this did in fact happen the following day, and will require a re-charter). The draft was discussed at this LAMPS meeting to accelerate the path to possible adoption. 5) Wrap Up Russ mentioned potentially re-chartering to adopt Alexey's e-mail header protection document. Eric Rescorla asked if the group was interested in working on the draft, and whether people would implement it. Daniel Gillmor mentioned that he has had conversations with potential implementors and will get them to post their agreement to the list. The next step is to discuss potential charter text on the list. Progress on the draft can happen in parallel with the re-chartering effort.