Minutes IETF103: lamps
minutes-103-lamps-00

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.