Subject: [TLS] renegotiation draft needs clarification !!

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 11 Nov 2009 17:29:30 -0800

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.

/Nelson

---

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 11 Nov 2009 17:48:26 -0800

> "the contents of the extension data field", to make this sufficiently

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.

Wan-Teh

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 11 Nov 2009 18:27:24 -0800

> 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.

/Nelson

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 11 Nov 2009 19:46:10 -0800

>>> This leads to two different encodings, which are:
>>>
>>>  FF 01 00 00
>>>
>>>  FF 01 00 01 00

I will selfishly vote for the second choice since that is
how I implemented it, though it would be easy to change.

Mike

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 12 Nov 2009 04:10:16 +0000

>>>> This leads to two different encodings, which are:

Good catch.

> how I implemented it, though it would be easy to change.

The second choice is slightly more regular, in that the empty and
non-empty versions of the extension data have the same type.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 11 Nov 2009 20:23:28 -0800

>>>>> This leads to two different encodings, which are:

I can't take credit for finding that -- it was Nelson.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Nov 2009 08:16:36 +0200

At Wed, 11 Nov 2009 18:27:24 -0800,
> 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

---

From: Nasko Oskov <[email-masked]>
Date: Thu, 12 Nov 2009 07:52:38 +0000

>how I implemented it, though it would be easy to change.

I interpreted it the same way, as an empty vector.
Thanks,	
Nasko

---

From: Michael Gray <[email-masked]>
Date: Thu, 12 Nov 2009 18:36:06 +1000

> I interpreted it the same way, as an empty vector.

Same here

Mick

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls