Subject: Re: [openpgp] Modernizing the OpenPGP Format draft

From: ianG <[email-masked]>
Date: Mon, 2 Nov 2015 22:05:52 +0000

Excellent start!

On 31/10/2015 08:50 am, Bryan Ford wrote:
> Title: Modernizing the OpenPGP Message Format
> URL: https://datatracker.ietf.org/doc/draft-ford-openpgp-format/
> Abstract:
>     This draft proposes and solicits discussion on methods of modernizing
>     OpenPGP's encrypted message format to support more state-of-the-art
>     authenticated encryption schemes, and optionally to protect format
>     metadata as well as data via metadata encryption and judicious
>     padding.

I object to the use of the word "identity" in the text.  Wrong layer. 
I'd suggest either integrity or authentication?

I like the absolute separation of the the AEAD Protected Data packet - 
makes it easier to squash all the old stuff.

"additional data" == 0.  I'm fine with that.

nonce as 0 for non-reuse - disagree.  I would strongly prefer the nonce 
to always be there and always be randomly generated by requirement, 
because we can't trust the rest of the software.  Multiple, redundant 
protections are great when they are free.  Which they are in this case. 
  Nonce to be always present, big and random, and the secret key should 
not be re-used.

2.2 looks great!  Never heard of MonkeyDunkey but happy to endorse it 
sight unseen ;-)

> It covers two topics, the first being the AEAD evolution, the second
> being a somewhat more ambitious idea to provide better metadata
> protection and anonymization properties at the "outer-wrapper" level;
> see the draft for (some more, still sketchy) details.

2.3 also good, I'm very keen on that. The "bucket expansion" scheme is 
likely to signal which tool was used, unless we can convince other 
packages to do that (pretty unlikely).

iang

---

From: Bryan Ford <[email-masked]>
Date: Tue, 3 Nov 2015 08:30:26 +0900

Thanks Ian for the great feedback.

Indeed, I think in all the places the draft says ‘identity protection’ it should say ‘integrity protection’, sorry about the confusion.  That was just me mixing up i-words as I was deliriously hammering out text half an hour before the I-D submission deadline. ;)

> On Nov 3, 2015, at 7:05 AM, ianG <[email-masked]> wrote:
> nonce as 0 for non-reuse - disagree.  I would strongly prefer the nonce to always be there and always be randomly generated by requirement, because we can't trust the rest of the software.  Multiple, redundant protections are great when they are free.  Which they are in this case.  Nonce to be always present, big and random, and the secret key should not be re-used.

That’s completely reasonable, and I’d be fine with that in the interest of caution and bug-resilience.

> 2.3 also good, I'm very keen on that. The "bucket expansion" scheme is likely to signal which tool was used, unless we can convince other packages to do that (pretty unlikely).

Great.  My hope is that if we were to specify the padding/bucket-expansion mechanism in a separate document in an application-neutral way and with the relevant theory spelled out, we might eventually be able to convince other applications to use or migrate to such a scheme too.  But that would be a long-term goal, and whether or not it happens it would have to start somewhere, and to me OpenPGP seems like a reasonable place for it to start. ;)

By the way, I have a draft-of-a-draft of a document with more details on the metadata protection and padding schemes I have in mind; it obviously didn’t make the I-D deadline and still has major holes but I’m happy to share it informally with anyone interested.

Cheers
Bryan

---

From: ianG <[email-masked]>
Date: Mon, 2 Nov 2015 23:40:27 +0000

> Great.  My hope is that if we were to specify the padding/bucket-expansion mechanism in a separate document in an application-neutral way and with the relevant theory spelled out, we might eventual…

Right that's what I was thinking - write a separate draft listing an 
algorithm to determine next padded length to aim for.

I'd actually suggest slightly table driven:

512
1024
1500 (ethernet or the old UDP packet length)
4096
16k
64k (jumbo packet)
...

iang