[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ESP Pad byte changes
Paul, the requirement is as follows, per the latest ESP draft.
"The first padding byte appended to the plaintext is numbered 1, with
subsequent padding bytes making up a monotonically increasing sequence: 1,
2, 3, ... When this padding scheme is employed, the receiver SHOULD inspect
the Padding."
It's merely a SHOULD, not a MUST.
Regards,
-Bob
field.
-----Original Message-----
From: Paul Koning <pkoning@xedia.com>
To: skelly@redcreek.com <skelly@redcreek.com>
Cc: jhwilson@austin.ibm.com <jhwilson@austin.ibm.com>; ipsec@tis.com
<ipsec@tis.com>
Date: Thursday, April 09, 1998 1:25 PM
Subject: Re: ESP Pad byte changes
>>>>>> "Scott" == Scott G Kelly <skelly@redcreek.com> writes:
>
> Scott> Jackie Wilson wrote: <snip...>
> >> if it is not important from a security standpoint to have it,
> >> then why is it in the draft?
>
> Scott> One argument for using this mechanism is that filling the pad
> Scott> bytes with a predictable value prevents filling them with
> Scott> other things, i.e. leaking information. I'm not personally
> Scott> arguing for or against, just making an observation.
>
>That's an excellent argument for requiring the sending of some
>specified value. But I sure am puzzled about why there's a
>requirement (or even a suggestion) that it be checked on receive.
>
>Unless I'm missing something, the only thing that's necessary for
>packet parsing is that you have to be able to tell the length of the
>pad. The only additional property needed for security is that the pad
>must not be someone else's data.
>
>The current pad pattern certainly does both of these. Lots of other
>pad count plus pad data rules would work just as well -- e.g., pad
>data = constant byte N (any N), or random, or pseudorandom. But since
>the current pattern works, I wouldn't want to argue for changing it.
>
>On the other hand, I would like to know why the rule is that you MUST
>(rather than MAY) check the pad on receive.
>
> paul
>