Subject: RE: gssapi-cfx-04: padding size

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 2 Dec 2003 16:59:00 -0800

Ken Raeburn wrote:

>> ...and the extra trailing octets, generally padding added by the
>>    cryptosystem, we shall call "crypto-system garbage" in this
>>    document, to distinguish them from padding octets added by this
>>    GSSAPI mechanism.

Padding is generally associated with block ciphers, and it was my
intention to avoid that term here.

>> ...one can always find a (possibly larger, but by less than 64K)
>>    size such that, when the message data is padded to that size,
>>    there will....

But you really meant that delta is less than 64k.

So let's try this:

In 4.2.4.

    The result of decryption can be longer than the original plaintext 
   [KCRYPTO] and the extra trailing octets are called "crypto-system 
   garbage" in this document.  However, given the size of any plaintext 
   data, one can always find the next (possibly larger) size so that,
when 
   padding the to-be-encrypted text to that size, there will be no
crypto-
   system garbage added [KCRYPTO].

Note that the constrain described here is weaker than that of kcrypto
(for example, it does not mention the 64k limit), and I think that
should be ok because it is not the normative reference, but rather an
inference from kcrypto therefore it can be weaker, right? 

>> Section 5.2 says wrap tokens generated from a 16K octet input must be
>> handled.  It may be worth noting that the token could include nearly
>> 64K of padding, and thus the token itself may be over 80K.

This is theoretically possible but it does not happen with any existing
enctypes and won't happen with any future enctypes (IMHO).
gss_wrap_size_limit() should be helpful to find out the overhead of the
wrap tokens (SSPI exposes the overhead of Wrap tokens properly).

Thx,

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ken Raeburn
Sent: Tuesday, December 02, 2003 2:41 PM
To: [email-masked]
Subject: gssapi-cfx-04: padding size

Section 4.2.4 uses the phrase "crypto-system garbage".  I don't really
like the use of the word "garbage" here, and I've said that before,
but if you're going to use it, please rephrase it to indicate more
concisely that that is the term you're defining and using *in this
document*.  As it's phrased, I'd read it to mean that that's the term
for it defined elsewhere (which one would presume to be [KCRYPTO]
except I know that's not the case), and that you're just repeating the
definition for clarity.  Try something like this:

    ...and the extra trailing octets, generally padding added by the
    cryptosystem, we shall call "crypto-system garbage" in this
    document, to distinguish them from padding octets added by this
    GSSAPI mechanism.

Section 4.2.4 says "one can always find the next (possibly larger)
size so that...", but [KCRYPTO] just says that such a size must exist,
and be within a certain range; it doesn't suggest that the smallest
such length has to be easy to find.  That inconsistency is sort of
okay, I guess, since section 4.2.4 doesn't actually say that the
smallest such size has to be used; the third paragraph just requires
that there be no "garbage".  The smallest semantic change to clean
this up would be to rephrase the description in the second paragraph
to say something like:

    ...one can always find a (possibly larger, but by less than 64K)
    size such that, when the message data is padded to that size,
    there will....

Section 5.2 says wrap tokens generated from a 16K octet input must be
handled.  It may be worth noting that the token could include nearly
64K of padding, and thus the token itself may be over 80K.

Ken

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 2 Dec 2003 21:06:59 -0500

On Tuesday, Dec 2, 2003, at 19:59 US/Eastern, Liqiang((Larry)) Zhu 

> intention to avoid that term here.

Yes, I used "generally" to try to indicate that that doesn't have to be 
the reason.  Perhaps "often" would've been better.

> But you really meant that delta is less than 64k.

Yes, I thought "larger, but by less than 64K" meant that, but perhaps 
it was unclear.

> inference from kcrypto therefore it can be weaker, right?

You're still talking about the "next" size, suggesting that maybe we 
need to look for the smallest suitable size, but that is not actually a 
requirement in the current document.  I'd rather get rid of the word 
"next" and the confusion it might cause.

If you change "find the next (possibly larger) size" to "find a 
(possibly larger) size", that would be okay.

> wrap tokens (SSPI exposes the overhead of Wrap tokens properly).

Since the CFX draft doesn't require the minimum padding size be used, 
it can (and in the current MIT implementation I'm working on testing, 
*does*) happen.  It's a quality-of-implementation issue; in a 
production implementation, you don't want the excess padding, and a 
good implementation won't normally insert it, but you may want it if 
you're trying to test corner cases.

I don't consider the text for the draft to be all that important.  An 
implementation that doesn't handle 65535 bytes of padding is broken, 
but I expect the implementors will get it right.