Viktor Dukhovni via Postfix-users wrote in
 <zefrnbx3x8nz6...@chardros.imrryr.org>:
 |On Fri, Mar 01, 2024 at 12:26:33AM +0100, Steffen Nurpmeso wrote:
 |
 |> i still use the
 |> 
 |>   # super modern, forward secrecy TLSv1.2 / TLSv1.3 selection..
 |>   tls_high_cipherlist = EECDH+AESGCM:EECDH+AES256:EDH+AESGCM:CHACHA20
 |
 |I don't recommend cargo-culting random cipher lists.

Well i think he carefully selected that; i must admit i have
blindly said that, somewhen on this list i posted "the same" thing
and by then i still knew what was his and what i added or changed.

 |>   smtpd_tls_mandatory_ciphers = high
 |>   smtpd_tls_mandatory_exclude_ciphers = TLSv1
 |
 |In pratice, this boils down to
 |
 |    ECDHE-ECDSA-AES256-SHA  TLSv1 Kx=ECDH     Au=ECDSA Enc=AES(256) \
 |     Mac=SHA1
 |    ECDHE-RSA-AES256-SHA    TLSv1 Kx=ECDH     Au=RSA  Enc=AES(256) \
 |     Mac=SHA1
 |    ECDHE-ECDSA-AES128-SHA  TLSv1 Kx=ECDH     Au=ECDSA Enc=AES(128) \
 |     Mac=SHA1
 |    ECDHE-RSA-AES128-SHA    TLSv1 Kx=ECDH     Au=RSA  Enc=AES(128) \
 |     Mac=SHA1
 |
 |Which should all be fine (better than cleartext) for email.

You are the specialist who can even write RFCs on this topic, dear
Viktor Dukhovni.  Ie TLS.  And regarding cryptographics aka its
maths i have zero competence.  In reality, and myself, that is.
If you say the above TLSv1 things are ok, so it may be, but
i would hope my above config boils down to the below, because
otherwise i would even have misunderstood postconf(5).

  $ openssl ciphers -v EECDH+AESGCM:EECDH+AES256:EDH+AESGCM:CHACHA20:!TLSv1
  TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256)   
         Mac=AEAD
  TLS_CHACHA20_POLY1305_SHA256   TLSv1.3 Kx=any      Au=any   
Enc=CHACHA20/POLY1305(256) Mac=AEAD
  TLS_AES_128_GCM_SHA256         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(128)   
         Mac=AEAD
  ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256)   
         Mac=AEAD
  ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2 Kx=ECDH     Au=RSA   Enc=AESGCM(256)   
         Mac=AEAD
  ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128)   
         Mac=AEAD
  ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2 Kx=ECDH     Au=RSA   Enc=AESGCM(128)   
         Mac=AEAD
  ECDHE-ECDSA-AES256-CCM         TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM(256)   
         Mac=AEAD
  ECDHE-ECDSA-AES256-CCM8        TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM8(256)  
         Mac=AEAD
  ECDHE-ECDSA-AES256-SHA384      TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)      
         Mac=SHA384
  ECDHE-RSA-AES256-SHA384        TLSv1.2 Kx=ECDH     Au=RSA   Enc=AES(256)      
         Mac=SHA384
  DHE-DSS-AES256-GCM-SHA384      TLSv1.2 Kx=DH       Au=DSS   Enc=AESGCM(256)   
         Mac=AEAD
  DHE-RSA-AES256-GCM-SHA384      TLSv1.2 Kx=DH       Au=RSA   Enc=AESGCM(256)   
         Mac=AEAD
  DHE-DSS-AES128-GCM-SHA256      TLSv1.2 Kx=DH       Au=DSS   Enc=AESGCM(128)   
         Mac=AEAD
  DHE-RSA-AES128-GCM-SHA256      TLSv1.2 Kx=DH       Au=RSA   Enc=AESGCM(128)   
         Mac=AEAD
  ECDHE-ECDSA-CHACHA20-POLY1305  TLSv1.2 Kx=ECDH     Au=ECDSA 
Enc=CHACHA20/POLY1305(256) Mac=AEAD
  ECDHE-RSA-CHACHA20-POLY1305    TLSv1.2 Kx=ECDH     Au=RSA   
Enc=CHACHA20/POLY1305(256) Mac=AEAD
  DHE-RSA-CHACHA20-POLY1305      TLSv1.2 Kx=DH       Au=RSA   
Enc=CHACHA20/POLY1305(256) Mac=AEAD
  RSA-PSK-CHACHA20-POLY1305      TLSv1.2 Kx=RSAPSK   Au=RSA   
Enc=CHACHA20/POLY1305(256) Mac=AEAD
  DHE-PSK-CHACHA20-POLY1305      TLSv1.2 Kx=DHEPSK   Au=PSK   
Enc=CHACHA20/POLY1305(256) Mac=AEAD
  ECDHE-PSK-CHACHA20-POLY1305    TLSv1.2 Kx=ECDHEPSK Au=PSK   
Enc=CHACHA20/POLY1305(256) Mac=AEAD
  PSK-CHACHA20-POLY1305          TLSv1.2 Kx=PSK      Au=PSK   
Enc=CHACHA20/POLY1305(256) Mac=AEAD

I also admit i do not understand your "compaigning for anon
ciphers for SMTP".  I think the TLS system should move away from
CA pools, to some DNS based thing.  Your DANE is standardized and
you hear the word often, i am currently enthusiastic on how
pragmatic DKIM solved its problems, and that includes the DNS
record holding the certificate (aka public key, here).  I would
have no problem (except for the sheer record size, but of course,
like DANE, a simple fingerprint could also be published, this is
sufficient!) with a simple TLSXXX record, as long as DNS can now
be used over secure transport itself, and DNSSEC is also simple
and simply available.  'Still hoping for my provider to add it,
now.  For S/MIME it would have to provide the complete key,
however.  Ie, very simple and pragmatic, with decades old OpenSSL
functions to simply load PEM key data in, and you are ready to go.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Reply via email to