Re: [TLS] renegotiation draft needs clarification !!

[Eric Rescorla <[e-mail]>]

At Wed, 11 Nov 2009 18:27:24 -0800,
Nelson B Bolyard wrote:
> 
> On 2009-11-11 17:48 PDT, Wan-Teh Chang wrote:
> > On Wed, Nov 11, 2009 at 5:29 PM, Nelson B Bolyard <[e-mail]> wrote:
> >> At least Two implementers have read the draft differently and implemented
> >> non-interoperable implementations.  The draft needs clarification.
> >>
> >> First the draft says:
> >>
> >>   The "extension data" field of this extension contains a
> >>   "Renegotiation_Info" structure:
> >>
> >>             struct {
> >>               opaque renegotiated_connection<0..255>;
> >>             } Renegotiation_Info;
> >>
> >> Then it says:
> >>
> >>   The contents of this extension are specified as follows.
> >>
> >>   o  If this is the initial handshake for a connection, then this field
> >>      is of zero length in both the ClientHello and the ServerHello.
> >>
> >> One implementer interprets this to mean that the extension data field
> >> is of zero length.  Another interprets it to mean that the
> >> "renegotiated_connection" field inside the Renegotiation_Info is to
> >> have zero length.  This leads to two different encodings, which are:
> >>
> >>  FF 01 00 00
> >>
> >>  FF 01 00 01 00
> >>
> >> I suggest replacing "the contents of this extension" with either
> >> "The contents of the renegotiated_connection", or
> >> "the contents of the extension data field", to make this sufficiently
> >> explicit.
> > 
> > This kind of ambiguity was also in the original RFC 4507 for
> > the TLS session ticket extension, and had to be addressed in
> > a new RFC 5077.  See RFC 5077 section 1 and appendix A.
> 
> Thanks for the tip, Wan-Teh.  So, summarizing that appendix, it says that
> clients have two different interpretations of an empty session ticket
> extension, so servers should accept either one and should return an
> empty extension in the same format as that sent by the client.
> 
> Fellow TLS WG members,
> Let's not repeat that for this extension.  This extension hasn't been
> published in an RFC yet, so let's nip this in the bud, and make it
> completely unambiguous before that happens.

I agree. I'll put it on my TODO list to fix this.

IMHO, the better interpretation is an empty vector (i.e. 00) for
the data field with an extension containing only that. I.e.

ff 01 00 01 00

-Ekr