[gnutls-devel] GnuTLS | tls1.3: server returns early on handshake when no cert is provided by client (!711)

[Development of GNU's TLS library]

Nikos Mavrogiannopoulos commented on a discussion on lib/handshake-tls13.c:

> +			IMED_RET("generate app keys", ret, 0);
> +
> +			ret = _tls13_write_connection_state_init(session, STAGE_APP);
> +			IMED_RET("set write app keys", ret, 0);
> +
> +			_gnutls_handshake_log("HSK[%p]: switching early to application traffic keys\n", session);
> +		}
> +
> +		/* fall through */
> +	case STATE108:
> +		if (session->internals.resumed != RESUME_FALSE)
> +			_gnutls_set_resumed_parameters(session);
> +
> +		/* If we didn't request a client certificate we can send tickets now
> +		 * and return early */
> +		if (session->internals.hsk_flags & HSK_EARLY_START_USED) {

What do you have in mind? The sending of the ticket early, is an improvement to the current situation as it allows the client to have it in cache/queue when the handshake is complete. It is described in the TLS1.3 as:
```
   Although the resumption master secret depends on the client's
   second flight, servers which do not request client authentication MAY
   compute the remainder of the transcript independently and then send a
   NewSessionTicket immediately upon sending its Finished rather than
   waiting for the client Finished.  This might be appropriate in cases
   where the client is expected to open multiple TLS connections in
   parallel and would benefit from the reduced overhead of a resumption
   handshake, for example.
```

The worrying part is point 2 from 4.4.4:
```
       Servers MAY send data after sending their first flight, but
       because the handshake is not yet complete, they have no assurance
       of either the peer's identity or of its liveness
```
but as we are only doing that for the "unauthenticated client" it shouldn't matter.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/711#note_90800941
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20180727/e247c0fe/attachment-0001.html>