Re: [TLS] Review of draft-ietf-tls-rfc4366-bis-04

[Eric Rescorla <ekr at networkresonance.com>]

At Sat, 25 Apr 2009 00:46:58 +0200,
Simon Josefsson wrote:
> 
> "Joseph Salowey (jsalowey)" <jsalowey at cisco.com> writes:
> 
> > This is a working group last call for comments on
> > draft-ietf-tls-rfc4366-bis-04 prior to sending this document on to the
> > IESG for publication as a proposed standard RFC.  The document and
> > revision history can be found here:
> >
> > http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-04
> >
> >
> > Please send any comments to the list by May 15, 2009.  
> 
> Hi.  The document looks good in general, however I have two comments:
> 
> 1)
> 
> RFC 4366 contains:
> 
>       struct {
>           opaque url<1..2^16-1>;
>           Boolean hash_present;
>           select (hash_present) {
>               case false: struct {};
>               case true: SHA1Hash;
>           } hash;
>       } URLAndOptionalHash;
> 
> The draft changes the struct to:
> 
>       struct {
>           opaque url<1..2^16-1>;
>           opaque SHA1Hash[20];
>       } URLAndHash;
> 
> An RFC 4366 implementation that receives a RFC4366bis struct will reject
> the encoding as corrupt, and possibly refuse the connection.
> 
> Likewise, an RFC 4366bis implementations will reject a RFC4366 struct.
> 
> It is possible to implement a parser that will accept both structs, but
> this is not discussed nor suggested by the document.
> 
> I suggest that a padding byte is inserted as follows:
> 
>       struct {
>           opaque url<1..2^16-1>;
>           opaque padding<1>;
>           opaque SHA1Hash[20];
>       } URLAndHash;
> 
> And some text is added:
> 
>    The "padding" byte MUST be 0x01.  It is present to make the structure
>    backwards compatible.
> 
> TLS 1.2 also changed old structs, let's not make the same mistake again.

Oh, good catch.

I would leave it as-is in 4366 and simply say // Must be true...

-Ekr