[gnutls-devel] Server sends incorrect extensions for resumption handshake?

[Peter Dettman]

Hi All,
I'm currently adding session resumption to the BouncyCastle (Java) TLS 
code, and I'm seeing what I think is incorrect behaviour from the 
gnutls-serv test server. I'm using GnuTLS 3.2.1 on Win7, with command line:
     gnutls-serv --http --x509cafile x509-ca.pem --x509keyfile 
x509-server-key.pem --x509certfile x509-server.pem

My test client makes an initial connection to establish a session, 
successfully negotiating TLS 1.1, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, 
secure_renegotiation = true. Note the ServerHello contains two 
extensions: renegotiation_info and ec_point_formats. This connection is 
closed once the handshake has completed.

The client then tries to resume this session (with essentially the same 
ClientHello, excepting client_random, and with the resuming session_id). 
If it ignores the errors I am about to describe, it can happily resume 
the session, and make a GET request to the http server, getting the 
expected page and closing cleanly. However I think the ServerHello is 
wrong, specifically the server extensions.

Firstly, the ec_point_formats extension is included in the session 
resumption ServerHello. This appears to violate RFC 3546 2.3. "If [...] 
the older session is resumed, then the server MUST ignore extensions 
appearing in the client hello, and send a server hello containing no 
extensions[.]" (later RFC updates contain similar clauses) . Please 
understand that the problem is probably broader than just the 
ec_point_formats extension; the server shouldn't be sending any. The 
only exception to that rule that I am aware of is from RFC 5746, 
renegotiation_info, which appears to say that this extension is 
per-connection, and can always be sent. This is the second issue I want 
to raise: while gnutls-serv sends renegotiation_info during the initial 
handshake, it does _not_ send it during a resumption handshake.

I am posting to the list instead of raising a bug report directly, 
because it's at least true that 'openssl s_server' also sends 
superfluous server extensions during resumption (it sends the 
renegotiation_info correctly though) . I would appreciate if anyone can 
enlighten me as to whether there is an unofficial standard in play here, 
or whether this should be considered a bug.

Please contact me if you'd like replicate the problem, either via the 
BouncyCastle test code itself, or in some other way.

Regards,
Pete Dettman