Monday, July 26, 2021, 23:00-01:00 (+1) UTC
Chairs: Kathleen Moriarty, Richard Barnes, Mohit Sethi
Original at https://codimd.ietf.org/notes-ietf-111-secdispatch
Jabber: xmpp:secdispatch@jabber.ietf.org
Meetecho: https://meetings.conf.meetecho.com/ietf111/?group=secdispatch&short=&item=1
Showed the NOTE WELL.
No bases to the proposed agenda.
Link to mail post: https://mailarchive.ietf.org/arch/msg/secdispatch/ZQOQWCJKcdnVKH51eUP72QbTf1M/
Link to draft: https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update/
Note from author: ITS community is interested in producing an update to RFC 6353. NTCIP and ISO communities have requested the author reach out to the IETF to initiate a conversation on this topic.
EKR: Advocates a new WG and a standards-track output.
Rich: Advocates a full document instead of an update.
Roman: Where is the expertise in SNMP going to come from? We know where to find TLS expertise.
Richard: Can this be done in UTA?
Ben: Leaning toward tightly scoped new WG.
Roman: Maybe the OPS ADs can offer assistance about SNMP expertise.
OUTCOME: Either OPS or small focused SEC WG.
Link to mail post: https://mailarchive.ietf.org/arch/msg/secdispatch/DNHp1KsbDzzkNwO6aPp_PLeSIos/
Link to draft: https://datatracker.ietf.org/doc/draft-knodel-e2ee-definition/
Quetion from authors: Which WG is best to continue work on the draft?
PHB: Prefers LAMPS because it covers several protocol perspectives. Also, would like data at rest to be in scope too.
Mohit (no chair hat): A definition that is specific to MLS is much easier than a general definition that covers many protocol environments. SAAG is a better place to hold the general discussion.
EKR: A definition is helpful. Example to TLS session to Google is not the “ends” for the Gmail application. Does not quite fit in an existing group.
Richard: Need to include the different layers.
Roman: If it is not specific to a protocol, then it probably needs to be AD sponsored.
Ben: More discussion to determine the scope is needed. Basically agree with Roman.
OUTCOME: Set up a mail list to further the discussion.
Link to mail post: https://mailarchive.ietf.org/arch/msg/secdispatch/FlVfg8uiZcw4cIMUGzj-iGVx5J4/
Link to draft: https://datatracker.ietf.org/doc/draft-henry-ft-owe/
Richard: Seems like IEEE 802.11 would be a better home.
Dan: IEEE 802.11 did not want to do the OWE work that became RFC 8110.
EKR: Suggests liaison with IEEE 802.11 as the first step.
Bob Moskowitz: {poor audio}
Roman: Agree with starting with a liaison statement.
OUTCOME: Start with liaison with IEEE 802.11.
Link to mail post: https://mailarchive.ietf.org/arch/msg/secdispatch/tS_8Zfh3EYhbz4A-ZBMpDzHRvuU/
Link to draft: https://datatracker.ietf.org/doc/draft-struik-secdispatch-verify-friendly-ecdsa/
Note from authors: Discussed this with lamps at IETF-110 but
despite positive feedback lamps did not include this with their recent re-charter yet. The simple technique is broader than just lamps, though, and should be beneficial for any deployment (certificate transparency, openpgp, pkix, etc.). Lamps would be a good starting point.
PHB: Suggest CFRG.
Rene: Batch signature verification of 6x if public key the same. Less if just the same curve.
DKG: Suggest CFRG before being used in protocols.
Rich: Suggest CFRG review.
Richard: Suggest CFRG review before any codepoints are assigned.
Roman: Agree with Richard.
OUTCOME: CFRG review before any codepoints are assigned.
Link to mail post: https://mailarchive.ietf.org/arch/msg/secdispatch/0kxStuDPR_SW8f1K1OJpsQCioMY/
Link to draft: https://datatracker.ietf.org/doc/draft-jordan-jws-ct/
Question from authors: What direction would be best for this work in the IETF?
OUTCOME: ISE