Minutes IETF114: secdispatch
minutes-114-secdispatch-00

SecDispatch @ IETF 114
======================

10:00 - 11:00   Tuesday Session I (60 minutes)

1. Logistics and introduction (chairs, 5 min)

# 2. Dispatch items
-----------------
(Each item is 15 minutes including discussion unless otherwise noted)

Post-Quantum Terminology
------------------------
(a) Terminology for Post-Quantum Hybrids (15 minutes)
draft:  https://datatracker.ietf.org/doc/draft-driscoll-pqt-hybrid-terminology/
presenter: Florence Driscoll

Consistent terminology is security critical, to make sure we have a common
understanding of what we're talking about. A recurring discussion topic is
"composite" vs "non-composite", but we haven't yet nailed down what we actually
mean. Likewise for "hybrid authentication".  (For extra confusion, "hybrid" is
already used in e.g., HPKE.)

Possible options:
- new PQ WG
- CFRG
- LAMPS
- AD sponsored

Paul Hofman: Single draft for key exchange and signatures?  We need to have
hybrids for both, but will have a terminology mismatch.  Do KE first,
signatures next.

EKR: How much is the research community converging on terminology?
A: NIST is defining some, just in their FAQ.
IETF seems to be only community concered about "hybrid".
There are also IETF-specific considerations.
(AD-sponsored doesn't give the review we need)
-> CFRG or a new WG if we had one, probably.

Barry Leiba: What EKR said; didn't work well in ISO, definitely not an
AD-sponsorship item; might put other terminology stuff into a new WG

Sofia Celi: thanks for this, it's great.  Re research community, not much of a
unification of terminology.  Varies some, most consistency from key-exchange
documents from NIST.  I also think separate documents for key-exchange and
signature would make sense.  (NIST recommends "dual" for signatures.)  ??? or a
PQ group may be created.

Daniel K Gilmore: new group probably best; CFRG is congested. Like separate
drafts for KE and Signature.  The technology is different.

Richard Barnes -> DKG: Other items for this WG?
DKG: Something curdle-ish, how to incorporate this stuff into other protocols.

PHB: Another group is probably best. People building stuff are going to want to
know what to call things. CFRG do algorithm stuff, but algorithm and
cryptographic stuff are not the same as wire protocols. When you're trying to
discuss things, that's where we will need terminology.

Kathleen: hear a lot of "new WG", some CFRG, some in the chat that CFRG is not
quite right.

Roman: Talk to CFRG. We need to find a suitable place to land this.

Richard Barnes: Either it needs to land in a dedicated group, or in CFRG.

Roman: Thanks for bringing this work here

Federated TLS Authentication
----------------------------

(b) Federated TLS Authentication (10 minutes + 5 minutes discussion)
draft:  https://datatracker.ietf.org/doc/draft-halen-fed-tls-auth
presenter: Stefan Halén

Stefan gives overview of the motivation of FedTLS. Uses cases are the education
and health secort. This is needed for secure data transfer. There are open
standards, and implementations of this. Steady increase in up-take, along with
identity mechanisms. Probably see an even bigger uptake if this were to be
adopted by IETF.

Overview of operation, by way of an example. Client and server pull others
details from a local MD, which in turn pull from the central federation
metadata.

EKR: Clarifying question: Why is the proxy verifying the client's trust chain?
Stefan: The proxy doesn't *need* to do that.

Stefan: Asks for any questions? Where should we dispatch this to?

EKR: Doesn't sound like there's a lot of other people doing this. You can do
this with no RFC at all? You can register information about your scheme without
this.

Stephen Farrell: I admit not having read the draft. I don't enough information
to recommend a dispatch outcome.

Brendan Moran: a quick question: do the machines in the machine-to-machine need
to parse the federation metadata?

Stefan: yes

Brendan: why JSON?  If you need this to be processed by constrained nodes, use
something more suitable for constrained nodes, like CBOR.

Mike O: carrying over from mailing list.  Clearly there's a need for this,
solves a real problem, but it wasn't clear that there's enough companies doing
this that you need a real standard.  Why need IETF standardization?

Stefan: we're running federation for the health sector.  To get them to raise
funds for this, you'd need a standard.

Kathleen: queue wrapping up.  Sounds like not much interest, you might be able
to do this without any further IETF involvement.  (Authors,) did you get what
you needed?

Stefan: I will try to add more text to the document to present a stronger case
for what we're doing.

The FNV Non-Cryptographic Hash Algorithm
----------------------------------------

(c) The FNV Non-Cryptographic Hash Algorithm
draft:  https://www.ietf.org/archive/id/draft-eastlake-fnv-18.txt
presenter: Donald Eastlake

The purpose of this is to provide a stable reference document, and also a
reference C implementation. [description of operation of hash]

This hash is used widely: IEEE standard 802.1Qbp-2014, RFC 7357 and RFC 7873.
It's also deployed by Twitter, database index hashing, major web
search/indexing engines, and many more.

Next steps: Donald suggest the SECDISPATCH recommend AD sponsorship.

Paul Wouters: I don't mind AD sponsoring if you can't find a home for it,
although the latter would be my preference.

EKR: to clarify, you're just taking a fixed algorithm and writing it down.
We're not reviewing it or changing it in any way? Also isn't it already in an
IEEE document?

Donald: Yes, but only one form of the hash, and it's buried deep within it?

EKR: I think this should go within ISE

Paul Hoffman: I think the fact that this is already referenced in other,
standards-track, IETF documents makes it innapropriate for ISE.

EKR: I guess my point is about consensus. IETF docs must have consensus. I'm
not sure why we'd get that here.

Donald: We'd probably put stuff in security considerations.

PHB: This would need *a lot* of description in the Security Considerations
about when/where it is [in]appropriate to use this. Also I have an IPR things
about this. There was someone claiming to own the idea of using a cryptographic
hash for non-cryptographic purposes.

Donald: the authors have tried very hard to ensure there are no IPR problems.

Kathleen: I see no reason not to do this via AD sponsorship

Ted Hardie: I just wanted to clarify: I took from what you (Paul H) were saying
that the ISE have rejected this. Given that this is going for informational
anyway, there's no request for substantive review, the ISE is the best place
for this.

Dan Harkins: Does this offer anything over, say, MD5?

Donald: I don't want this to descend into a comparison of hash functions

Paul: I think AD sponsorship sounds like the best route.

Richard Barnes: It seems like there's a split over whether AD sponsorship or
ISE is appropriate

Roman: What we're saying is that we should say AD sponsorship for now.

# 3. Chair summary/session results readout (5 minutes)

Richard summarizes the dispatch decisions.

# 4. Open mic (5 minutes)
Stephen Farrell: I think secdispatch isn't working as well as hoped. I'm not
sure the summaries affected any decisions. I think some of these should have
gone to the TLS mailing list (? is that right?)

DKG: I have a 'dangerous labels' draft giving DNS labels that you'd be
surprised people might be able to register in your zones. Also email address
local-parts. I have no idea where this lands. 'MTA-STS' is an example.
Basically a wall of shame, to divert people to things like .well-known. But
I've got no idea where this should go in the IETF.

Richard Barnes: Probably a good thing to bring up on the list.

---

# Security Area Advisory Group (SAAG)
IETF 114 - Philadelphia, Room: Liberty D

11:00 - 12:00   Tuesday Session I (60 minutes)
(may start earlier pending completion of SecDispatch agenda)

## 1. Welcome, Administrivia, and Agenda Bashing (5 mins)

Note-well [still] applies. Going to talk about the possibility of a new PQ
group.

If you'd like to volunteer as a WG chair, then reach out to us. Then we have a
list we can go to when a new WG gets formed.

Also, a request for document shepherds. It's a good thing for a newcomer to do.
Ask you AD if shepherding is right for you!

Finally, errata harvesting is important.

Richard Barnes: Thank you for developing talent in our area. If you and your
co-chair are both experienced, then I think you're doing it wrong. Good to
bring up new chairs.

## 2. WG Reports (10 mins, chairs)

ACME: Yoav: We've got a number of documents coming through. Some about to go
through WGLC MLS: Sean Turner: protocol and architecture draft have gone
through WGLC. Good to go! OHAI: Shivan: think we're almost ready to go with the
main protocol draft. About to hit WGLC PPM: Sam: got a few people looking at
our drafts. Would love a few more people to look at it.

Security BoFs at IETF114:
JWP, SCITT and SATP.

Barry Leiba, chair of DMARC. Issues around correct org domain where we are
replacing use of public suffix list. A lot of controversy on the list.

Sam Weiler: TIGRESS WG has obviously security implications, despite being in
ART. Roman: for those who have been following along, TIGRESS came from the
SECRET BoF. It's going to remain in ART, but have a SEC AD.

Valery Smyslov (co-chair of UTA): There's an error in the chair slides: UTA WG
status seems to be copy-pasted from TLS WG status.

Bob Moskowitz: DRIP draft is in WGLC. Would like to get to LC in the WG.

Dave Thaler: In the RATS WG there was a presention from Carl about formats for
configuring a trust anchor store. RATS would make use of this. But other WGs,
including SUIT and TEEP might also want to make use of it. Maybe it should come
to secdispatch at some point in the future.

Roman: There's talk about MIMI in the chat - does someone want to talk about it?

## 3. AD Report (15 mins, ADs)

Slide 33
Understand where ADs are, Slide 34, including common AD review issues.
WG life cycle: Slide 35; e.g., SACM closed last week.

pqc mailing list has just been created - please use that for pqc-related
discussions.

Work on errata, in particular for documents that no longer have open WG (Slide
38); looking for volunteers Started hilighting that last time, and we are
actually losing ground.

Paul Hoffman: Implementers often wish that there were errata reported.

Barry Leiba: Any new errata that are purely editorial wil be handled by RFC
editor.

## 4. Open Mic (remaining time)

Roman: What is the threshold we want to set for a PQ WG: we had a conversation
at IETF111. Result was that open WGs would be available to think about issues.
What we didn't think about was PQ maintenance in protocols without open WGs. So
proposal was a WG for the 'orphan' protocols. Concern that there might not be
enough expertise in such a WG. Also concern about what the first protocols
would be to be considered. And also without NIST having made progress, it
wasn't clear where to go with it.

The threshold for having such a PQ group is somewhere to discuss suitable
terminology around these issues. Discuss! EKR: This was the concept behind
CURDLE. I think this may be premature. We got the recommendations from NIST a
few weeks ago. maybe we should try to work on protocols we have WGs for, and
then learn lessons from that. Trying to do them all at once may not be what we
want. Roman: there's the maintenance piece, and there's also having a place to
have conversations around terminology and framework. EKR: I'm wary of creating
another group. Mike Ounsworth: a plug for centralisation: all protocols are
going to grapple with similar problems. Why don't we have that discussion
*once* in the same WG. There's going to be protocols that will get
forgotten/not-have-a-home. We need a place to look at that. PHB: I don't
understand PQ. From the point of view of "how do we apply them to a protocol",
I don't think we have that knowledge yet. PKI is not the same as PKC. It's
going to be the same with PQC. It's like IRTF - we need to educate, and
generally level-up. We're going to have people bringing in what they developed
in their basement and showing it off. The good news is I've got a degree in
nuclear physics. I am not worried about a quantum computer arriving in the next
five years. I don't think we have to do this on an emergency basis. Michael
Richardson: I largely agree with others, that we don't need to build a group
for orphaned protocols. We need to get on and do the transition for protocols
with open WGs. Maybe uplift those orphans to TLS? That would solve things. I
don't feel confident we know where we're going with certificates. Data-at-rest
problem is very different from the tls/ipsec problem. We can do these in either
order. Certificate/data-at-rest is the priority for me. Scott Fluhrer. I would
like to disagree with the idea that we shouldn't start now. Might be 8 months
before we have a WG... This could take up a lot of time. Deployment is even
worse. I would recommend starting a BoF at next IETF. Paul Hoffman: Many people
in the room might remember Hilary Orman, who wrote a draft about when we might
need to worry about Quantum computers. I then wrote a document about DNS. I'm
simply plugging those now for those who are talking about *when* such a
computer might come about. Come talk to me, or look at Hilary's document. NIST
have punted signatures down the road. If you want to do *something* now, then
look at KEMs. Sofia Celi: to comment on some of the other comments: about the
need to migrate - a quantum computer won't be created tomorrow, but someone
could be storing encrypted traffic to decrypt when one exists. I really like
some of the comments that state that this isn't about just the cryptography
itself, but how it fits into algorithms. If IETF just standardise the same
algoirthms that NIST have stnadardised, we won't really be doing anything. It's
about trying to fit them in to the protocols. As someone before me said, "we
shouldn't be repeating what one WG is doing in another". This might be more
related to research, but also applying research. Florence D: I'm going to agree
with a lot of what Sofia said. I think there's value in a central place to have
these discussions. Details about how a specific protocol e.g. tls or ipsec
should work belong to those WGs. but there is value in central discussion.
Bringing cryptogrpahic and protocol expertise together is important. John Gray:
from Entrust. We've been considering this for many years. Putting on my
customer-hat, we've been prototyping PQ algorithms, especially signatures. I
don't think this can wait any longer. It comes up weekly for us. We've already
implemented certificates, and had cusomters wanting to use them Russ Housley:
We thought the transition from SHA1 would take 5 years. This is much bigger and
more pervasive. We have to worry about traffic recorded today and broken by a
future quantum computer. Let's get started - it's going to take a long time.
EKR: A few points: first, the signature stuff isn't ready. The best we can do
is get the key exchange stuff okay. The sizes of signatures are gooing to be a
big problem. We've been sending this data for 20 years. My argument is not that
we should do nothing. it's that we have a limited ability in this organisation
to solve the problem once, or twice, before we generalise. In TLS we've got
quite far due to people like Doug Stebila. If people want to form a WG to do
this, that's up to them. But I don't want to hold up work in TLS or LAMPS.

[Closes queue, moving to rest of Open Mic about more general topics.]
No takers for Open Mic.