[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

padding values

On the differences in text on padding values:

> From: Bob Monsour <rmonsour@earthlink.net>
> While I understand that you believe that it's important for the
> algorithm/transform documents to repeat certain field definitions from the
> base ESP document, in this case I find it couter-productive and prone to
> inducing errors. Let's take an example from from your DES draft
> (draft-simpson-esp-des1-v2-00.txt) and compare it to the "new" ESP draft
> and RFC1829. It states:
>
>    Padding          zero or more octets.
>
>                     Prior to encryption, this field is filled with a
>                     series of integer values (beginning with zero), to
>                     align the Pad Length and Payload Type fields at the
>                     end of an eight octet boundary (counted from the
>                     beginning of the Payload Data).
>
>                     After decryption, it is examined for a valid series
>                     of integer values.
>
>                     This field is opaque.  That is, the value is set
>                     prior to encryption, and is examined only after
>                     decryption.
>
Please read this in the context of the whole paper.  See also:

2.2.  Decryption
...
   The Pad Length is removed and examined.  If pad checking is config-
   ured, and the padding octets are not the correct values for the Pad
   Length, then the payload is discarded, and the "Decryption Failed"
   error is indicated [RFC-xxxx].
...

Operational Considerations
...
   Pad Check
      Some earlier implementations used random pad values.

      Default: Off.
...

The default is off because of interoperability concerns.


> In the "new" ESP draft (section 2.5) padding is defined as follows:
>
>    The Padding bytes SHOULD be initialized with random data and they are
>    transmitted. The transmitter can add 0-255 bytes of padding.  Padding
>    beyond that required for encryption algorithm blocksize alignment may
>    be used to conceal the actual length of the payload, in support of
>    traffic flow confidentiality.  However, inclusion of such additional
>    padding has adverse bandwidth implications and thus its use should be
>    undertaken with care.  The Padding field is optional, but all
>    implementations MUST support generation and consumption of padding.
>
The ESP draft is wrong.  It has a scoping error.  The description of
padding is to be left to the individual transforms.  See the previous
notes to this list on the implementors' agreement.

If this is not fixed in the next draft of ESP, I'm sure someone will
suggest a more specific change in wording.


> Lastly, RFC1829 states:
>
>    Padding
>
>       The size of this field is variable.
>
>       Prior to encryption, it is filled with unspecified implementation
>       dependent (preferably random) values, to align the Pad Length and
>       Payload Type fields at an eight octet boundary.
>
>       After decryption, it MUST be ignored.
>
> I don't understand how someone can write code to support the padding
> requirements that conform to RFC1829 or the "new" ESP and find that it will
> interoperate with code that is written to follow your new draft. An RFC1829
> programmer will send the "preferably random" values in for padding and the
> implementor of your new draft will reject the incoming packet for lack of a
> "valid series of integer values". While you don't say exactly what to do in
> this case, it certainly leaves room for various interpretations (read that
> as potential interoperability problems).
>
Hopefully, not everyone will read only the first part of a draft, and
will actually follow and implement the draft in its entirety.

The values were previously "implementation dependent", which was open to
various interpretations.

The "preferably random" values turned out to be cryptographically wrong.

At the request of the persons explicitly named in the Acknowledgements,
the "implementation dependent" values were changed to specified values.
This is not open to various interpretations.

I realize that you are new to the list, and may have missed the earlier
debates.

Remembering that you like to use the same technique in multiple venues,
I'll point out that these values are used in PPP DES encryption.  And
that non-random values are also specified in RSA's PKCS.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: