Re: [PATCH 2/3] Store header and trailer byte counts in schan_context for future use

[Henri Verbeet]

On 30 August 2010 18:37, Mikko Rasa  wrote:
> -
>        ctx->trailer_bytes = pgnutls_mac_get_key_size(pgnutls_mac_get(ctx->session));

...
> - stream_sizes->cbHeader = 5;
> - stream_sizes->cbTrailer = mac_size + 256; /* Max 255 bytes padding + 1 for padding size */
> - stream_sizes->cbHeader = ctx->header_bytes;
> - stream_sizes->cbTrailer = ctx->trailer_bytes;

Does this imply TLS record padding should be disabled? I imagine an
encrypted message may not fit in the application provided buffers
otherwise.

[PATCH 2/3] Store header and trailer byte counts in schan_context for future use

[Mikko Rasa]

On 31.08.2010 16:16, Henri Verbeet wrote:
> On 30 August 2010 18:37, Mikko Rasa  wrote:
> > -
> >        ctx->trailer_bytes = pgnutls_mac_get_key_size(pgnutls_mac_get(ctx->session));
>
> ...
> > -
> >        stream_sizes->cbHeader = 5;
> > -
> >        stream_sizes->cbTrailer = mac_size + 256; /* Max 255 bytes padding + 1 for padding size */
> > -
> >        stream_sizes->cbHeader = ctx->header_bytes;
> > -
> >        stream_sizes->cbTrailer = ctx->trailer_bytes;
>
> Does this imply TLS record padding should be disabled? I imagine an
> encrypted message may not fit in the application provided buffers
> otherwise.

That was originally so I could determine the end of the message and fill 
a SECBUFFER_EXTRA buffer if there's any leftover data (probably because 
the input buffer contained part of the next message).  However, since I 
had to do my own TLS frame decoding anyway in a later patch, I don't 
really need to know the MAC size anymore.

I'll produce a revised patchset shortly, taking into account Hans's 
feedback as well.