OpenPGP Meeting Notes at IETF-95 April 6 11:00 WG: Open Specification for Pretty Good Privacy (openpgp) Meeting: IETF 95, Buenos Aires Location: Buenos Aires Hilton, Atlantico C Date: 2016-04-06 Time: 11:00-12:30 ART Chair: Daniel Kahn Gillmor Jabber Scribe: Rich Salz Notes: Niels ten Oever dkg: There is a short meeting, some progress, some discussion on remaining issues. Note well Agenda accepted - Working Group Agenda - https://tools.ietf.org/html/draft-koch-openpgp-rfc4880bis-02 - https://gitlab.com/openpgp-wg/rfc4880bis - terminology review - S2K (Argon2i + tweak for Corrigan-Gibbs) - fingerprint inclusion of creation time? - further progress/discussion on OAE? - AES-GCM - AES-OCB - ChaCha20-Poly1305 - POET/AEZ/ELmD Meeting: - https://tools.ietf.org/html/draft-koch-openpgp-rfc4880bis-02 - https://gitlab.com/openpgp-wg/rfc4880bis Only Rich and dkg have looked at Werners draft last version. Werner Koch has his own Git repo, dkg is happy to take pull requests from Gitlab and port them to Werner's repo. Discussion should be happening on the list, but git can be used as issue tracker. Request for review and comment. Should we adopt as WG ? Maybe makes no sense if ppl have not read it and if there were no big changes. Feedback would be appreciated. - terminology review Rich and Robin Wilton have reviewed the terminology. Rich mentioned that not all language is consistent and aligned with other text. There is a difference between 4880 and other places where OpenPGP is being discussed. Almost every term dates back to the original dates. Question is whether you want to help GPG community or align more with the bigger IETF security terminology. This could be quite an invasive change and need a terminology section at the beginning. Some wording will have to change and we need consensus on the group -> Rich will make a bullet-list of terms that might need translation - S2K (Argon2i + tweak for Corrigan-Gibbs) There seems to be consensus on the list. No one in the room disagrees, has concerns or objections with using Argon - fingerprint inclusion of creation time? We want one type of fingerprint per key. What will this FP be, and what do we put in. Creation time is included in current keys. Do we want to keep that present? Of do we want the FP to direct to the unlying key. Is similar to the keypining issue that happens in the HTTPS world. Phil Hallam-Baker: Having a key without creation time seems a bad idea dkg: doesn't need to be, can be in another form Phil Hallam-Baker: If ppl are creating FPs over timestamps over the key material I expect they will keep them together. Otherwise one would end up with ending with saving contacts seperate from the key. Which would be a bad idea since ppl have already made decisions based on this. If this would have been an original decision, it might make sense. Now not so much. Bryan Ford: Having the FP being dependent on other stuff. I don't think I mind. Can we not make it dependent on other stuff too, like the argon. One can create a FP and say on which parameters you want to depend. Would secure against other ppl mining a similar key. Phil Hallam-Baker: The only legitimate prefix one can be mining for, without shooting yourself in the foot, shoot be 0's dkg: Problem with variable FP is when it is unclear because one does not know where it begins or ends (for instance if there was a misprint on a business card) Werner Koch: WIW: For ECDH we need a fingerprint truncted to 20 bytes. Bryan Ford: If we allow the FP to cover anything bbut the bare private key itself, we might end up having different FPs for a key. dkg: which means we don't have a proper FP. werner: I don't think it is that important: we can always truncate it to 20 bytes. Or does PHB suggest to have shorter fprs? dkg: we're talking about a lot of things we could do with FPs, but I think we should write down what we COULD do, and then decide what we WANT to do. We seem to be spinning our wheels. werner: Fingerprints are used a) by the protocol and b) for human inspection. For the latter truncation makes sense Phil Hallam-Baker: I have some of this text, unpublished. I want to use FPs in SSH as well. I would like PGP and SSH to converge. Maybe a solution would be if you use 0's you should use FP compression. dkg: You seem to keep expanding what we would like to do with FPs whereas I would like to make the scope smaller because I would like this to end. Would you do the write down with this scope? Phil-Hallam Baker: Yes - further progress/discussion on OAE? - AES-GCM - AES-OCB - ChaCha20-Poly1305 - POET/AEZ/ELmD Stephen Farrell: IP for OCB is a mess. Issues with non-military use with AES-OCB. Bryan Ford: Having one AES cipher and Cha Cha seem to have good diversity and would defuse the monoculture argument Sean Turner: Back in the day when there was DSA/RSA we said: you can choose one of two, but on the receiving side your need to accept both. **a patch seems to be the solution/ consensus** AOB Derek Atkins: I plan to review dkg: we're done early because not much has been done, I hope and expect we'll change this in the future. I want to raise one additional question on what we see in the broader IETF: when there are asymmetric crypto sigs being done , macing or signing -> add a label, so it is not replayable in another context. So you can not trick ppl into creating openPGP and then replay as TLS handshake. OpenPGP does not give a prefix like that. I am wondering whether it would be worth to adapt this. These are theoretical attack for the most part, but it would be nice to not worry about this. DNSSEC might have a prefix, TLS is already doing this. Having a standard idea in the iETF on how to do this would be nice. Bryan Ford: I strongly support this. in CFRG this came up too. Paul Wouters: Signatures don't tell you. We end up publishing keys in DNS but there is no way to map this key to an email address dkg: OpenPGP has a way to say this userID made this sig. Phil Hallam-Baker: I want to support putting an ID in. This would need an IETF wide thing at the minimum. I don't think there is a chance content types will be misused by other WGs. Content types look like a good bet, and we can always extend them. S/MIME usability has been done without hassle. i did that because if I did PGP did before S/MIME people would not help. dkg: Is this a call for collaborators: Phil Hallam-Baker: Yes. dkg: Do ppl have other questions or concerns? I hope ppl will follow up on the mailinglist, and get some patches flowing and get the draft underway. Thanks all for being here.