X-Git-Url: https://git.exim.org/users/jgh/exim.git/blobdiff_plain/4f1d23a1aa7aafc5a47988d80dde87c67ec8e1fc..d70fc2833417750a21f05e651ee776efb538bf05:/doc/doc-txt/experimental-spec.txt diff --git a/doc/doc-txt/experimental-spec.txt b/doc/doc-txt/experimental-spec.txt index f304cf455..f748f6146 100644 --- a/doc/doc-txt/experimental-spec.txt +++ b/doc/doc-txt/experimental-spec.txt @@ -873,84 +873,6 @@ used via the transport in question. -Early pipelining support ------------------------- -Ref: https://datatracker.ietf.org/doc/draft-harris-early-pipe/ - -If compiled with EXPERIMENTAL_PIPE_CONNECT support is included for this feature. -The server advertises the feature in its EHLO response, currently using the name -"X_PIPE_CONNECT" (this will change, some time in the future). -A client may cache this information, along with the rest of the EHLO response, -and use it for later connections. Those later ones can send esmtp commands before -a banner is received. - -Up to 1.5 roundtrip times can be taken out of cleartext connections, 2.5 on -STARTTLS connections. - -In combination with the traditional PIPELINING feature the following example -sequences are possible (among others): - -(client) (server) - -EHLO,MAIL,RCPT,DATA -> - <- banner,EHLO-resp,MAIL-ack,RCPT-ack,DATA-goahead -message-data -> ------- - -EHLO,MAIL,RCPT,BDAT -> - <- banner,EHLO-resp,MAIL-ack,RCPT-ack -message-data -> ------- - -EHLO,STARTTLS -> - <- banner,EHLO-resp,TLS-goahead -TLS1.2-client-hello -> - <- TLS-server-hello,cert,hello-done -client-Kex,change-cipher,finished -> - <- change-cipher,finished -EHLO,MAIL,RCPT,DATA -> - <- EHLO-resp,MAIL-ack,RCPT-ack,DATA-goahead - ------- -(tls-on-connect) -TLS1.2-client-hello -> - <- TLS-server-hello,cert,hello-done -client-Kex,change-cipher,finished -> - <- change-cipher,finshed - <- banner -EHLO,MAIL,RCPT,DATA -> - <- EHLO-resp,MAIL-ack,RCPT-ack,DATA-goahead - -Where the initial client packet is SMTP, it can combine with the TCP Fast Open -feature and be sent in the TCP SYN. - - -A main-section option "pipelining_connect_advertise_hosts" (default: *) -and an smtp transport option "hosts_pipe_connect" (default: unset) -control the feature. - -If the "pipelining" log_selector is enabled, the "L" field in server <= -log lines has a period appended if the feature was advertised but not used; -or has an asterisk appended if the feature was used. In client => lines -the "L" field has an asterisk appended if the feature was used. - -The "retry_data_expire" option controls cache invalidation. -Entries are also rewritten (or cleared) if the adverised features -change. - - -NOTE: since the EHLO command must be constructed before the connection is -made it cannot depend on the interface IP address that will be used. -Transport configurations should be checked for this. An example avoidance: - - helo_data = ${if def:sending_ip_address \ - {${lookup dnsdb{>! ptr=$sending_ip_address} \ - {${sg{$value} {^([^!]*).*\$} {\$1}}} fail}} \ - {$primary_hostname}} - - - - TLS Session Resumption ---------------------- TLS Session Resumption for TLS 1.2 and TLS 1.3 connections can be used (defined @@ -984,7 +906,10 @@ Security aspects: vulnarability surface. An attacker able to decrypt it would have access all connections using the resumed session. The session ticket encryption key is not committed to storage by the server - and is rotated regularly. Tickets have limited lifetime. + and is rotated regularly (OpenSSL: 1hr, and one previous key is used for + overlap; GnuTLS 6hr but does not specify any overlap). + Tickets have limited lifetime (2hr, and new ones issued after 1hr under + OpenSSL. GnuTLS 2hr, appears to not do overlap). There is a question-mark over the security of the Diffie-Helman parameters used for session negotiation. TBD. q-value; cf bug 1895 @@ -1000,12 +925,9 @@ Observability: Issues: In a resumed session: - $tls_{in,out}_certificate_verified will be set, and verify = certificate - will be true, when verify failed but tls_try_verify_hosts allowed the - connection (under OpenSSL) $tls_{in,out}_cipher will have values different to the original (under GnuTLS) $tls_{in,out}_ocsp will be "not requested" or "no response", and - hosts_require_ocsp will fail + hosts_require_ocsp will fail --------------------------------------------------------------