OpenPGP Interim Feb 2023

time: 2023-02-09 12:00 UTC - 14:00 UTC

location: https://meetings.conf.meetecho.com/interim/?short=ba9363d0-0318-4c22-b3a7-f2037e345a02

Agenda

Excellent notes thanks to Neal Walfield.

dkg: Some of the issues have already been discussed on the mailing list.

stephen: If we finish up these issues, I hope that we can get the
document published fast.
dkg: conclusions need to be published to the list. If you have a clear
opinion, then it would be good to state that on the list.

• Signing

  Should the new key and signature formats change codepoint
  designations from v5 to v6? (this avoids collision with the v5
  codepoint which has seen some pre-specification deployment and could
  cause confusion in the wild)

    Should the fingerprint and signing octet for the new form also move from 0x9a to 0x9b? (v4's comparable octet is 0x99)
  
    MR that answers "yes" to both of the above: !231
  

dkg: Avoid conflict with draft-koch. At ietf 115, no one seemed happy,
but there wasn't a better solution and it will avoid some inter op
confusion.
dkg: identified a prefix that should also be changed
dkg: Should we also change pkesk and skesk to v6 too?
dkg: Seems to be consensus that this is a good idea.
dkg: Asks for comments about the MR.
jonathan: I shipped code that supports v5 (draft-koch) in onak. I have a
vested interest that we move to v6 for interoperability.
stephen: does anyone object to v6? if so, please say something now.
stephen: no one objects to using v6.
stephen: separately, does anyone object to moving pkesk and skesk to v6?

dkg: if we move those to v6, we'll need a new MR.
dkg: we need some positive confirmation
neal: I'm for moving to v6 and for the other two changes
dkg: It seems there are no objects. I'll make an MR for the changes.
stephen: We'll post the minutes to the list and then people can still
object there.
dkg: If someone else wants to do the MR, please do it.

Should hashed data for v5 signatures revert to a 4-octet length field? in -07 it is an 8-octet length field, which causes a risk of aliased data streams with v3 or v4 signatures, (see #130)
    MR that answers "yes" to the above: !220

dkg: Issue: Some v5 signatures can be misinterrupted as v3 signatures
due to the longer trailer. (Presents the issue.)
We don't know the consequence of this issue, but it doesn't seem like a
great property of a crypto system.
Proposal: revert from 8 octet to 4 octet width field (MR !220).
This is some reasoning in there that a >2^32 trailer len is not a
problem.
andrew gallagher: v5 signatures are already implemented in the wild. Can
we ensure that this aliasing won't be an issue with draft-koch or future
specs?
dkg: draft-koch signatures are indeed problematic. this is a good reason
to not use what people have implemented so far. But we can't fix that.
We can only fix the crypto-refresh.
andrew: can we make sure that v5, v6 and v7 are not aliasable.
dkg: draft-koch as currently specified won't be aliasable with the
crypto-refresh signatures. we can't stop people from implementing
whatever they want.
dkg: let's run a poll, as I'm not convinced that everyone understands
the issue fully.
dkg: I'm seeing hands raised in favor of the reversion; I'm not seeing
anyone not raising their hand.
dkg: We had 7 people raise their hand. Do we need another poll to ask
whether people understand the issue?
stephen: I understood it, and I think others did too. I don't think we
need another poll, but if anyone needs more information, they should say
something.
dkg: Ok, we got positive feedback on the poll. So, I'm going to move on.

Update signature salt size from 16 octets? (see #150)

    Should this be a uniform increase to 32 octets? or should it be bound to the hash function used?

    Should the size of the salt be indicated on the wire in the Signature packet?

    MR that answers "bound to the hash function used" and "indicated on the wire" to the above questions: !219

dkg: Aron's concern is that some PQ algos will want more than 16 bytes
of salt.
dkg: Justus wants to be able to parse the data even if he doesn't
understand the hash algorithm.
dkg: Should we specify a salt size?
dkg: I'd like to hear what people think. Should it be specified? Should
it be on the wire? What about the salt size for SHA-1 and MD5.
dkg: None of the packets have the salt size embedded in them.
falko strenzke: The simplest solution would be to make it 16 bytes.
dkg: We could just say don't do this for SHA-1 and MD5 and those
algorithms couldn't be used, which is what we want. Alternatively, we
could zero pad.
dkg: Is there a reason you want to do that and not say "not applicable"
to SHA-1 and MD5?
falko: No, that is also okay.
dkg: Are there any objections to changing the wire format at this stage?

stephen: I hope there would be a high bar to changing the wire format at
this stage.
dkg: We're changing the wire format anyways with the v5 to v6 change.
stephen: It's still pretty late.
justus: If we don't know the hash algorithm, then we don't know the size
if it is not on the wire.
stephen: your audio was pretty bad, I think you are in support of
changing the wire format.
dkg: justus: would you be willing to update the test suite?
stephen: justus said yes in the hash
dkg: daniel huigens is also in favor of the change (via chat)
stephen: I'm wary of the logic: if we change one thing then we can
change something else
stephen: dkg: can you please summarize what you've heard about the three
questions
dkg: people seems to be in favor of the size of the wire
dkg: people are in favor of rejecting sigs if the salt size does not
match what is on the wire
dkg: re depreated hash algorithms, andrew g said the algorithms should
have not applicable in the column
stephen: do people agree with andrew?
dkg: runs a poll: deprecated vs 16 octets: 6 for, 0 against
dkg: daniel h. volunteers to make an MR
dkg: that seems to be the way forward

Add Context parameter for signatures? Marcus Brinkmann's messages on this list provide examples of why a context parameter can be useful (see also #145)

    if so, how do we specify or register the context parameter for different use domains?

    MR that says "yes, add a context parameter" and "don't specify any specific context or set up a registry", and is also coupled to a context parameter for encryption: !214

dkg: Proposal by Marcus Brinkmann.
dkg: It is not clear to me if we want to include a context parameter or
not
daniel h.: For signing, technically it is possible to get the main
separation using notation data. We can use a critical notation that is
specific to an application. We have some support for that in our
implementations, but it is still a manual thing. It's possible, but it's
kind of a hacky solution. Also, no one is doing that at the moment. The
advantage of adding a context parameter in my mind is to encourage new
applications to use it. If we had a top-level context parameter in our
libraries, then it is quite obvious that it is something that you can
and should do whereas adding notations isn't. Of course we could add
more high level APIs for that using notation data. But it would be good
to encourage domain separation at the spec level.
dkg: Can you speak to how that would work with existing deployments. My
concern is that high-level API would encourage people to use it, but
existing applications won't be able to verify it.
daniel h.: I think it is very specific to each application. For email
there was a complete proposal to add a header. That was focused on
encryption, but could be used for signing.
dkg: The header will signal that it should be used for that message. But
there is also the question: should I use the context parameter?
daniel h.: if we build this parameter into v6 sigs, then you at least
will be able to know that the implementation has to support it.
dkg: What would be decided at the email level?
daniel h.: when sending a message to a v6 key, or making a v6 sig, you
would use this
dkg: the critical issue is that if you don't know the context parameter,
then you can't verify
daniel h.: for email it was a header that says what to put there
(sender, recipient, etc.).
dkg: you're describing a complex scheme. are you proposing to fold this
into this specification?
daniel h.: no, I'm saying this should be discussed in the context of
email and shouldn't go in this spec
dkg: I agree we don't want that in the spec
dkg: what should we do when sending a mail?
daniel h.: my point is that we should discuss this else where
dkg: if we roll this out, people have to do something and what should
then do
daniel h.: they can put the empty string
dkg: now there will be some emails without a context and some with
dkg: I'm asking: what context parameters will I know to include?
daniel h.: the application has to define it and if the application
doesn't say anything, then use the empty string
dkg: how do you know what to do?
daniel h.: once we define that this is a thing that you can do, email
applications will have to work to support that.
dkg: there are also archived messages
daniel h.: indeed. in the context of email, we could bind it to v6
dkg: so we can't use v6 with email until someone defines it?
stephen: I think we're going in circles. I understand that dkg is
hesitant.
neal: I agree with dkg and we should be conservative. we can also do it
with notations and the fact that is not part of the api is an api
problem and not a spec problem.
daniel h.: I don't think it makes sense to postpone this whole topic to
an email spec. My point was to postpone how we use it for email. I think
having a context parameter in the spec would be great. And it would be a
good

I'm gone for 5 minutes....

stephen: There's a tension between wanting it to stop cross protocol
attacks and knowing what to put in there.
stephen: other voices? it would be good to get more input on this.
andrew: We could have a third way between the two: we don't have to
specify the context. use the notation, but mangle the subpacket to make
the signature unreadable. it would need to be reconstructed before the
signature could be verified.
daniel h.: if you want to make it unreadable, you could put a hash of
the context data in the subpacket
jonathan: I'm not sure I really see the benefit of the context
subpacket. why couldn't this be a different type of notation flag, like
human readable for notation data
stephen: you just want an indicator for the context?
jonathan: I propose a new flag registry for the context. We're relying
on all applications to understand that signatures can only be used in
particular contexts. I don't see the value of a separate context
parameter.
daniel h.: The proposal is to get some crypto verification by adding
some context that goes into the hash of the signature. It can be as
simple as adding the name of the application.
falko: If I have a backup application that puts in a context parameter,
then when I verify the backup, I can't verify my own signatures on the
command line, right?
daniel h.: right, you have to pass the parameter somehow.
dkg: It indicates a significant API change to how signatures are made
and verified
dkg: I'm inclined to start a show of hands
stephen: there is a similar issue for encryption. should we discuss that
too? a lot of the issues are the same.
dkg: I can hold off on the poll.
stephen: Let's talk about encryption.

• Encryption

  Add Context parameter for encryption? (see #145)

    if so, how do we specify or register the context parameter for different use domains?
  
    MR that says "yes, add a context parameter" and "don't specify any specific context or set up a registry", and is also coupled to a context parameter for signatures: !214
  

dkg: Should encryption and decryption depend on a context, i.e.,
encryption and decryption depend on the same parameter.
decryption would fail if the decryption does not include the context.
daniel h.: for encryption there is no way to provide domain separation;
there is not an equivalent thing to the notation subpacket. We can't put
something in the additional data. And if you put something in the body,
there is no guarantee that someone else couldn't have encrypted a
message with that structure. For encryption, it is possible even more
important.
dkg: daniel, may be you could say something about greenfield vs.
non-greenfield.
daniel h.: it is the same situation as before, I think
neal: I'm deeply worried about the usability aspects. crypto is already
so hard to use.
dkg: can you give an example
neal: The example that falko gave before is exactly what I mean
daniel h.: I think we need to think about who OpenPGP is for. Is it for
applications? Or should it be used on the command line? I think that
currently, OpenPGP is maybe more focused on end users in that sense,
which I think makes it a poor fit for applications trying to use
applications. I think in the end if applications use OpenPGP and provide
users an interface, then the usability will be better. We shouldn't
expect users to verify a backup signature manually.
neal: I understand, but what about when applications disappear and I
still want to access my data.
falko: That is my concern as well. What if my backup application uses
the file names as the context and I lose that?
falko: For encryption, I support the idea of a context, it defeats some
attacks. But I think it should be something that is optional. I don't
think there is a solid way to introduce this parameter. A context
parameter that travels with the message would be a good idea.
justus: I'm also worried about the complexity this brings to existing
APIs, like gmime. We'd need to completely change how those APIs look.
stephen: Very roughly, I think what I've heard is daniel giving good
arguments, and some people pushing back for slightly different reasons.
Does someone want to argue for these parameters?
dkg: I could do two polls: add context to v6 sigs? to seipdv2?
stephen: Should we add the parameter now? (In this draft?) There are
some benefits, but introducing them is tricky. Or should we revisit
late? There is clearly some interest.
daniel h.: I think the question of how to introduce it is an application
question. I think that needs to be discussed in the context of email. If
we don't add it to the spec, we can't add it to email. I don't argee
that the order of things is to figure out how to make it usable and then
add it to the spec. But, we can add it to the spec and make it optional
for email and every existing application. Then new applications can use
it and later we can think about how to add it to email.
stephen: I would kind of agree, but adding context to email is hard, but
it is also hard in the general case.
dkg: I would agree that it is not solely an application layer question.
Existing applications need a signaling mechanism to indicate whether to
use a context. I'm inclined to say it should be in this spec. If you are
encrypting to a key, then that key can signal it.
daniel h.: If you are assuming that the key is only used by one
application, you don't need this separation. Advantage of domain
separation is the same key can be used by different applications.
neal: we actually have the key usage flags so it would be possible to
have one certificate and different keys per application.
justus: unintelligible
justus: have a notation in the subkey binding signature would also work

stephen: dkg, let's do the poll
jonathan: I'm not clear if the intent is to keep the data secret unless
you know the context, or just prevent an application from
decrypting/verifying something that was encrypted/signed in a different
context.
dkg: These context parameters were developed in the context of an
attacker munging the data.
jonathan: if there is no requirement for an ability to decryption, then
putting it in a notation would work
dkg: that works for signatures, but not encryption. the scenario is: an
attacker feeds you a message from a different context and your MUA does
horrible things with it. The paper was concerned with exfiltration of
clear text.
jonathan: That only works if we have a context for email and that is
going to be hard to specify. And if the application wants to protect
itself, it can do so without any help from the protocol.
dkg: two polls: add a context parameter to v6 sigs? to seipdv2?
stephen: should the WG revisit this topic?

discussion about what the poll questions should be

dkg: poll: Should we add a context parameter to v6 signatures in this
draft without any specification of its value?
dkg: 9 response, 2 for, 7 against
dkg: poll: Should we add a context parameter to SEIPDv2 encryption in
this draft without any specification of its value?
dkg: 9 responses, 2 for, 7 against
stephen: did anyone change their vote between the polls and want to
comment why?
stephen: poll: does the working group want to address context parameters
after 4880bis?
dkg: 9 for, 0 against
dkg: thanks for your feedback

Remove checksum and padding for v5 PKESK? This reduces the bytes on the wire at no loss of functionality as there is already a checksum in the key wrapping algorithm.
    MR that does this: !223

dkg: In the current approach for ecdh there is redundancy. Should we
remove it? Only impacts ECDH, not other algorithms.
dkg: This is another change on the wire. We have changes on the wire
anyway.
dkg: There is an MR, but the MR doesn't adjust the test vectors.
dkg: Does anyone have an opinion on this?
daniel h.: I'm not a huge fan of binding the algo specifics to the
version of the packet. But that said, I do like this. It is much closer
to using standard keywrap. We have aes keywrap implemented in web
crypto, which we could use with the new format, but not the existing
one. So that simplifies using it. So I would be in favor.
dkg: Thanks daniel.
justus: unintelligible audio.
dkg: I heard him say he was in favor of this change and likes the
simplification.
dkg: If we make this change, then all session keys need to be multiples
of 8 octets in the future. People should be aware of those consequences,
but I don't think they are dangerous. Should I do a poll, stephen?
dkg: poll: shall we simplify v6 ECDH PKESK keywrap input?
dkg: 5 for, 0 against. Fewer people are actively engaging, but no one is
objecting.
stephen: we're 90 minutes in, let's speed up

• Overall

  Guidance for Designated Expert? (see mailing list discussion and

  146). This doesn't have an MR yet, hopefully Stephen or i can make

  one before the interim. Do we want to suggest that Designated
  Experts be given substantial leeway, but advise that they follow the
  following guidance when considering a specification for the
  Specification Needed registrations:

    avoid codepoint squatting and vanity registrations
  
    require that the specification is concretely useful
  
    require that any registered algorithms meet the security requirements of the community and the message structures for which they are proposed to be used.
  

  Title of the specification? The current title ("OpenPGP Message
  Format") is unclear and confusing (see #144). This is trivial, so
  let's not bikeshed too hard. Some possible options are:
  OpenPGP
  OpenPGP Protocol
  OpenPGP Wire Format and Semantics
  OpenPGP Messages, Signatures, Keys, and Certificates
  OpenPGP Data Format

dkg: Last question: it's a bikeshedding question. I lean for just
OpenPGP.
stephen: Let's bikeshed on the list. I don't think it is worth audio
time.

• Administrivia

  Do we want to meet in Yokohama (IETF 116)?

dkg: If the changes are made as discussed, are we done with WGLC? Should
we pass the document to the wider ietf community?
dkg: Is there anything we are missing?
stephen: You mean anything that we need to address?
stephen: The plan will be trying to get paul to push out a new draft
with these changes, then have the WG check those, then the rest.
dkg: I want to remind folks that paul has little time. So it would be
good to offer him MRs, and step up to help, the easier it will be.
dkg: Should be meet at Yokohama?
stephen: IETF LC won't start before IETF 116.
stephen: We need to request the meeting slot by tomorrow. It seems there
is enough interest to recharter.
falko: I'd like to argue for meeting and addressing PQC. We have a draft
out, and as soon as the WG is done so far, it could be interesting to
turn to that. So far, we haven't received much feedback on the PQC
draft.
stephen: I don't want to disturb 4880bis.
stephen: If you have ideas for rechartering, send them to us privately
to avoid distrubing 4880bis.

neal: We didn't discuss the designated expert topic.
dkg: right, I posted a draft. It would be great if folks could weigh in
on that.
stephen: let's take this topic to the list.

daniel h.: Since michael brought it up in the chat: the other thing is
that Werner's new draft, that I think he published this week, rips out
eax. Purely from a perspective of differences between the drafts and if
we have to justify those differences, then it will be difficult to
justify all of those modes. On gcm, there's been some discussion, and
concrete reasons to put it in. For ocb, we discussed making that
mandatory to implement. I don't think we ever really discussed eax or
reasons for having it. I know it is very late in the process, but I'd
like to ask if we need it or if we should rip it out.
stephen: That's one to take to the list. It is late. Even if people have
good ideas at this point, but it may be too late.
stephen: That raises the possibility that the WG is DoSed, not saying
that Werner is trying to do that, but being reactive in that way could
have that effect.
dkg: I'm worried about terminating. But I agree that a simpler draft is
simpler to review. And a draft without eax is simpler. We have code
points that are reserved. If you think it is a good idea, it would be
good to have a clear merge request.
stephen: There's a real risk that we get stuck, and there should be a
high bar, even for deletions.
dkg: I don't want to spend two months arguing about this.
stephen: only propose to the list if you want to pursue this. we don't
want to not terminate. we already have a fork of the draft. we really
should finish.
daniel h.: if we want to do it, I'll do the work, but I won't do it if
we don't want to do it.
dkg: We should only propose changes that you strongly believe in. The
discussion should be fast.
stephen: if you don't believe in it, then I think we are done
daniel h.: the risk is that people are going to ask why we have 3 aead
modes
dkg: I don't think we'll get pushback. We have historical reasons for
having it. I don't think we'll get pushback.
stephen: if there is something that is important, bring it to the list,
but be aware of the risk of the WG never finishing.
dkg: please post to the list; show active participation, e.g., I read
it, I checked something, please weigh in. Having clear answers let's us
move forward.

• Overflow (if we have time)

  Other outstanding chartered work

  Collect list of unchartered work for consideration of a re-charter

Notes:

sftcd taking notes here, I plan to just record actions/decisions

• slide 6: decision: move to v6 (tbc on list)
• slide 7: poll - revert to 4 octets: 7 yes, 0 no

• slide 8: answers to questions on slide:

  • salt size - add to wire format: yes,
  • reject sig if mismatch
  • deprecated == n/a (poll: 6 yes 0 no)

• slide 9: poll: 7 no, 2 yes

• slide 10: poll: 7 no, 2 yes

  • 3rd poll: do something about context parameters post-4880bis: 9
    yes, 0 no

• slide 11: poll: 5 yes, 0 no

• slide 12: take to list
• slide 13: yes to 116 meeting