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

[Gregory Maxwell <[e-mail]>]

On Sat, Oct 28, 2017 at 8:23 AM, Paul Wouters <[e-mail]> wrote:
> 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)

This is a great argument but it does not apply here: A PGP public key
lists the suites that it supports. The only way you get an
incompatibility is if the far end is OCB-only and you can't support it
and that failure is "realtime" not delayed.

> 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

IIRC most or all of the popular OCB alternatives are CTR based and
highly brittle to nonce reuse.

SIV mode is the only currently standardized-in-any-way AEAD mode that
I'm aware of that has some robustness to nonce reuse.

Not that IV reuse should be a major risk factor for OpenPGP-- but I
think we've all learned that brittle constructions tend to result in
unwelcome surprises, that line if thinking is why AEAD modes exists in
the first place.

>The fact that there is a discussion and unclarity
> about this at all shows that there is an issue here.

Never underestimate people's ability to have a debate.

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

This seems rather moralistic rather than a practical consideration.

IETF protocols routinely register encodings and codepoints for highly
restricted techniques:  OCB in OpenPGP would only get used when there
is mutual support on both ends.

I don't think the laudable effort of avoiding restricted techniques as
mandatory in standardized protocols is aided by a total war on them
that covers optional use of less restrictively licensed things.

The standards process question should primarily be will it get use if
it exists? If not, don't bother. The licensing of OCB appears to be
very permissive for more than a few very broad classes (including Free
Software implementations).  Input from implementers on if they'd
implement it if specified should be the primary metric.

Also, if it gets used will it enhance or harm security (seems more
like the former in this case)?

I don't believe there is any 1:1 replacement for it currently, if
there were that would be a consideration too.

One could make an argument that the grab-bag-choose-your-own-adventure
of many cryptographic options is a bad design, but I think the ship
has already sailed on that one in OpenPGP. :)