Re: [openpgp] Proposal to include AEAD OCB mode to 4880bis

[Paul Wouters <[e-mail]>]

On Sat, 28 Oct 2017, Ronald Tse wrote:

> We all appreciate the work put into adding the AEAD packet specifications and making a real registry of it. It
> should be a good thing that someone proposes to actually use the AEAD registry. There’s really no reason blocking
> others from doing what they want.
> 
> Again, no one is taking anything away from the spec with a “MAY” phrase.

For protocols like IKE/IPsec or TLS, where you negotiate a cipher suite,
MAY algorithms are fine.

For a protocol where both parties are not online at the same time, and
where one party might not know the other party's capabilities at all,
a MAY algorithm can lead to non-interoperability (with human latency
involved)

Do OpenPGP public keys list all the encryption algorithms and signature
algorithms supported by that user? If not, then there should really only
be MUST algorithms (current crypto) and SHOULD algorithms (for things
being sunset). If OpenPGP public keys do list these, do we have any
information how current these are for most published public keys?

It would have been nice to have had OCB support when it was invented.
By now, the gains are pretty minimal. While there is an argument for
having a "stand by" or "backup" algorithm that is universially supported,
I would say chacha20/poly would be the better AEAD candidate.

And I don't agree with your handwaiving about the various different
licenses and use cases. The fact that there is a discussion and unclarity
about this at all shows that there is an issue here.

It's not that I dislike OCB. I looked at OCB a few years ago when TLS got
special permission to use it, to see about defining it for IKE/IPsec as
well, but the TLS draft authors made it clear they took years getting all
the permissions and licensing in place, and it listed "TLS" specifically
at places, so I could not re-use their work at the time for IKE/IPsec. So
I decided not to pursue it for IKE/IPsec.

The lesson here is, don't put arbitrary restrictions on your algorithm if
you want to see widespread adoption.

Paul