IETF
openpgp
openpgp@jabber.ietf.org
Friday, July 29, 2022< ^ >
Meetecho has set the subject to: OpenPGP @ IETF 112
Room Configuration
Room Occupants

GMT+0
[01:45:47] xcrypt1210 joins the room
[02:21:43] xcrypt1210 leaves the room
[12:37:02] xcrypt1210 joins the room
[12:52:56] xcrypt1210 leaves the room
[13:03:19] xcrypt1210 joins the room
[13:12:06] gniibe joins the room
[13:12:32] vanitasvitae leaves the room
[13:42:26] dkg joins the room
[13:42:38] <dkg> hi everyone!
[13:42:59] <dkg> we've got ~~18 minutes until the session starts here.
[13:49:39] justus joins the room
[13:50:27] <justus> o/
[13:57:13] <zulipbot> (Justus Winter) dkg: ftr, your mic is hot
[14:07:11] <zulipbot> (Quynh Dang) Hi chairs, the volume is very low at my end. Quynh.
[14:07:11] <zulipbot> (Stephen Farrell) please join the queue if you'd like to speak to an issue whether remote or local (but we're not a huge crowd so we can probably manage even if you don't)
[14:07:34] <zulipbot> (Justus Winter) yes
[14:07:47] <zulipbot> (Quynh Dang) yes. thank you.
[14:11:38] <zulipbot> (Justus Winter) I'm keen on random
[14:13:18] <zulipbot> (Justus Winter) About the procedure, the design team members have often expressed their opinions in the tracker, and I feel like repeating them here doesn't add anything new.  What should we do?
[14:13:53] <zulipbot> (Justus Winter) ok
[14:15:10] <zulipbot> (Justus Winter) If removing the rationale helps, I'm fine with that
[14:17:00] <zulipbot> (Daniel Huigens) 👍
[14:20:50] <zulipbot> (Benjamin Kaduk) It must be exciting to "push the red button"
[14:22:28] <dkg> Quynh, can you enable your own audio?
[14:22:51] <zulipbot> (Stephen Farrell) @quynh go ahead or do you have audio issues?
[14:23:07] <zulipbot> (Quynh Dang) I can go now.
[14:24:45] <zulipbot> (Benjamin Kaduk) I expect/hope that Quynh is speaking to the FIPS requirements regarding encryption modes
[14:30:50] <zulipbot> (Justus Winter) Quynh: your mic is still hot
[14:31:03] <zulipbot> (Justus Winter) nvm
[14:31:29] <zulipbot> (Quynh Dang) thank you Justus.
[14:31:43] <zulipbot> (Phillip Hallam-Baker) Yeah, stuff happens. If you do it in the RFC, can write security considerations
[14:33:21] <zulipbot> (Roman Danyliw) The desire on GCM is pretty clear
[14:38:55] xcrypt1210 leaves the room
[14:44:55] xcrypt1210 joins the room
[14:47:38] <zulipbot> (Benjamin Kaduk) Thanks Justus!  I am now more strongly in favor of keeping things in a direct key signature :)
[14:57:41] <zulipbot> (Justus Winter) the designated revoker's key can also be distributed in the revocation signature
[14:57:54] <zulipbot> (Justus Winter) so that it doesn't have to be carried around in the cert
[14:58:07] <zulipbot> (Justus Winter) so you only pay the price if the revocation actually happens
[14:58:20] <zulipbot> (Justus Winter) nevertheless, that scheme has to be specified
[15:00:21] <zulipbot> (Andrew Gallagher) I don't see what advantages designated revokers have over escrow
[15:02:35] <zulipbot> (Justus Winter) I think there are two advantages, first it fits corporate workflows well (think someone leaving a company)
[15:03:01] <zulipbot> (Roman Danyliw) I believe the COSE reference Ben is explaining is https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/
[15:03:14] <zulipbot> (Justus Winter) second, you can be more precise in the time and reason for the revocation
[15:03:48] <zulipbot> (Justus Winter) (if you escrow, you can escrow a bunch of time X reason revocation certificates, but that will always be imprecise)
[15:04:15] <zulipbot> (Stephen Farrell) thanks roman (and ben)
[15:04:54] <zulipbot> (Benjamin Kaduk) On guidance to IANA designated experts, I like https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-algs-12#section-10.4 , quoting in part:
>    part, defined as expert review.  This section gives some general
   guidelines for what the experts should be looking for, but they are
   being designated as experts for a reason, so they should be given
   substantial latitude.
>   Expert reviewers should take into consideration the following points:
>    *  Point squatting should be discouraged. [...]
[15:06:50] <zulipbot> (Benjamin Kaduk) The QUIC "counterexample" I mentioned that gives much less leeway to the expert can be found at https://www.rfc-editor.org/rfc/rfc9000.html#name-permanent-registrations :
> Permanent registrations in QUIC registries use the Specification Required policy (Section 4.6 of [RFC8126]), unless otherwise specified. The designated expert or experts verify that a specification exists and is readily accessible. Experts are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing or architecturally dubious). The creation of a registry MAY specify additional constraints on permanent registrations.
[15:07:26] <zulipbot> (Orie Steele) An example of an open registry: https://github.com/w3c/did-spec-registries
[15:07:39] <zulipbot> (Orie Steele) I will note that the guidance to the maintainers could still be improved
[15:08:46] <zulipbot> (Justus Winter) I think the only confusion that came up while implementing was about the unit of the memory size parameter
[15:09:08] <zulipbot> (Justus Winter) And we improved upon that iirc
[15:10:38] <zulipbot> (Roman Danyliw) Competition mentioned about Argon2 = https://www.password-hashing.net/
[15:11:17] <zulipbot> (Justus Winter) improvement: https://gitlab.com/openpgp-wg/rfc4880bis/-/commit/88d11499f26a441aa9ca4f454a270be68278e5fa
[15:11:32] <zulipbot> (Roman Danyliw) Which then got adopted by CFRG.  Now https://datatracker.ietf.org/doc/html/rfc9106
[15:11:45] xcrypt1210 leaves the room
[15:14:39] <zulipbot> (Benjamin Kaduk) What do you use for the hash prefix if you're using an EdDSA signature?
[15:15:18] <zulipbot> (Andrew Gallagher) The hash prefix should be taken from the digest, not the signature
[15:15:44] <zulipbot> (Benjamin Kaduk) But EdDSA doesn't have a digest step before signing
[15:17:42] <zulipbot> (Stephen Farrell) @ben: iirc the hash from which the prefix comes is over packets and is what's fed into eddsa (but I may be remembering wong)
[15:18:12] <zulipbot> (Benjamin Kaduk) @sftcd ah, that would make some amount of sense
[15:18:25] <zulipbot> (Justus Winter) ben: we hash the message, then feed the digest to EdDSA
[15:18:38] <zulipbot> (Benjamin Kaduk) (I'm not going to try to find the relevant part of the spec during the meeting, so had to ask)
[15:20:02] <zulipbot> (Tero Kivinen) My notes on this issue might need some checking, as most of the discussion is on such level that I do not understand it...
[15:20:03] <zulipbot> (Justus Winter) we feed the digest to EdDSA *as the message*
[15:20:15] <zulipbot> (Daniel Huigens) As I've written on the list I personally don't think that this particular type of broken key is worth keeping the checksum for, as there might be many other ways a key might be broken that are non-recoverable also
[15:21:36] <zulipbot> (Andrew Gallagher) I don't think the motivation for this check was error recovery, I think it was just the ability to throw away bad stuff with the minimum amount of effort :-)
[15:21:49] <zulipbot> (Justus Winter) yes it is about error recovery
[15:22:03] <zulipbot> (Justus Winter) if you don't reorder the packets, you may miss revocations
[15:22:42] <zulipbot> (Daniel Huigens) Yeah, I meant to Justus's specific point about keeping the checksum for being able to reorder mal-ordered keys
[15:23:32] <zulipbot> (Daniel Huigens) (But I also don't think that that was the original motivation for adding the checksum indeed)
[15:23:33] <zulipbot> (Justus Winter) you can do that reordering with the asymmetric operations, but cert canonicalization is already maybe the most expensive operation that we do
[15:29:00] <zulipbot> (Jonathan Hoyland) Has someone spoken to GitHub and asked them to fix it?
[15:29:27] <zulipbot> (Benjamin Kaduk) re "breakage for the sake of breakage", the whole point of a cryptographic security protocol is to provide breakage, but only when there's an actual attack.  Providing breakage at other times just causes people to be annoyed about the breakage, and we do that inadvertently often enough that we don't have much error budget remaining.
[15:29:53] <zulipbot> (Jonathan Hoyland) Esp. if I understood @Ben correctly that they could fix it retroactively without having to re-sign stuff.
[15:31:19] <zulipbot> (Benjamin Kaduk) They could fix the openpgp signature without re-signing.  I don't know what signature we're talking about and whether it integrates with git in a way that would be covered by the git hash chain.
[15:32:26] <zulipbot> (Andrew Gallagher) They might be able to fix their self-sig in principle, but I'm not aware that any such tooling exists. Most clients don't allow you to do fine bit-correction to that level of precision.
[15:33:20] <zulipbot> (Benjamin Kaduk) I guess we should probably actually confirm my intuition that you can fix it without re-signing, before we get too far down this path...
[15:34:04] <zulipbot> (Andrew Gallagher) Someone with sufficient knowledge of the standard would probably have to fix it in a hex editor. And then you have the question of whether clients would even recognise that the packet was updated, and if so which is the correct one.
[15:36:59] <zulipbot> (Jonathan Hoyland) @Ben Kaduk, I just checked, and adding or modifying a signature changes the commit hash.
[15:37:42] <zulipbot> (Justus Winter) Jonathan: thanks for checking
[15:38:38] <zulipbot> (Benjamin Kaduk) Yes, thanks for checking!
[15:39:13] <zulipbot> (Andrew Gallagher) There are two issues being discussed here that I can see - one is signatures made by the github key. The other (the one I'm interested in) is self-signatures ON the github key. The second is probably fixable in retrospect, the first definitely is not.
[15:39:42] <zulipbot> (Andrew Gallagher) s/other/first/
[15:40:16] <zulipbot> (Justus Winter) Please move the camera
[15:40:29] <zulipbot> (Justus Winter) we cannot see Daniel
[15:40:31] <dkg> meetecho: can you pan the camera to reach daniel?
[15:40:43] <dkg> thank you!
[15:41:49] <zulipbot> (Benjamin Kaduk) I'm waiting for the rest of the talk to be "Kerberos, but for OpenPGP" :)
[15:42:05] xcrypt1210 joins the room
[15:42:54] <zulipbot> (Benjamin Kaduk) > symmetrically sign stuff, using an HMAC or a CMAC
Or a KMAC!
[15:43:31] <zulipbot> (Justus Winter) (obligatory plug :)
[15:43:49] <dkg> Andrew: why would it not be possible to fix the self-sigs on the github certificate?  if the MPIs of the public key are malformed, *that* would be awkward (because the fingerprint would change), but the self-sig could be bit-fiddled like any other sig, right?
[15:44:43] <dkg> if anyone has a contact at github, i'd be happy to try reaching out to them as a WG chair
[15:45:20] <zulipbot> (Andrew Gallagher) @dkg: they could be bit-fiddled, yes. But what happens if a client tries to merge the bit-fiddled version with the non-fiddled one? I'm not saying it wouldn't work - I'm saying I have no clue whether it would work and it might only work in some clients.
[15:45:36] <zulipbot> (Aron Wussler) Jonathan commented before: @Ben Kaduk, I just checked, and adding or modifying a signature changes the commit hash.
[15:45:45] vanitasvitae leaves the room
[15:46:14] <zulipbot> (Aron Wussler) So this might be the simple reason why you don't want to fiddle with old signatures
[15:47:16] <zulipbot> (Jonathan Hoyland) I guess it would be fixable with a git rebase, but a lot of git trees are a bit fragile.
[15:47:20] <dkg> Looks like JanZerebecki reported it here: https://github.com/community/community/discussions/27607
[15:47:29] <zulipbot> (Benjamin Kaduk) I guess HPKE is maybe a "better fit" for the existing openpgp classifications than stock AEAD would be ... but it's also not quite the same.
[15:47:42] <zulipbot> (Benjamin Kaduk) *not quite the same as what Daniel wants
[15:47:42] <zulipbot> (Jonathan Hoyland) (Or at least, I keep breaking them 😅)
[15:49:24] <zulipbot> (Aron Wussler) Changing commit IDs can be very problematic with many package distribution system
[15:49:37] <zulipbot> (Andrew Gallagher) @justus: yes, and I think go-crypto will do the same - it will throw away the bad sig straight away so there's no confusion when the fixed one arrives. But what about those clients that don't recognise the bad selfsig as bad?
[15:50:20] <zulipbot> (Justus Winter) then you have two very similar signatures and consider both valid
[15:50:34] <zulipbot> (Justus Winter) luckily, both say the same thing, so i don't think this would cause confusion
[15:51:08] <zulipbot> (Andrew Gallagher) They may import the new selfsig as a duplicate sig, which would be great. Or they may dedup the two sigs for being the "same".
[15:51:47] <zulipbot> (Andrew Gallagher) I have no idea if any actual client would do this, I'm just throwing out the possibility that we can't rule it out.
[15:59:56] <zulipbot> (Daniel Huigens) 👏
[16:00:01] xcrypt1210 leaves the room
[16:00:09] <zulipbot> (Quynh Dang) thank you all
[16:00:09] <zulipbot> (Justus Winter) thank you all :)
[16:00:27] <gniibe> Thank you all.
[16:00:50] <zulipbot> (Jonathan Hoyland) @Meetecho: Adjourned
[16:00:53] vanitasvitae joins the room
[16:06:46] gniibe leaves the room
[16:14:17] dkg leaves the room
[16:32:32] vanitasvitae leaves the room
[17:21:15] xcrypt1210 joins the room
[17:46:17] xcrypt1210 leaves the room
[18:22:18] xcrypt1210 joins the room
[19:04:48] xcrypt1210 leaves the room
[19:23:20] xcrypt1210 joins the room
[19:46:23] xcrypt1210 leaves the room
[21:22:23] justus leaves the room
[22:30:55] xcrypt1210 joins the room
[22:48:23] xcrypt1210 leaves the room
[22:50:16] xcrypt1210 joins the room
[23:21:36] vanitasvitae joins the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!