Re: [openpgp] Padding packets

[Stephen Farrell <[e-mail]>]

I guess we're not yet quite done with this one,
so let's schedule it for discussion at IETF114.

Cheers,
S

On 15/07/2022 11:45, Stephen Farrell wrote:
> 
> Hi Folks,
> 
> I created a gitlab issue for this one. [1] Let's see if
> we've actually got rough consensus on it though...
> 
> If I were to suggest that we've converged onto merge
> request 204 ([2], use zeros for padding, recommend not
> compressing them) would I be wrong? Please correct me
> if so before Tuesday 19th if you can.
> 
> If nobody has a problem with that we can ask the
> editors to try merge [2].
> 
> Thanks,
> Stephen.
> 
> [1] https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/132
> [2] https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/204
> 
> 
> 
> On 15/06/2022 12:29, Werner Koch wrote:
>> Hi!
>>
>> The idea of a padding packet is in general a good idea and has been
>> discussed many times:
>>
>>     5.14.  Padding Packet (Tag 21)
>>
>>     The Padding packet contains random data, and can be used to defend
>>     against traffic analysis (see Section 14.10) on version 2 SEIPD
>>     [...]
>>     Its contents SHOULD be random octets to make the length obfuscation
>>     it provides more robust even when compressed.
>>
>> The problem with random padding packets is that this opens a high
>> capacity channel with all its problems.  Having this in the protocol is
>> a problem because applications taking care not to leak too much
>> information will need to reject such messages and inform the user about
>> a possible problem.
>>
>> Please drop this.  A better mechanism to add padding is by handling this
>> at the MIME layer.  In any case, a well defined pseudo-random generator
>> is required.
>>
>> At this opportunity I checked the Literal Data packet and unfortunately
>> noticed that not only the 'u' has gone but also the 'm' which we
>> introduced to declare MIME content to avoid relying on heuristics.  That
>> these flags are not included in the signed material is not a problem,
>> because they are only hints to the implementation.
>>
>>
>> Salam-Shalom,
>>
>>     Werner
>>
>>
>>
>> _______________________________________________
>> openpgp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/openpgp
> 
> _______________________________________________
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp