tidying

[users/jgh/exim.git] / doc / doc-txt / experimental-spec.txt

diff --git a/doc/doc-txt/experimental-spec.txt b/doc/doc-txt/experimental-spec.txt
index a2861c4a968b94f07d7e7f4ff1ad0b246b6279a1..f748f61460a27692e61ed51630e379ec5c2b156c 100644 (file)
--- a/doc/doc-txt/experimental-spec.txt
+++ b/doc/doc-txt/experimental-spec.txt
@@ -873,89 +873,12 @@ 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
 ----------------------

-TLS Session Resumption for TLS 1.2 and TLS1.3 connections can be used (defined
+TLS Session Resumption for TLS 1.2 and TLS 1.3 connections can be used (defined

 in RFC 5077 for 1.2).  The support for this can be included by building with
 in RFC 5077 for 1.2).  The support for this can be included by building with

-EXPERIMENTAL_TLS_RESUME defined.
+EXPERIMENTAL_TLS_RESUME defined.  This requires GnuTLS 3.6.3 or OpenSSL 1.1.1
+(or later).

 
 Session resumption (this is the "stateless" variant) involves the server sending
 a "session ticket" to the client on one connection, which can be stored by the
 
 Session resumption (this is the "stateless" variant) involves the server sending
 a "session ticket" to the client on one connection, which can be stored by the


@@ -965,34 +888,46 @@ calculation and one full packet roundtrip time.
 
 Operational cost/benefit:
  The extra data being transmitted costs a minor amount, and the client has
 
 Operational cost/benefit:
  The extra data being transmitted costs a minor amount, and the client has

-extra costs in storing and retrieving the data.
+ extra costs in storing and retrieving the data.

 
 

-In the Exim/Gnutls implementation the extra cost on an initial connection
-which is TLS1.2 over a loopback path is about 6ms on 2017-laptop class hardware.
-The saved cost on a subsequent connection is about 4ms; three or more
-connections become a net win.  On longer network paths, two or more
-connections will have an average lower startup time thanks to the one
-saved packet roundtrip.  TLS1.3 will save the crypto cpu costs but not any
-packet roundtrips.
+ In the Exim/Gnutls implementation the extra cost on an initial connection
+ which is TLS1.2 over a loopback path is about 6ms on 2017-laptop class hardware.
+ The saved cost on a subsequent connection is about 4ms; three or more
+ connections become a net win.  On longer network paths, two or more
+ connections will have an average lower startup time thanks to the one
+ saved packet roundtrip.  TLS1.3 will save the crypto cpu costs but not any
+ packet roundtrips.
+
+ Since a new hints DB is used, the hints DB maintenance should be updated
+ to additionally handle "tls".

 
 Security aspects:
  The session ticket is encrypted, but is obviously an additional security
 
 Security aspects:
  The session ticket is encrypted, but is obviously an additional security

-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.
+ 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 (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
+ There is a question-mark over the security of the Diffie-Helman parameters
+ used for session negotiation. TBD.  q-value; cf bug 1895

 
 Observability:
  New log_selector "tls_resumption", appends an asterisk to the tls_cipher "X="
 
 Observability:
  New log_selector "tls_resumption", appends an asterisk to the tls_cipher "X="

-element.
-
-Variables $tls_{in,out}_resumption have bit 0-4 indicating respectively
-support built, client requested ticket, client offered session,
-server issued ticket, resume used.  A suitable decode list is provided
-in the builtin macro _RESUME_DECODE for ${listextract {}{}}.
+ element.
+
+ Variables $tls_{in,out}_resumption have bits 0-4 indicating respectively
+ support built, client requested ticket, client offered session,
+ server issued ticket, resume used.  A suitable decode list is provided
+ in the builtin macro _RESUME_DECODE for ${listextract {}{}}.
+
+Issues:
+ In a resumed session:
+  $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

 
 
 --------------------------------------------------------------
 
 
 --------------------------------------------------------------