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

[Ronald Tse]

Hi OpenPGP WG,

There has been some discussion in the group some time ago about OCB, but back then the AEAD requirements were not set in stone.

Since bis-02 now formally defines the AEAD packet and an AEAD algorithm registry, I’d like to bring up the topic again of adding OCB to the draft given its clear benefits. There have been previous mentions of patent concerns, but OCB is freely licensed for open source tools and has been included in libraries like OpenSSL and Botan.

I have submitted a merge request to the document repository, and the diffs can be seen below.

Merge request
* https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/8

Diffs
* https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/8/diffs

Please feel free to let me know what you think. Thanks!

Kind regards,
Ron

P.S. this merge request includes https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/7 as the document wasn’t “buildable” due to a missing reference to RFC 7748.

_____________________________________

Ronald Tse
Ribose Inc.

+=========================================================+
This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to
receive this for the addressee, you must not use, copy,
disclose or take any action based on this message or any
information herein. If you have received this message in
error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation.
+=========================================================+

[Werner Koch]

On Wed, 25 Oct 2017 11:16, ***@ribose.com said:

> Diffs
> * https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/8/diffs

Can you please send the diff to this mailing list so that we do not need
to rely on external sources in the archives of this ML. it is also
easier for me to work with patches send by mail.


>
> Please feel free to let me know what you think. Thanks!
>
> Kind regards,
> Ron
>
> P.S. this merge request includes https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/7 as the document wasn’t “buildable” due to a missing reference to RFC 7748.
>
> _____________________________________
>
> Ronald Tse
> Ribose Inc.
>
> +=========================================================+
> This message may contain confidential and/or privileged
> information. If you are not the addressee or authorized to
> receive this for the addressee, you must not use, copy,
> disclose or take any action based on this message or any
> information herein. If you have received this message in
> error, please advise the sender immediately by reply e-mail
> and delete this message. Thank you for your cooperation.
> +=========================================================+
>
> _______________________________________________
> openpgp mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

[Paul Wouters]

On Wed, 25 Oct 2017, Ronald Tse wrote:

> Since bis-02 now formally defines the AEAD packet and an AEAD algorithm registry, I’d like to bring up the topic again of
> adding OCB to the draft given its clear benefits. There have been previous mentions of patent concerns, but OCB is freely
> licensed for open source tools and has been included in libraries like OpenSSL and Botan.

What is the advantage of adding more and more algorithms and variants?

If OCB is clearly a winner over another algorithm candidate to be added,
is the inferior other candidate removed?

Adding algorithms is easy. Removing them is hard. That should raise the
bar for adding new ones.

Paul

[Rick van Rein]

Hi,

> Adding algorithms is easy. Removing them is hard. That should raise the
> bar for adding new ones.

I second that. There should be a good reason for adding new algorithms.
(Which is always subjective because it is really helpful to have things
to fall back on when a part fails, security-wise.)

Along the same lines I'm also surprised that no effort has been made to
deprecate 2.x PGP packet formats and public key formats, for instance.
We all know that such old keys don't have a reason to exist anymore,
but we're all still coding the old and new in order to be compliant to
the standards. Such a waste of time...

-Rick

[Ronald Tse]

Hi Werner, Rick and Paul,

Werner, thanks for the tip. I’ve just sent the proposed patches to the mailing list as you probably already see it.

Rick, Paul,

The benefits of OCB mode are best explained on this page:
http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm

In comparison with EAX which is already included in 4880bis, OCB is fully parallelizable for encryption/decryption and authentication (EAX authentication is serial). It is a single-pass algorithm (EAX is 2-pass), and is currently the only widely accepted AEAD mode that is endian-independent (EAX is endian-dependent), which makes implementation easier.

Performance of OCB is superior to EAX and is probably the fastest among accepted AEAD competitors, which is compared in this paper:
https://www.fi.muni.cz/~xsvenda/docs/AE_comparison_ipics04.pdf

This paper states that with 16 byte messages, EAX requires 227.09 cycles per byte (6 blockcipher invocations), while OCB only 118.91 (3 blockcipher invocations) cycles are needed.

In addition, Krovetz and Rogaway have also made the effort to standardize OCB in RFC 7254, providing a stable IETF reference, and also included OCB-AES in the IANA registry for AEAD parameter sets (RFC 5116), which EAX is not present:
https://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml

Another thought is to actually refer to the IANA registry for OpenPGP supported AEAD algorithms, but that might be a topic for another day.

Kind regards,
Ron

_____________________________________

Ronald Tse
Ribose Inc.

+=========================================================+
This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to
receive this for the addressee, you must not use, copy,
disclose or take any action based on this message or any
information herein. If you have received this message in
error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation.
+=========================================================+

On Oct 26, 2017, at 12:47 AM, Rick van Rein <***@openfortress.nl<mailto:***@openfortress.nl>> wrote:

Hi,

Adding algorithms is easy. Removing them is hard. That should raise the
bar for adding new ones.

I second that. There should be a good reason for adding new algorithms.
(Which is always subjective because it is really helpful to have things
to fall back on when a part fails, security-wise.)

Along the same lines I'm also surprised that no effort has been made to
deprecate 2.x PGP packet formats and public key formats, for instance.
We all know that such old keys don't have a reason to exist anymore,
but we're all still coding the old and new in order to be compliant to
the standards. Such a waste of time...

-Rick

[Derek Atkins]

Rick van Rein <***@openfortress.nl> writes:

> Along the same lines I'm also surprised that no effort has been made to
> deprecate 2.x PGP packet formats and public key formats, for instance.
> We all know that such old keys don't have a reason to exist anymore,
> but we're all still coding the old and new in order to be compliant to
> the standards. Such a waste of time...

I have files encrypted 20+ years ago (to a 20+ year old key) sitting
around in storage. Are you saying that those encrypted files should not
be readable anymore?

And note that if your response is "but just re-encrypt them", I'll add
that then I lose a lot of the original data, like original signing date
etc. Moreover, AFAIK there is no tool that I can use to re-encrypt a
message while keeping signature data intact. (Please correct me if I'm
missing something, but even gpg does not seem to have a "re-encrypt"
option).

> -Rick

-derek
--
Derek Atkins 617-623-3745
***@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant

[Rick van Rein]

Hi Derek,

>> Along the same lines I'm also surprised that no effort has been made to
>> deprecate 2.x PGP packet formats and public key formats, for instance.
>> We all know that such old keys don't have a reason to exist anymore,
>> but we're all still coding the old and new in order to be compliant to
>> the standards. Such a waste of time...
>
> I have files encrypted 20+ years ago (to a 20+ year old key) sitting
> around in storage. Are you saying that those encrypted files should not
> be readable anymore?

I was thinking about signing, which was indeed an oversight.

One might question if current-day crypto software should continue to
support old encrypted files though, or that a fork would be wiser. The
added complexity of the software is far from helpful in keeping software
clear and bug free. Also, this old material may end up being treated by
hardly-tested code, which is another undesirable part.

Anyhow, I brought this up to agree that we should be careful what is
being added, and your response is in fact confirming that.

-Rick

[Paul Wouters]

On Oct 30, 2017, at 19:29, Rick van Rein <***@openfortress.nl> wrote:
>
> Hi Derek,
>
>>
>> I have files encrypted 20+ years ago (to a 20+ year old key) sitting
>> around in storage. Are you saying that those encrypted files should not
>> be readable anymore?

So when do we stop supporting an algorithm? When it can be brute forces in a month? A year ? A day?


> One might question if current-day crypto software should continue to
> support old encrypted files though, or that a fork would be wiser.

Like pgp 2.6 and pgp 5. Yes.

A way to also stimulate upgrading could be to demote algorithms to decrypt/verify only and not allow them for creating new encrypted/signed material.

As for we have been doing this for 20 years argument, I am still carrying idea.c and still have to manually compile it every time gpg upgrades. So the “current” scheme has proven to not work well at all for me.

Paul

[Derek Atkins]

On Mon, October 30, 2017 2:00 pm, Paul Wouters wrote:
> On Oct 30, 2017, at 19:29, Rick van Rein <***@openfortress.nl> wrote:
>>
>> Hi Derek,
>>
>>>
>>> I have files encrypted 20+ years ago (to a 20+ year old key) sitting
>>> around in storage. Are you saying that those encrypted files should
>>> not
>>> be readable anymore?
>
> So when do we stop supporting an algorithm? When it can be brute forces in
> a month? A year ? A day?

That's a good question, but considering none of it applies to pretty much
any method we've supported (except, perhaps, MD5) it's a bit moot.

>> One might question if current-day crypto software should continue to
>> support old encrypted files though, or that a fork would be wiser.
>
> Like pgp 2.6 and pgp 5. Yes.
>
> A way to also stimulate upgrading could be to demote algorithms to
> decrypt/verify only and not allow them for creating new encrypted/signed
> material.

We've already done that. It "works" (to some degree) to get people to
upgrade.

> As for we have been doing this for 20 years argument, I am still carrying
> idea.c and still have to manually compile it every time gpg upgrades. So
> the “current” scheme has proven to not work well at all for me.

Honestly, AFAIK there has never been a security issue with IDEA; just
patent/licensing. At this point I think all those issues are gone, too,
so honestly there's little reason not to include it natively.

But the real point is that there are so few methods that people want to
support *IN THE PROTOCOL* that there is little reason, IMNSHO, to prevent
them from doing so in a standard way.

Remember, just because the protocol supports a method does not mean
implementations will. But if the protocol does NOT support some methods
it might prevent some users from using the protocol. Hence, if we want to
encourage adoption (even if it's in a closed environment) we should
encourage method adoption. Again, it's not that expensive to do so on our
part.

> Paul

-derek

--
Derek Atkins 617-623-3745
***@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant

[Paul Wouters]

On Mon, 30 Oct 2017, Derek Atkins wrote:

>> As for we have been doing this for 20 years argument, I am still carrying
>> idea.c and still have to manually compile it every time gpg upgrades. So
>> the “current” scheme has proven to not work well at all for me.
>
> Honestly, AFAIK there has never been a security issue with IDEA; just
> patent/licensing. At this point I think all those issues are gone, too,
> so honestly there's little reason not to include it natively.

It was an example of how some people having IDEA and other not having it
causes interop issues to the point that I need to manually hack my
implementation to talk to those people. That's something you want to
avoid more then giving people a list of 6 sexy algorithms to choose
from.

> But the real point is that there are so few methods that people want to
> support *IN THE PROTOCOL* that there is little reason, IMNSHO, to prevent
> them from doing so in a standard way.

I don't understand that sentence.

> Remember, just because the protocol supports a method does not mean
> implementations will.

If you add things to the protocol that the vast majority will not
implement, you have lost already and that added thing becomes useless.

> But if the protocol does NOT support some methods
> it might prevent some users from using the protocol.

Which is a good thing? Do you think most users can make a meaningful
decision about which algorithms to trust or not and for how long?

The reason for a lot variance with TLS or IKE/IPsec with protocols is
that performance does matter. For openpgp, performance hardly matters.
You're not doing 1Gbps or running on an IoT device with 32kb RAM or
require less then 25ms latency.

Paul

[Derek Atkins]

Paul,

On Mon, October 30, 2017 3:22 pm, Paul Wouters wrote:

> It was an example of how some people having IDEA and other not having it
> causes interop issues to the point that I need to manually hack my
> implementation to talk to those people.

Yes, and IMHO, IDEA should get added back in. In this day and age there
is zero reason to prohibit it.

> That's something you want to
> avoid more then giving people a list of 6 sexy algorithms to choose
> from.

Note that it's not "PEOPLE" who are choosing them, per se. It's the
implementers, who one would think would have a better idea of what to
implement and why.

>> But the real point is that there are so few methods that people want to
>> support *IN THE PROTOCOL* that there is little reason, IMNSHO, to
>> prevent
>> them from doing so in a standard way.
>
> I don't understand that sentence.

Okay, let me try again.

How many public key methods are there? Not many.
How many ciphers are there? Again, not many.
Similarly, how many AEAD methods are there? Again... not many.

Even moreso, there are even fewer methods people are proposing to include
in the OpenPGP protocol than the limited number of methods that are out
there.

There are SO FEW methods that, indeed, if even one implementer wants to do
it in a standard way we should let them.

Maybe that implementer is doing something privately, but still wants to do
it in a standard way. We should let them.

Maybe they feel that it'll be years before someone else is interested, but
they want to ensure their code written today will work down the road. We
should let them.

In other words, we should be accepting in relinquishing protocol numbers.

>> Remember, just because the protocol supports a method does not mean
>> implementations will.
>
> If you add things to the protocol that the vast majority will not
> implement, you have lost already and that added thing becomes useless.

You've clearly never worked on (or in) a private enclave. The IETF should
not be in the position to say that private enclaves MAY NOT exist. But
you seem to be implying that by your stance.

Maybe the implementer who wants to add OCB doesn't care if your
implementation can read it, because your implementation is very unlikely
to ever see an OCB message. Why do you want to say that they may not do
that (which is what you're saying by implying that your implementation
must support every feature and that the protocol may not support features
that your implementation does not support).

>> But if the protocol does NOT support some methods
>> it might prevent some users from using the protocol.
>
> Which is a good thing?

No. It's not. We should encourage people to use OpenPGP. It's a great
protocol, and anything we do that prohibits adoption is a bad thing.

> Do you think most users can make a meaningful
> decision about which algorithms to trust or not and for how long?

That's irrelevant to this discussion.

> The reason for a lot variance with TLS or IKE/IPsec with protocols is
> that performance does matter. For openpgp, performance hardly matters.
> You're not doing 1Gbps or running on an IoT device with 32kb RAM or
> require less then 25ms latency.

I'm afraid you're wrong here. I *AM* running OpenPGP on an IoT device,
and in fact that IoT device has less than 32kB RAM. (I'm assuming you
meant 32kB, and not 32kb == 4KB, which is exactly how much RAM my device
has).

I'm running OpenPGP specifically because the data formats are smaller and
easier to generate/parse than X.509, so I *CAN* actually run it in an IoT
device. Of course I'm extremely limited in what methods I support, but I
happen to control both ends of the communication so I can work in an
enclave and control the implementation.

This is exactly why we should be open in what we accept. In my case, I
don't care if your implementation does not support my methods, but I want
to ensure that I can implement my methods in a standard way such that it
wont interfere with you (and you wont interfere with me). Moreso, in a
few years, my messages might escape my enclave, which is yet another
reason I'd like to do it in a standard way.

(And yes, I've moved well beyond OCB in this discussion).

> Paul

-derek

--
Derek Atkins 617-623-3745
***@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant

[Paul Wouters]

On Mon, 30 Oct 2017, Derek Atkins wrote:

> On Mon, October 30, 2017 3:22 pm, Paul Wouters wrote:
>
>> It was an example of how some people having IDEA and other not having it
>> causes interop issues to the point that I need to manually hack my
>> implementation to talk to those people.
>
> Yes, and IMHO, IDEA should get added back in. In this day and age there
> is zero reason to prohibit it.

You miss my point. Implementors made decisions and as a result, non-expert
endusers ended up not being able to send each other encrypted email. I
am sayong don't repeat that mistake.

> Note that it's not "PEOPLE" who are choosing them, per se. It's the
> implementers, who one would think would have a better idea of what to
> implement and why.

That still does not help much against someone using a new algorithm and
someone else using old software that does not have that algorithm.

How long does it take for any now added algorithm to be commonly
supported? By paranoid people who dont want to upgrade their offline
systems? :)

> Maybe that implementer is doing something privately, but still wants to do
> it in a standard way. We should let them.

That's what private number ranges are for.

> Maybe the implementer who wants to add OCB doesn't care if your
> implementation can read it, because your implementation is very unlikely
> to ever see an OCB message. Why do you want to say that they may not do
> that (which is what you're saying by implying that your implementation
> must support every feature and that the protocol may not support features
> that your implementation does not support).

As long as you can detect the support when you have the public key, that's
probably okay. But that's still a weak argument to allow vanity
algorithms, as it will still increase the chance that multiple parties
don't share those in their implementation.

And how does this work when my phone supports some algorithms, and my
laptop supports other. How do I announce that in my public key? It
looks like you'd be forced to only publish the shared algorithms. I
wouldn't even know how to announce that.

>>> But if the protocol does NOT support some methods
>>> it might prevent some users from using the protocol.
>>
>> Which is a good thing?
>
> No. It's not. We should encourage people to use OpenPGP. It's a great
> protocol, and anything we do that prohibits adoption is a bad thing.

Swiss army knives are great tools. Raise your hand if you never cut
yourself with one.

> I'm running OpenPGP specifically because the data formats are smaller and
> easier to generate/parse than X.509, so I *CAN* actually run it in an IoT
> device. Of course I'm extremely limited in what methods I support, but I
> happen to control both ends of the communication so I can work in an
> enclave and control the implementation.
>
> This is exactly why we should be open in what we accept. In my case, I
> don't care if your implementation does not support my methods, but I want
> to ensure that I can implement my methods in a standard way such that it
> wont interfere with you (and you wont interfere with me).

Ok, well if all of that needs to be supported I guess we will be cursed
with an amount of failure as the price to pay for the freedom to
shoehorn openpgp on everything. I still think it is wise to try and
limit the number of algorithms with similar cryptographic and
architectural properties.

Paul

[Derek Atkins]

On Mon, October 30, 2017 4:29 pm, Paul Wouters wrote:
> On Mon, 30 Oct 2017, Derek Atkins wrote:
>
>> On Mon, October 30, 2017 3:22 pm, Paul Wouters wrote:
>>
>>> It was an example of how some people having IDEA and other not having
>>> it
>>> causes interop issues to the point that I need to manually hack my
>>> implementation to talk to those people.
>>
>> Yes, and IMHO, IDEA should get added back in. In this day and age there
>> is zero reason to prohibit it.
>
> You miss my point. Implementors made decisions and as a result, non-expert
> endusers ended up not being able to send each other encrypted email. I
> am sayong don't repeat that mistake.

And you're saying the mistake is that IDEA was included in the first
place? Or that IDEA was removed? Or...???

>> Note that it's not "PEOPLE" who are choosing them, per se. It's the
>> implementers, who one would think would have a better idea of what to
>> implement and why.
>
> That still does not help much against someone using a new algorithm and
> someone else using old software that does not have that algorithm.

Sure. Just like you're not going to be able to run Linux on an Apple ][

> How long does it take for any now added algorithm to be commonly
> supported? By paranoid people who dont want to upgrade their offline
> systems? :)

Probably a few years at least, which is a good reason to get it into the
spec NOW for the hope that in 3-5 years it'll be more widely deployed.

>> Maybe that implementer is doing something privately, but still wants to
>> do
>> it in a standard way. We should let them.
>
> That's what private number ranges are for.

That's not "in a standard way". It also only works for experimentation.
If you ever expect to deploy it you should NOT use a private number range,
because MY private numbers and YOUR private numbers may conflict.

>> Maybe the implementer who wants to add OCB doesn't care if your
>> implementation can read it, because your implementation is very unlikely
>> to ever see an OCB message. Why do you want to say that they may not do
>> that (which is what you're saying by implying that your implementation
>> must support every feature and that the protocol may not support
>> features
>> that your implementation does not support).
>
> As long as you can detect the support when you have the public key, that's
> probably okay.

You can. The self-signature on a key encodes that.

> But that's still a weak argument to allow vanity
> algorithms, as it will still increase the chance that multiple parties
> don't share those in their implementation.

Perhaps, but that's a different argument and unrelated to whether the spec
should specify a code point. You seem to be arguing that if it's not 100%
in use everywhere then we shouldn't allocate a code point. I'm suggesting
that code points are relatively cheap and should be open to most all
comers with reasonable requests.

> And how does this work when my phone supports some algorithms, and my
> laptop supports other. How do I announce that in my public key? It
> looks like you'd be forced to only publish the shared algorithms. I
> wouldn't even know how to announce that.

How are you sharing your keypairs across your devices?

>>>> But if the protocol does NOT support some methods
>>>> it might prevent some users from using the protocol.
>>>
>>> Which is a good thing?
>>
>> No. It's not. We should encourage people to use OpenPGP. It's a great
>> protocol, and anything we do that prohibits adoption is a bad thing.
>
> Swiss army knives are great tools. Raise your hand if you never cut
> yourself with one.

* Raises his hand *

You're right, they are great tools, and they are great because they
include so many tools, even tools that not everyone needs. And even
better, there are different models of swiss army knifes (SAK) that include
different sets of tools. So my knife probably has a different set than
yours. And that's a good thing.

If every SAK contained the same set of tools then it would probably be
less useful. When I was a kid I used the magnifying glass all the time,
but never the saw. Later on I found uses for the saw, but kind of lost a
use case for the magnifying glass.

>> I'm running OpenPGP specifically because the data formats are smaller
>> and
>> easier to generate/parse than X.509, so I *CAN* actually run it in an
>> IoT
>> device. Of course I'm extremely limited in what methods I support, but
>> I
>> happen to control both ends of the communication so I can work in an
>> enclave and control the implementation.
>>
>> This is exactly why we should be open in what we accept. In my case, I
>> don't care if your implementation does not support my methods, but I
>> want
>> to ensure that I can implement my methods in a standard way such that it
>> wont interfere with you (and you wont interfere with me).
>
> Ok, well if all of that needs to be supported I guess we will be cursed
> with an amount of failure as the price to pay for the freedom to
> shoehorn openpgp on everything. I still think it is wise to try and
> limit the number of algorithms with similar cryptographic and
> architectural properties.

I think you're continually conflating the OpenPGP Specification / Protocol
with various implementations. We already have the case that different
implementations include different crypto methods. In fact we've lived
with that case for the past two decades and the world has not ended.

I'm saying that the SPEC should allow the freedom. I also feel it's fine
if GPG chooses not to implement something that I want in my implementation
(or, vice versa). I also feel it's fine if you choose even different.

This is exactly the purpose of MUST, SHOULD, and MAY in the spec. You
KNOW that a compliant implementation will overlap in the MUST methods.

> Paul

-derek

--
Derek Atkins 617-623-3745
***@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant

[Ronald Tse]

Thank you Derek for the insightful comments. I fully agree with them.

The “algorithm registries” (including the AEAD registry) exist to allow multiple algorithms, whether optional or mandatory, to exist. Otherwise there should just be one big MUST and we all get on with it. The point of a standard is to allow independent implementations to interoperate — the usage of private numbers defeats that intention.

OpenPGP is already used in more places than just email exchanges, take file signature verification as an example. It should not be up to the workgroup to decide that such usage should now be prohibited. In fact within the entire RFC 4880, there is no mention that OpenPGP is intended for email exchange — the spec was intended to be a generic message format allowing people to use it as they see fit.

To answer the patent concerns of OCB: Rogaway is willing to provide a royalty-free license for all implementers and users of OpenPGP, served alongside the draft as an IETF IPR. This means that the previous points of “military-use” or linkage to “closed-source” software are resolved.

Ron

_____________________________________

Ronald Tse
Ribose Inc.

On Oct 31, 2017, at 5:09 AM, Derek Atkins <***@ihtfp.com<mailto:***@ihtfp.com>> wrote:


On Mon, October 30, 2017 4:29 pm, Paul Wouters wrote:
On Mon, 30 Oct 2017, Derek Atkins wrote:

On Mon, October 30, 2017 3:22 pm, Paul Wouters wrote:

It was an example of how some people having IDEA and other not having
it
causes interop issues to the point that I need to manually hack my
implementation to talk to those people.

Yes, and IMHO, IDEA should get added back in. In this day and age there
is zero reason to prohibit it.

You miss my point. Implementors made decisions and as a result, non-expert
endusers ended up not being able to send each other encrypted email. I
am sayong don't repeat that mistake.

And you're saying the mistake is that IDEA was included in the first
place? Or that IDEA was removed? Or...???

Note that it's not "PEOPLE" who are choosing them, per se. It's the
implementers, who one would think would have a better idea of what to
implement and why.

That still does not help much against someone using a new algorithm and
someone else using old software that does not have that algorithm.

Sure. Just like you're not going to be able to run Linux on an Apple ][

How long does it take for any now added algorithm to be commonly
supported? By paranoid people who dont want to upgrade their offline
systems? :)

Probably a few years at least, which is a good reason to get it into the
spec NOW for the hope that in 3-5 years it'll be more widely deployed.

Maybe that implementer is doing something privately, but still wants to
do
it in a standard way. We should let them.

That's what private number ranges are for.

That's not "in a standard way". It also only works for experimentation.
If you ever expect to deploy it you should NOT use a private number range,
because MY private numbers and YOUR private numbers may conflict.

Maybe the implementer who wants to add OCB doesn't care if your
implementation can read it, because your implementation is very unlikely
to ever see an OCB message. Why do you want to say that they may not do
that (which is what you're saying by implying that your implementation
must support every feature and that the protocol may not support
features
that your implementation does not support).

As long as you can detect the support when you have the public key, that's
probably okay.

You can. The self-signature on a key encodes that.

But that's still a weak argument to allow vanity
algorithms, as it will still increase the chance that multiple parties
don't share those in their implementation.

Perhaps, but that's a different argument and unrelated to whether the spec
should specify a code point. You seem to be arguing that if it's not 100%
in use everywhere then we shouldn't allocate a code point. I'm suggesting
that code points are relatively cheap and should be open to most all
comers with reasonable requests.

And how does this work when my phone supports some algorithms, and my
laptop supports other. How do I announce that in my public key? It
looks like you'd be forced to only publish the shared algorithms. I
wouldn't even know how to announce that.

How are you sharing your keypairs across your devices?

But if the protocol does NOT support some methods
it might prevent some users from using the protocol.

Which is a good thing?

No. It's not. We should encourage people to use OpenPGP. It's a great
protocol, and anything we do that prohibits adoption is a bad thing.

Swiss army knives are great tools. Raise your hand if you never cut
yourself with one.

* Raises his hand *

You're right, they are great tools, and they are great because they
include so many tools, even tools that not everyone needs. And even
better, there are different models of swiss army knifes (SAK) that include
different sets of tools. So my knife probably has a different set than
yours. And that's a good thing.

If every SAK contained the same set of tools then it would probably be
less useful. When I was a kid I used the magnifying glass all the time,
but never the saw. Later on I found uses for the saw, but kind of lost a
use case for the magnifying glass.

I'm running OpenPGP specifically because the data formats are smaller
and
easier to generate/parse than X.509, so I *CAN* actually run it in an
IoT
device. Of course I'm extremely limited in what methods I support, but
I
happen to control both ends of the communication so I can work in an
enclave and control the implementation.

This is exactly why we should be open in what we accept. In my case, I
don't care if your implementation does not support my methods, but I
want
to ensure that I can implement my methods in a standard way such that it
wont interfere with you (and you wont interfere with me).

Ok, well if all of that needs to be supported I guess we will be cursed
with an amount of failure as the price to pay for the freedom to
shoehorn openpgp on everything. I still think it is wise to try and
limit the number of algorithms with similar cryptographic and
architectural properties.

I think you're continually conflating the OpenPGP Specification / Protocol
with various implementations. We already have the case that different
implementations include different crypto methods. In fact we've lived
with that case for the past two decades and the world has not ended.

I'm saying that the SPEC should allow the freedom. I also feel it's fine
if GPG chooses not to implement something that I want in my implementation
(or, vice versa). I also feel it's fine if you choose even different.

This is exactly the purpose of MUST, SHOULD, and MAY in the spec. You
KNOW that a compliant implementation will overlap in the MUST methods.

Paul

-derek

--
Derek Atkins 617-623-3745
***@ihtfp.com<mailto:***@ihtfp.com> www.ihtfp.com<http://www.ihtfp.com/>
Computer and Internet Security Consultant

_______________________________________________
openpgp mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/openpgp

[Derek Atkins]

Paul Wouters <***@nohats.ca> writes:

> On Wed, 25 Oct 2017, Ronald Tse wrote:
>
>> Since bis-02 now formally defines the AEAD packet and an AEAD
>> algorithm registry, I’d like to bring up the topic again of
>> adding OCB to the draft given its clear benefits. There have been
>> previous mentions of patent concerns, but OCB is freely
>> licensed for open source tools and has been included in libraries
>> like OpenSSL and Botan.
>
> What is the advantage of adding more and more algorithms and variants?

Different requirements in different use-cases.

> If OCB is clearly a winner over another algorithm candidate to be added,
> is the inferior other candidate removed?

Not necessarily. Just because one is a "winner" does not necessarily
mean the other is "inferior". Again, different use-cases have different
requirements that could result in different preferred choices.

> Adding algorithms is easy. Removing them is hard. That should raise the
> bar for adding new ones.

Historically the OpenPGP group has been relatively inviting and open to
addition (non-mandatory) algorithms. I see no reason today that this
decades-old practice be changed.

> Paul

-derek
--
Derek Atkins 617-623-3745
***@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant

[Peter Gutmann]

Ronald Tse <***@ribose.com> writes:

>There have been previous mentions of patent concerns, but OCB is freely
>licensed for open source tools and has been included in libraries like
>OpenSSL and Botan.

It's a lot more problematic than that. While I support the OCB patent
holder's stand on a moral basis, the licensing unfortunately makes it
impossible to use for general software, which is a real shame because it's a
very nice crypto mechanism. Examples of some general-purpose uses of crypto
and how the license affects them:

Banking: No, because members of the military might be customers.

Email: No, because it might go to/come from a .mil address.

Ordering a pizza online: No, because it might be sent to a military base.

(Some of these are from actual legal analyses of the implications of using it,
not just me coming up with corner cases).

IDEA had the same problem, it was more or less OK to use in open-source type
software, but was still sufficiently problematic that it was removed from
OpenPGP. It's the same with OCB, the license terms require that you track
every single use and user of the software in order to verify that the use is
non-infringing. That makes it unusable for real-world purposes, i.e. where
commercial entities are involved.

Peter.

[Ronald Tse]

Hi Peter,

Perhaps I could clarify that the OCB patent is limited in regional scope and does not apply outside of the US. For example, the NZ military could order a pizza using OCB.

The OCB licenses provided on Rogaway’s page is very clear that open source usage, such as in OpenSSL and any products based on OpenSSL, is strictly allowed — which means that military and hardware usage of OCB through OpenSSL is already allowed.

I think we are slightly confusing an optional algorithm, which OCB is proposed to be, with a mandatory one. A user should be able to specify in their preferences that they don’t accept OCB. A .mil email address will probably specify they do not want OCB in this case.

Given OpenPGP is supposed to be “open”, people should be able to state their preferences as well as do what they want with it.

For example, Chinese cryptography law strictly forbids AES usage in hardware. Does that mean Intel needs to drop AES-NI for chips sold in China? The answer is no. People simply don’t use it because of these regulations.

This is the same with OCB — if you don’t like it, don’t want it, just don't use it. It only enables people who want it to use it.

Ron

_____________________________________

Ronald Tse
Ribose Inc.

+=========================================================+
This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to
receive this for the addressee, you must not use, copy,
disclose or take any action based on this message or any
information herein. If you have received this message in
error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation.
+=========================================================+

On Oct 26, 2017, at 9:34 AM, Peter Gutmann <***@cs.auckland.ac.nz<mailto:***@cs.auckland.ac.nz>> wrote:

Ronald Tse <***@ribose.com<mailto:***@ribose.com>> writes:

There have been previous mentions of patent concerns, but OCB is freely
licensed for open source tools and has been included in libraries like
OpenSSL and Botan.

It's a lot more problematic than that. While I support the OCB patent
holder's stand on a moral basis, the licensing unfortunately makes it
impossible to use for general software, which is a real shame because it's a
very nice crypto mechanism. Examples of some general-purpose uses of crypto
and how the license affects them:

Banking: No, because members of the military might be customers.

Email: No, because it might go to/come from a .mil address.

Ordering a pizza online: No, because it might be sent to a military base.

(Some of these are from actual legal analyses of the implications of using it,
not just me coming up with corner cases).

IDEA had the same problem, it was more or less OK to use in open-source type
software, but was still sufficiently problematic that it was removed from
OpenPGP. It's the same with OCB, the license terms require that you track
every single use and user of the software in order to verify that the use is
non-infringing. That makes it unusable for real-world purposes, i.e. where
commercial entities are involved.

Peter.


_______________________________________________
openpgp mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/openpgp

[brian m. carlson]

On Thu, Oct 26, 2017 at 02:03:02AM +0000, Ronald Tse wrote:
> Perhaps I could clarify that the OCB patent is limited in regional
> scope and does not apply outside of the US. For example, the NZ
> military could order a pizza using OCB.

Unfortunately, a patent anywhere is an impediment everywhere in the age
of the Internet.

> The OCB licenses provided on Rogaway’s page is very clear that open
> source usage, such as in OpenSSL and any products based on OpenSSL, is
> strictly allowed — which means that military and hardware usage of OCB
> through OpenSSL is already allowed.

It's my reading of Rogaway's license that linking an open-source library
against closed source software violates the patent license, even though
it might not violate the library license. If a distro ships an
OCB-enabled crypto library, it can't be used for any closed-source
software shipped on that system (Chrome, Slack) or any non-open-source
custom-built apps (say, an internal Rails app).

Since crypto libraries like OpenSSL are very frequently linked against
other software on the system, this is a terrible idea.

The fact that it's this hard to understand the patent issues makes it
really obvious why OCB is a bad idea.

> I think we are slightly confusing an optional algorithm, which OCB is
> proposed to be, with a mandatory one. A user should be able to specify
> in their preferences that they don’t accept OCB. A .mil email address
> will probably specify they do not want OCB in this case.

I'm generally opposed to including algorithms, even optional ones, which
are patent-encumbered. The fact that an IPR declaration exists for an
RFC is enough to scare off many companies from implementing it.

I personally hate having to meet with company lawyers, even extremely
knowledgable ones, about the type of crypto we use and the legal impacts
of it. Adding OCB to the spec is going to cause a lot of those
conversations that don't need to happen.

> Given OpenPGP is supposed to be “open”, people should be able to state
> their preferences as well as do what they want with it.
>
> For example, Chinese cryptography law strictly forbids AES usage in
> hardware. Does that mean Intel needs to drop AES-NI for chips sold in
> China? The answer is no. People simply don’t use it because of these
> regulations.
>
> This is the same with OCB — if you don’t like it, don’t want it, just
> don't use it. It only enables people who want it to use it.

Practically, a patent-encumbered algorithm is not likely to be
implemented. The patent problems with OCB make it unlikely that it will
be suitable for inclusion into the Red Hat or Debian archives. That
means that most open-source implementations will not include it, and
those that do will not interoperate with those that don't.

Why should we add an algorithm which is likely to get little practical
usage? OCB doesn't provide useful crypto agility, but it does provide
yet another option, which we've tried to avoid in the specification.
Additional algorithms are hard to deprecate and are a source of
potential security bugs in implementations.

I'm not saying OCB isn't a great block cipher mode, just that it's going
to be practically unused because of the patent situation.

> +=========================================================+
> This message may contain confidential and/or privileged
> information. If you are not the addressee or authorized to
> receive this for the addressee, you must not use, copy,
> disclose or take any action based on this message or any
> information herein. If you have received this message in
> error, please advise the sender immediately by reply e-mail
> and delete this message. Thank you for your cooperation.
> +=========================================================+

If your mails are confidential, you probably want to stop sending them
to a public mailing list. If not, you'll want to omit this message.
--
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

[Paul Wouters]

> On Oct 25, 2017, at 22:03, Ronald Tse <***@ribose.com> wrote:
>
>
> I think we are slightly confusing an optional algorithm, which OCB is proposed to be, with a mandatory one.

For IETF standards, optional or mandatory to implement, it should be unencumbered and free to use.

> A user should be able to specify in their preferences that they don’t accept OCB. A .mil email address will probably specify they do not want OCB in this case.

This is not unencumbered or free to use and should disqualify this algorithm for IETF.

> For example, Chinese cryptography law strictly forbids AES usage in hardware. Does that mean Intel needs to drop AES-NI for chips sold in China? The answer is no. People simply don’t use it because of these regulations.

This example is wrong. IETF does not control other entities. It only controls itself and set rules for itself. And one of those rules is “free, gratis and unencumbered”.

> This is the same with OCB

It is not, as you explain above.

Paul

[Werner Koch]

On Fri, 27 Oct 2017 02:26, ***@nohats.ca said:

> For IETF standards, optional or mandatory to implement, it should be unencumbered and free to use.

rfc2440 and rfc4880 both included IDEA as a SHOULD algorithm despite
that IDEA was patent encumbered. Also RSA was patent encumbered when
2440 was published and nevertheless a SHOULD algorithm.

Ronald proposed OCB as a MAY algorithm so that by the time the patent
expires it can be used. We will anyway require a couple of years before
a new algorithm can be used. It is up to the implementation to announce
support for certain algorithms.


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

[Peter Gutmann]

Werner Koch <***@gnupg.org> writes:

>rfc2440 and rfc4880 both included IDEA as a SHOULD algorithm despite that
>IDEA was patent encumbered. Also RSA was patent encumbered when 2440 was
>published and nevertheless a SHOULD algorithm.

They were there because there wasn't much choice. PGP 2.0 used IDEA and RSA,
so it had to be kept around for future versions, although it was only a
SHOULD, not a MUST. With OCB in contrast you're introducing a new patent-
encumbered algorithm for no obvious reason.

If you really want the protection that OCB offers then encrypt-then-MAC is a
totally unencumbered way of doing the same thing. It's been in S/MIME for
years.

Peter.

[Ronald Tse]

Thank you Werner for the supporting comment. Seeing the comments I think we all agree that OCB is a great AEAD mode, and the only concern is about its IP.

1. A number of statements have been made regarding IETF standards and patents, but those statements do not necessary reflect today’s reality.

IETF’s IPR page details its stance towards IP and specifically, patents. There does not seem to be no requirement that the standard is “unencumbered”, “free” or “gratis”. The requirement is that licenses must be granted in a non-discriminatory way.

In the IETF’s IPR disclosure listing (https://datatracker.ietf.org/ipr/), you can find quite a few examples of newly published RFC documents that are clearly covered by issued patents, with no “indemnification” for implementers.

In fact, RFC 8179 clarifies the following for a Standards Track document:
----
9. Licensing Requirements to Advance Standards Track IETF Documents

Section 2.2 of RFC 6410 [RFC6410] states:

If the technology required to implement the specification requires
patented or otherwise controlled technology, then the set of
implementations must demonstrate at least two independent,
separate and successful uses of the licensing process.

A key word in this text is "requires". The mere existence of
disclosed IPR does not necessarily mean that licenses are actually
required in order to implement the technology.
----

For RFC 8179 compliance, there are already 3 licenses issued on Rogaway’s web site, and many others that are not shown there. This means that incorporating OCB in the 4880 document would NOT affect its status as a Standard.


2. There has been some misunderstanding regarding the OCB license coverage.

a. OCB is already shipped in Red Hat and Debian today in the OpenSSL and Botan cryptographic libraries.

b. Linking and distribution of any closed-source software with an open-source software (OCB License 2: as defined by the FSF, including BSD, GPL licenses), is already an accepted, licensed use of OCB.

In all of Brian’s examples, linking or distribution of “any closed-source software shipped on that system or any non-open-source custom-built apps” that utilize an OCB-enabled open-source crypto library, is explicitly allowed by License 2.


3. The misunderstanding that OpenPGP implementers will not implement OCB due to IPR disclosures.

Werner of GnuPG, has already indicated support to OCB on multiple occasions. Our own open-source OpenPGP implementation, RNP, will implement OCB. Anyone that uses popular cryptographic libraries like OpenSSL and Botan can already implement this and is covered by the licenses.

Again, OCB is proposed to be a MAY algorithm, not a MUST or even a SHOULD — if someone doesn't like it, there is no need to prevent others from using it.


Thanks for the comments.

Ron


_____________________________________

Ronald Tse
Ribose Inc.



On Oct 27, 2017, at 4:46 PM, Peter Gutmann <***@cs.auckland.ac.nz<mailto:***@cs.auckland.ac.nz>> wrote:

Werner Koch <***@gnupg.org<mailto:***@gnupg.org>> writes:

rfc2440 and rfc4880 both included IDEA as a SHOULD algorithm despite that
IDEA was patent encumbered. Also RSA was patent encumbered when 2440 was
published and nevertheless a SHOULD algorithm.

They were there because there wasn't much choice. PGP 2.0 used IDEA and RSA,
so it had to be kept around for future versions, although it was only a
SHOULD, not a MUST. With OCB in contrast you're introducing a new patent-
encumbered algorithm for no obvious reason.

If you really want the protection that OCB offers then encrypt-then-MAC is a
totally unencumbered way of doing the same thing. It's been in S/MIME for
years.

Peter.
_______________________________________________
openpgp mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/openpgp

[Hanno Böck]

On Fri, 27 Oct 2017 10:12:51 +0000
Ronald Tse <***@ribose.com> wrote:

> Again, OCB is proposed to be a MAY algorithm, not a MUST or even a
> SHOULD — if someone doesn't like it, there is no need to prevent
> others from using it.

I'd like to support what Paul Wouters was saying earlier in this thread.

Don't add multiple algorithms unless there isn't a very good reason for
it. Add one that is good for everything. Having a "may" algorithm only
adds unneeded complexity that is more likely to cause any security
issues than any potential disadvantage any modern AEAD has.

The GPG protocol is far more complex than it has to be.


One more note: Given that I don't see a particular rush in getting a
new RFC out you may simply wait for the CAESAR competition and choose
one of the resulting AEADs.

--
Hanno Böck
https://hboeck.de/

mail/jabber: ***@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[Werner Koch]

On Fri, 27 Oct 2017 12:38, ***@hboeck.de said:

> Don't add multiple algorithms unless there isn't a very good reason for
> it. Add one that is good for everything. Having a "may" algorithm only

There is a good reason for adding a MAY mode:

- We want an AEAD mode.
- The WG seems not to like OCB for political (patent) reasons.
- Thus the proposed solution is to require EAX but prepare for other
modes.
- OCB has been suggested as such another mode.
- We can add it to rfc4880bis as MAY mode to give a specification in
case someone will implement it anyway.

Consider what will happen if we don't do this: OCB may be implemented
anyway but at best an I-D extending RFC4880bis is used as specification.
Or worse, there is no spec at all and everyone implements it in slightly
different ways.

Also: The first revisions of I-Ds for RFC6637 (ECC for OpenPGP)
specified _only_ NIST curves and didn't allowed for any other curves.
This has been challenged and fortunately RFC6637 allows for arbitrary
curves, albeit less well specified. Without that semi-MAY we would not
have been able to deploy software using modern curves. Patents on ECC
are still a minefield but nevertheless everyone is moving towards ECC.

> The GPG protocol is far more complex than it has to be.

You mean OpenPGP.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

[Ronald Tse]

Thank you Werner, I share the same opinion.

One-size-fits-all is often a misnomer. I believe having an option is usually better than not having one.

_____________________________________

Ronald Tse
Ribose Inc.

> On Oct 27, 2017, at 7:07 PM, Werner Koch <***@gnupg.org> wrote:
>
> On Fri, 27 Oct 2017 12:38, ***@hboeck.de said:
>
>> Don't add multiple algorithms unless there isn't a very good reason for
>> it. Add one that is good for everything. Having a "may" algorithm only
>
> There is a good reason for adding a MAY mode:
>
> - We want an AEAD mode.
> - The WG seems not to like OCB for political (patent) reasons.
> - Thus the proposed solution is to require EAX but prepare for other
> modes.
> - OCB has been suggested as such another mode.
> - We can add it to rfc4880bis as MAY mode to give a specification in
> case someone will implement it anyway.
>
> Consider what will happen if we don't do this: OCB may be implemented
> anyway but at best an I-D extending RFC4880bis is used as specification.
> Or worse, there is no spec at all and everyone implements it in slightly
> different ways.
>
> Also: The first revisions of I-Ds for RFC6637 (ECC for OpenPGP)
> specified _only_ NIST curves and didn't allowed for any other curves.
> This has been challenged and fortunately RFC6637 allows for arbitrary
> curves, albeit less well specified. Without that semi-MAY we would not
> have been able to deploy software using modern curves. Patents on ECC
> are still a minefield but nevertheless everyone is moving towards ECC.
>
>> The GPG protocol is far more complex than it has to be.
>
> You mean OpenPGP.
>
>
> Shalom-Salam,
>
> Werner
>
> --
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
> _______________________________________________
> openpgp mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp

[Werner Koch]

Hi!

[I am only wearing my GnuPG maintainer's hat right now.]

On Fri, 27 Oct 2017 12:12, ***@ribose.com said:

> Again, OCB is proposed to be a MAY algorithm, not a MUST or even a SHOULD — if someone doesn't like it, there is no need to prevent others from using it.

Well, I would like to implement OCB in GnuPG at least to be prepared for
the time after the patent(s) expiration. It will not be the default any
time soon.

I already remarked that I expect that it will take a couple of years
before gpg with _any_ AEAD mode will be widely enough deployed so that
an AEAD mode can actually be used. We have seen that it took many years
before we could enforce the MDC mode despite that there is a key flag
announcing it. It is unfortunate that we need to implement EAX for the
very same reason that PGP5 had to use DSA/Elgamal instead of RSA. But
delaying an AEAD mode even further would be worse.

The patent situation is actually different between RSA+IDEA and OCB.
For the former the holders of the patent went aggressively against
everyone using them. For the latter the patent holder(s) gave explicit
royalty free grants for almost all use cases. And the patents will
expire in a few years - modulo the usual uncertainty with the patent
system.

Peter suggested to use encrypt-then-MAC to avoid all problems. This
would require an entire different structure of the symmetric encryption
code and thus adds complexity for a theoretical benefit over the MDC
approach. We would still need to double process the data.

Having an option to allowing switch the AEAD mode will be easier than to
implement both, encrypt-then-MAC and one AEAD mode.



Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

[brian m. carlson]

On Fri, Oct 27, 2017 at 10:12:51AM +0000, Ronald Tse wrote:
> 3. The misunderstanding that OpenPGP implementers will not implement OCB due to IPR disclosures.

This has nothing to do with whether implementers will implement it.
This has to do with whether users will be willing to use a spec or
implementation that has patent concerns associated with it.

> Werner of GnuPG, has already indicated support to OCB on multiple
> occasions. Our own open-source OpenPGP implementation, RNP, will
> implement OCB. Anyone that uses popular cryptographic libraries like
> OpenSSL and Botan can already implement this and is covered by the
> licenses.

GnuPG relies on libgcrypt for cryptographic functionality. On Debian,
libgcrypt is linked into Xorg, which is often linked to proprietary
software such as graphics drivers. Since Debian cannot avail itself of
license 2 (because restrictions on military use are unacceptable) and
license 1 prohibits uses with proprietary software, Debian's GnuPG is
unlikely to have support for OCB unless Debian ships two separate copies
of libgcrypt. For the same reason, Ubuntu is also likely to have the
same policy.

I've filed a bug with Debian to bring this to their attention.

These are the kind of practical reasons that patented software is
problematic and should not be a part of any specifications. I don't
believe there's a consensus on adding this, since the groups seem at
best evenly split. Previous opinions in the working group were mostly
negative.

I remain wholly opposed to including OCB in the OpenPGP specification,
and if this specification should make it to last call with OCB included,
I will oppose it on those grounds.
--
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

[Ronald Tse]

It is of course an issue for implementer adoption as well as user adoption. If no one implements it, no user can use it, no matter how much they want it. And since there are people who want to implement this, I don’t think the intention of the spec is to stop implementers from doing so.

The stated concern is only about whether Debian will carry any cryptographic library that implements OCB. OpenSSL and Botan are both Debian packages that already contain OCB today, and it should not be different with libgcrypt. At least it seems that the other issues are addressed.

Everyone has different expectations of what the spec should be, or what IETF RFCs should be or should stand for. In this case, I do not believe the IETF publication process has anything to do with the objection of OCB. Especially in this case, the patent owner has already demonstrated strong history of allowing open source usage.

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.

_____________________________________

Ronald Tse
Ribose Inc.

On Oct 28, 2017, at 8:33 AM, brian m. carlson <***@crustytoothpaste.net<mailto:***@crustytoothpaste.net>> wrote:

On Fri, Oct 27, 2017 at 10:12:51AM +0000, Ronald Tse wrote:
3. The misunderstanding that OpenPGP implementers will not implement OCB due to IPR disclosures.

This has nothing to do with whether implementers will implement it.
This has to do with whether users will be willing to use a spec or
implementation that has patent concerns associated with it.

Werner of GnuPG, has already indicated support to OCB on multiple
occasions. Our own open-source OpenPGP implementation, RNP, will
implement OCB. Anyone that uses popular cryptographic libraries like
OpenSSL and Botan can already implement this and is covered by the
licenses.

GnuPG relies on libgcrypt for cryptographic functionality. On Debian,
libgcrypt is linked into Xorg, which is often linked to proprietary
software such as graphics drivers. Since Debian cannot avail itself of
license 2 (because restrictions on military use are unacceptable) and
license 1 prohibits uses with proprietary software, Debian's GnuPG is
unlikely to have support for OCB unless Debian ships two separate copies
of libgcrypt. For the same reason, Ubuntu is also likely to have the
same policy.

I've filed a bug with Debian to bring this to their attention.

These are the kind of practical reasons that patented software is
problematic and should not be a part of any specifications. I don't
believe there's a consensus on adding this, since the groups seem at
best evenly split. Previous opinions in the working group were mostly
negative.

I remain wholly opposed to including OCB in the OpenPGP specification,
and if this specification should make it to last call with OCB included,
I will oppose it on those grounds.
--
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

[Paul Wouters]

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

[Derek Atkins]

Paul Wouters <***@nohats.ca> writes:

> 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?

Yes, they do. "Preferred algorothm notations".

-derek

--
Derek Atkins 617-623-3745
***@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant

[Gregory Maxwell]

On Sat, Oct 28, 2017 at 8:23 AM, Paul Wouters <***@nohats.ca> 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. :)

[Paul Wouters]

On Tue, 31 Oct 2017, Gregory Maxwell wrote:

As the signaling of support for algorithms is better then I realised,
I'll let myself be convinced that adding a new algorithm isn't too
bad. While I still think there is an increased risk of non-interoperability
or non-adoption, I guess it is not a deal breaker for new algorithms.

>> 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.

This is still a potential issue. As long as the algorithm has restrictions
on it that are discriminatory, their inclusion in a free software library
poses a risk for those companies shipping the software that have money
in the bank to attract lawsuits.

I'm worried about OCB support in openssl and/or other libraries as
part of the OS, because when a vendor's customers will use it for some
"unauthorised use", the vendor might get involved in a lawsuit.

I'm also confused about these restrictions. If opensource is allowed to
use it, anyone could use openssl under the newly minted (still minting?)
license to link against properietary code, meaning that there are in
practise, no restrictions left. So why doesn't Rogaway just release an
IPR statement to the IETF allowing its free and unrestrictive use?

Rich, do you know anything about the OCB code in openssl and how the
relicensing of openssl would mean the OCB code can remain or has to go?

Paul

[Ronald Tse]

I’m sure Rich could shine more light on this, but OpenSSL has already received a specific OCB license from Prof. Rogaway that allows users of OpenSSL to use OCB freely, including when linked against proprietary code (It’s on the OpenSSL website). Note that the OpenSSL license is more broad than License 1 and 2 on the OCB FAQ page.

As mentioned, Prof. Rogaway is willing to file an IPR statement allowing the use of OCB for all OpenPGP implementations, so I think the patent issue can probably be put to rest here.

Ron

_____________________________________

Ronald Tse
Ribose Inc.

On Oct 31, 2017, at 3:03 PM, Paul Wouters <***@nohats.ca<mailto:***@nohats.ca>> wrote:

On Tue, 31 Oct 2017, Gregory Maxwell wrote:

As the signaling of support for algorithms is better then I realised,
I'll let myself be convinced that adding a new algorithm isn't too
bad. While I still think there is an increased risk of non-interoperability
or non-adoption, I guess it is not a deal breaker for new algorithms.

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.

This is still a potential issue. As long as the algorithm has restrictions
on it that are discriminatory, their inclusion in a free software library
poses a risk for those companies shipping the software that have money
in the bank to attract lawsuits.

I'm worried about OCB support in openssl and/or other libraries as
part of the OS, because when a vendor's customers will use it for some
"unauthorised use", the vendor might get involved in a lawsuit.

I'm also confused about these restrictions. If opensource is allowed to
use it, anyone could use openssl under the newly minted (still minting?)
license to link against properietary code, meaning that there are in
practise, no restrictions left. So why doesn't Rogaway just release an
IPR statement to the IETF allowing its free and unrestrictive use?

Rich, do you know anything about the OCB code in openssl and how the
relicensing of openssl would mean the OCB code can remain or has to go?

Paul

[Paul Wouters]

On Tue, 31 Oct 2017, Ronald Tse wrote:

> I’m sure Rich could shine more light on this, but OpenSSL has already received a specific OCB license from Prof. Rogaway that allows users of OpenSSL to use OCB freely, including when
> linked against proprietary code (It’s on the OpenSSL website). Note that the OpenSSL license is more broad than License 1 and 2 on the OCB FAQ page.
> As mentioned, Prof. Rogaway is willing to file an IPR statement allowing the use of OCB for all OpenPGP implementations, so I think the patent issue can probably be put to rest here.

The recent I'm asking is because openssl is being relicensed and I don't
know how this affects things.

As for getting a license for openpgp (and TLS), putting support in a
general library where it can be used for other things is still an issue
that needs to be looked at by lawyers, not engineers. And since that
in itself will impact whether OCB would be made available in generic
distributions, I don't think this issue can be put to rest yet.

Paul

[Salz, Rich]

➢ The recent I'm asking is because openssl is being relicensed and I don't
know how this affects things.

Based on our counsel, the planned change to Apache2 license will not change any patent grants we have been given.

[Werner Koch]

<offtopic>

On Sat, 28 Oct 2017 02:33, ***@crustytoothpaste.net said:

> GnuPG relies on libgcrypt for cryptographic functionality. On Debian,
> libgcrypt is linked into Xorg, which is often linked to proprietary
> software such as graphics drivers. Since Debian cannot avail itself of

There are no proprietary drivers in Debian. Further it is not instantly
possible to decide what makes up a derivative work, "linking" would be
just one data point but even that term "linking" is not well defined.

> license 1 prohibits uses with proprietary software, Debian's GnuPG is
> unlikely to have support for OCB unless Debian ships two separate copies

GnuPG already uses OCB for the private key storage format and will
protect keys using this format if you use --enable-extended-key-format.
Eventually this will be the default key storage format for private keys.

</>

> I remain wholly opposed to including OCB in the OpenPGP specification,

Do you prefer that we put a "2 - reserved for OCB" into the specs and
have an I-D to specify the oue of OCB in OpenPGP? This would make the
life for implementors and auditors harder.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

[brian m. carlson]

On Tue, Oct 31, 2017 at 04:44:23PM +0100, Werner Koch wrote:
> > I remain wholly opposed to including OCB in the OpenPGP specification,
>
> Do you prefer that we put a "2 - reserved for OCB" into the specs and
> have an I-D to specify the oue of OCB in OpenPGP? This would make the
> life for implementors and auditors harder.

Yes, I would much prefer that we let OCB happen in a separate draft.
Then all the patent problems occur in a separate specification that
doesn't affect the core OpenPGP.
--
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

[Derek Atkins]

"brian m. carlson" <***@crustytoothpaste.net> writes:

> On Tue, Oct 31, 2017 at 04:44:23PM +0100, Werner Koch wrote:
>> > I remain wholly opposed to including OCB in the OpenPGP specification,
>>
>> Do you prefer that we put a "2 - reserved for OCB" into the specs and
>> have an I-D to specify the oue of OCB in OpenPGP? This would make the
>> life for implementors and auditors harder.
>
> Yes, I would much prefer that we let OCB happen in a separate draft.
> Then all the patent problems occur in a separate specification that
> doesn't affect the core OpenPGP.

I don't think you understand the relationship between the specification
and IP. Specifically, whether OCB is in the main spec or a secondard
spec does not affect any IP/patent "problems". Put another way,
IP/patent "problems" occur for anyone who wants to implement OCB,
regardless of where it is specified. However having it in the main
draft makes it easier to implement and audit, as Werner suggested. The
more places you have to reference, the more likely you'll make a
mistake.

Note that just because OCB is in the spec does not mean you must
implement it -- it's not going in as a MUST. If you don't implement it,
then there is no IP/patent worry on your part.

-derek

--
Derek Atkins 617-623-3745
***@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant

[brian m. carlson]

On Wed, Nov 01, 2017 at 10:35:59AM -0400, Derek Atkins wrote:
> "brian m. carlson" <***@crustytoothpaste.net> writes:
> > Yes, I would much prefer that we let OCB happen in a separate draft.
> > Then all the patent problems occur in a separate specification that
> > doesn't affect the core OpenPGP.
>
> I don't think you understand the relationship between the specification
> and IP. Specifically, whether OCB is in the main spec or a secondard
> spec does not affect any IP/patent "problems". Put another way,
> IP/patent "problems" occur for anyone who wants to implement OCB,
> regardless of where it is specified. However having it in the main
> draft makes it easier to implement and audit, as Werner suggested. The
> more places you have to reference, the more likely you'll make a
> mistake.

No, I completely understand it. I strongly feel that OCB doesn't belong
in the main draft so we have a simple, complete, unencumbered spec.
Then it's very easy to avoid all the uncertainty (and there is a lot) on
OCB by simply not implementing the additional spec. People can
implement the entire main RFC without having to even think about
patents, and that's valuable.

Otherwise, people have to end up explaining that yes, we implement the
spec, but no, we don't implement the patented parts, and that the spec
is implementable without the patented parts, and so on and so forth. I
anticipate that this is a conversation that numerous people, not just
me, are going to have with company lawyers.

I strongly believe that our spec should be unencumbered. I am still
strongly opposed to OCB because it's patented, but if it lives in a
separate spec, it's easy enough to just say, "Don't implement that RFC."
--
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204