26th July 2023
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html
Problem statement: using keys securely is hard. Secure storage methods
are unsupported so people don't use them. Key storage is also complex.
Passphrase handling is bad, lots of ways to get it wrong. There are lots
of different considerations when working out how to use keys securely in
various scenarios (TPMs, platform Cert stores, files).
result: things aren't as secure as we'd want
This should be easy, applications should make it easy to use keys
securely.
Draft proposal: set out expectations for user experience, and what the
application should provide. Trying to encourage applications and crypto
libraries to improve.
Question - what should I do next?
Kathleen Moriarty (KM): Are you trying to change anything from PKCS#11?
David Woodhouse (DW) No.
KM: Good, because that's currently with OASIS.
Michael StJohns (MSJ): 95-98% of this is probably not in scope for the
IETF because we don't do APIs. The pieces about PKCS#1, PKCS#8 and
PCKS#12 are with LAMPS.
Eric Rescorla (EKR): Is the problem statement that application A
provides a certificate and application B wants to use it?
DW: Typically it's across applications.
EKR: I would like to suggest that this is an antipattern, and one
shouldn't do it. I resist the problem statement.
Daniel Khan Gilmour (DKG): Disagree with EKR, I've encountered many of
the problems you're describing in S/MIME. There's an interoperability
issue, it's a disaster. I think LAMPS would be a good place to work on
this.
Stephen Farrell (SF): Agree with DKG, including doing it in LAMPS. I
have a concern about how you keep it accurate with releases with various
libraries. Useful work.
Tim Hollebeek (TH): Not sure LAMPS is the right place. It's useful work,
think scope should be trimmed down. It should go somewhere. It feels
more like an application-type thing than a core PKIX thing, so not
LAMPS. However, the conversation could start in LAMPS.
SF: Give it to LAMPS and let them adopt it. It shouldn't come back to
SECDISPATCH.
Roman Danyliw (RD), SEC AD: Send it to LAMPS to refine the scope. ADs
will send it elsewhere if it doesn't fit there long term. It will likely
take a LAMPS recharter.
MSJ: I only think the PCKS#1, 8, 12 stuff should go to LAMPS. Not the
API stuff.
DKG: I think it's a mistake to say we don't do API work.
Decision: Dispatch to LAMPS
https://datatracker.ietf.org/doc/draft-nir-lamps-altcompsigs/
Alternate way to do hybrid signatures to the Mike Ounsworth LAMPS
drafts. Based on paper by Bindel and Hale. Has property of strong
non-separability (SNS) which is the property that an attacker can't turn
a hybrid signature into a solely traditional or solely PQ signature that
will verify correctly. SNS forces verifiers to verify both signatures.
The con of SNS is that you can't have backwards compatibility. Also,
there may be FIPS issues.
Question: LAMPS is not doing hybrid signature work, so where does this
go?
Bas Westerbaan (BW): Dilithium is not plain Fiat-Shamir, and the
construction in the draft is insecure because it doesn't do the
appropriate bounds checks. I think this is a bad idea because it goes to
the guts of the cryptography and makes mistakes. We shouldn't do it.
Mike Ounsworth (MO): Join the composite team, and figure out how this
work fits. There's a question of where these conversations fit, the
conversations about what properties we need in these signatures.
Yoav Nir (YN): I'm fine with joining the team. I do think this is a
property we need.
EKR: From what I can tell this is a potentially correct answer to the
wrong question. We shouldn't do hybrid signatures at all. The LAMPS work
is misguided.
YN: I'm not saying hybrid signatures are a good thing or a bad thing,
they might be a bad thing. If we're going to do them we should make both
signatures matter.
SF: Agree with EKR, I'm not convinced hybrid signatures are that useful.
I think the right dispatch decision is to wait a few years, and then, in
a few years, have a BoF.
YN: If we wait a few years we might be so comfortable with Dilithium
that we might not need hybrids.
TH: I think this is interesting work. I think it should be done faster
rather than slower, we should decide to not do it rather than take a
wait and see approach. I think it should go through CFRG.
Scott Fluhrer (SF): This draft takes two signature algorithms and welds
them together. CFRG has to review them. Either send it to CFRG or say
we're not going to work on it.
Jonathan Hoyland (JH): Is this the same as channel binding/compact
authentication? I feel this is a solved problem in the mathematical
sense?
YN: I don't think it's related to channel binding.
RD: It seems like this draft has some new crypto, which would need to go
through CFRG. There's also some representational stuff that fits in
LAMPS.
YN: I don't think there's that much, it's just about combining two
signatures.
John Gray (JG): Is non-separability an important property? The composite
sigs group is happy to look at it. Also, we're not giving up on the
composite signatures draft. There might be space for both drafts.
YN: I think there should only be one draft on composite signatures.
JG: I think it depends if you need that property.
Phillip Hallam-Baker (PHB): I think this is really interesting but I
can't think of a use for it. If I wanted to do this I'd put something in
the signature manifest to say "check both signatures". I think we should
wait on this for two years or so.
Peter Campbell (PC): Non-separable signatures require changes to the
component algorithms. This can lead to vulnerabilities, so if you take
the Dilithium and ECDSA construction in the draft it omits the rejection
sampling. Introducing the rejection sampling is not straightforward. So
if it is something people want to see it needs to go to CFRG.
Decision discussion
RD, Security AD: Definitely needs to go to CFRG, may then go to LAMPS.
Martin Thomson (MT): I overwhelmingly heard that we don't need this.
RD: I'm not denying there was pushback, but if the authors need a next
step, they should go to CFRG.
Chris Wood: While it seems reasonable to take this to CFRG, CFRG is
overloaded with a lot of documents, so if this isn't work that's wanted
or needed by the IETF it would be harmful for the group. Please talk to
CFRG chairs before going there.
Decision: Start in CFRG, and then when it's ready dispatch to LAMPS.
However, there is uncertainty about if this is wanted.
https://www.ietf.org/archive/id/draft-xu-ipsecme-risav-01.html
Site-to-site IPsec is great for security, privacy, interoperability etc.
To set up a site-to-site IPsec tunnel you need to do something like send
emails and share certs like that. We'd like to automate that process so
that we can scale site-to-site IPsec. Idea is to define a config format
equivalent to the emails, and then publish these configs in the RPKI
database. Then when participants sync the RPKI database they'd have the
configs to connect to all other participants. This is the core idea of
RISAV. Means that client IP addresses cannot be seen on the internet
backbone.
RISAV treats the internet as a "network of networks". Packet is mutated
as it leaves the source AS and reformed as it enters the destination AS.
SF: SAVE (?) used to be a thing. It had a bunch of downsides. Do those
problems apply here?
Ben Schwartz (BS): Can't speak to SAVE, but most previous proposals for
source address validation have been control plane solutions whereas this
is a data plane solution.
SF: Would like to know answers to those questions before giving a
dispatch answer.
John Scudder (JS): I think that your solution for the problem (RPKI) is
great. I'm concerned about deploying this at scale between ASs. The
volume of traffic passing between ASs is orders of magnitude greater
than in site-to-site IPsec. Also people would not be able to opt into
this process.
BS: To the second point, I think this preserves the end-to-end
principle.
Ted Hardie (TH): I think there's an operational piece to this, it would
require communication between customer and LAR to add a new piece to the
RPKI.
BS: To clarify, only for ASs.
TH: If you're saying only customers large enough to be ISPs can use
this, then it's a very different problem space. I don't think the use
case is written out quite right. For dispatch, go to NANOG or go to ARAN
(?) policy list.
Alex Chernyakhovsky (AC): I think this problem is poorly defined. The
users who would benefit from this do have to use a manual process but
they're not the ones with ASs. Come back with a clearer use case and how
we address some of the operational concerns. I don't think the added
encryption is better than the MASQUE tunnel of tunnels.
David Schinazi (DS): I think some things will melt here. Talk to the
operators, see what they think.
BS: We'd need to double the number of routers in the world. I'm fine
with that.
DS: Need to know the operators are fine with it.
EKR: This reminds me of the original vision of IPsec. This is
interesting to workshop but we need to know people want it.
Paul Wouters (PW), Security AD: There's a Routing Working Group, SAVNET.
If it should be dispatched anywhere it should be dispatched there.
BS: Probably out of charter
PW: We can propose this on the mailing list to see if it's in charter.
Dispatch Decision: New mailing list, SAVNET possible
https://datatracker.ietf.org/meeting/117/materials/slides-117-secdispatch-spiffe-for-ietf-00
There's a new mailing list: WIMSE for Workload Identity across Multi (?)
Systems Environments. Come and join it. We hope to do a BoF at IETF 118.
Not sure if that will be ART area or SEC area.
Out of time for this presentation.
RD: At the last meeting we said that we would be rotating the chairing
of SECDISPATCH. Kathleen will be stepping down after this meeting, thank
you very much!