At Thu, 28 Feb 2019 10:39:17 -0800,
Jon Callas wrote:
On Feb 28, 2019, at 12:51 AM, Neal H. Walfield
<neal(_at_)walfield(_dot_)org> wrote:
So I think that a SHOULD is the right way to put it. I care less
about what the SHOULD limit should be, but a small hard limit sounds
like a bad idea.
Do you still think a hard upper limit is a bad idea?
No, I don’t think a hard upper limit is a bad idea. In the text you quote
above, I said a *small* hard upper limit. And no, I don’t know what small
means. I think 16K is small. 256K might be small. AES-GCM has issues about
64G. One might argue that’s a reasonable large upper limit. Me, I think
anything in the few megabytes to a gigabyte-ish is just fine.
Let me rewind a bit and get to my real point which I don’t think I’m making
well.
When one creates a standard, one needs to be careful with
parameters, particularly the MUSTs. Seemingly sensible things can
have downstream effects that convince people to use some other
protocol. Worse, someone’s angry blog post about something can
quickly go into “not even wrong” territory and embed itself into
folklore and you can’t get it out. There are plenty of bad ideas
that someone else has a really reasonable use case for.
There are always going to be haters.
...
This has never caused a problem that I’m aware of. I’m sure it caused a
problem that none of us are aware of, and the implementors just solved it on
their own. It is this experience that has me wondering about what the
restrictions out to be.
The best way to deal with it in a standard is to have non-normative guidance.
It is non-normative guidance that I was suggesting. Let me write an example
bit of non-normative guidance below:
...
I think that security concerns should be our first priority. And, any
flexibility increases our bug potential. As such, I'm not convinced
that we shouldn't use a fixed chunk size. If in a few years, if we
decide that the size is wrong, then we can just define a new mode,
which uses a different chunk size. In my opinion, it should be
impossible represent something that we want to disallow.
If we are really worried about the haters, then let's just deflect the
criticism: let's use 16 kiB chunks like TLS, as Marcus previously
pointed out:
https://mailarchive.ietf.org/arch/msg/openpgp/t79iRZ80KHuVTEyVVLAoCLl4Rwc
From RFC 8446:
5.2. Record Payload Protection
length: The length (in bytes) of the following
TLSCiphertext.encrypted_record, which is the sum of the lengths of
the content and the padding, plus one for the inner content type,
plus any expansion added by the AEAD algorithm. The length
MUST NOT exceed 2^14 + 256 bytes. An endpoint that receives a
record that exceeds this length MUST terminate the connection with
a "record_overflow" alert.
https://tools.ietf.org/html/rfc8446#section-5.2
(A record the approximate equivalent of a chunk.)
The Partial Body Lengths that OpePGP has had from the beginning have no
restrictions on them. There’s non-normative guidance that pretty much says
you shouldn’t even use them, but there’s no restriction on size.
I just reread and I don't think it suggests that Partial Body Lengths
should not be used.
https://tools.ietf.org/html/rfc4880#section-4.2.2.4
Can you point me to this guidance? This is the first time I hear that
chunking is considered to be a bad idea.
Thanks,
:) Neal
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp