[TLS] Interoperability testing for draft-ietf-tls-renegotiation-02.txt

Nelson B Bolyard <nelson@bolyard.me> Tue, 05 January 2010 20:08 UTC

Message-ID: <4B439C0E.6050003@bolyard.me>
Date: Tue, 05 Jan 2010 12:07:42 -0800
From: Nelson B Bolyard <nelson@bolyard.me>
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre
MIME-Version: 1.0
To: IETF TLS Working Group <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Eric Rescorla <ekr@rtfm.com>
Subject: [TLS] Interoperability testing for draft-ietf-tls-renegotiation-02.txt
Precedence: list

I have an implementation of a client which I believe conforms to that
draft.  I wish to test it against servers that also claim conformance,
both with SSL 3.0 and with TLS 1.0.

For TLS, I propose to send an initial TLS client hello with both SCSV
(cipher suite value 0x00ff) and empty RI extension (value 0xff01) (*).
If the server responds with a TLS server hello with an empty RI extension,
then following the completion of that handshake and sending of the https
request, to test renegotiation I would have my client do a subsequent
handshake with no SCSV and a "full" RI with a 12-byte TLS finished message
contents, and expect the server hello to bear a 24 byte RI with both
previous TLS finished message contents.

For SSL 3.0, I propose to send an initial SSL 3.0 client hello with SCSV
(cipher suite value 0x00ff) only, no empty RI.  If the server responds with
an SSL 3 server hello with an empty RI extension then following the
completion of that handshake and sending of the https request, I would have
my client do a subsequent SSL3 handshake with no SCSV and a "full" RI
extension with a 36-byte SSL3 finished message content, and expect the
server hello to bear a 72 byte RI with both previous TLS finished message
contents.

If that sounds right to you, and your server is willing to interoperate on
that basis, please let me know.  If that sounds wrong to you, please let me
know that, too.  :)

(*): My rationale for sending both SCSV and RI in the initial handshake,
when offering version TLS 1.0, is that, on the initial handshake, the
client does not yet know if the server is a TLS server or merely an SSL 3.0
server.  In the latter case, the server may be presumed to ignore hello
extensions (IINM) but to understand the SCSV.  If the server does handle
hello extensions, then presumably it will honor the empty RI (no?).
Please advise if I have misunderstood this point.

I would like to finish up the interoperability testing THIS week, by 8 Jan.

Thanks.

/Nelson Bolyard

(This is my 6th attempt to send this in the past 72 hours.)

[TLS] Interoperability testing for draft-ietf-tls… Nelson B Bolyard