[pfx] Re: DANE and DNSSEC
On Mon, May 22, 2023 at 02:34:41PM +0200, Joachim Lindenberg via Postfix-users wrote: > reusing the private key for too long (say a year or more) is > considered a bad security practice. Imho it is easier to monitor > changes of the issuing CA (I do) or just mark your calendar to update > in September 2025 than to pin 3 1 1. Don´t want to be fundamental, > just opinionated. Everyone has to decide on her/his own. FWIW, I don't agree. There are still ~270 domains publishing TLSA records matching the long-retired Let's Encrypt X3/X4 CAs. Dilligently tracking issuing CA transitions is not that easy in practice, and the security of ACME is fairly dubious. Key reuse as a *default* rollover approach is robust. When it is time to change keys, one can do so deliberately, and with due care to prepublish TLSA records matching the *next* key, then after a few TTLs deploy the next certificate, and at that point drop the outdated TLSA RR matching the old keys. Meanwhile, root CAs reuse the same RSA 2048-bit key for decades. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
Joachim Lindenberg via Postfix-users writes: > (...) just mark your calendar to update in September 2025 ... Hellow Joachim! Thanks for remarkble tip ^^^ Sincerely, Byung-Hee ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
reusing the private key for too long (say a year or more) is considered a bad security practice. Imho it is easier to monitor changes of the issuing CA (I do) or just mark your calendar to update in September 2025 than to pin 3 1 1. Don´t want to be fundamental, just opinionated. Everyone has to decide on her/his own. Cheers, Joachim -Ursprüngliche Nachricht- Von: raf via Postfix-users Gesendet: Samstag, 20. Mai 2023 00:53 An: postfix-users@postfix.org Betreff: [pfx] Re: DANE and DNSSEC On Thu, May 18, 2023 at 08:54:16PM +0200, Joachim Lindenberg via Postfix-users wrote: > For Letsencrypt certificates I´d definitely go with 2 1 1 > 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D and > optionally the R4 derivate and add their successors when these are about to > expire, rather than 3 1 1 and change every two months. > Best Regards, > Joachim The certificate might change every few months, but that doesn't mean that the key has to change at the same time. As Viktor pointed out, with certbot you can configure reuse_key = True which prevents the renewal from creating a new key. That way, the user can decide when they want the key to rollover. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
On Thu, May 18, 2023 at 09:11:41AM -0400, Viktor Dukhovni via Postfix-users wrote: > On Thu, May 18, 2023 at 09:22:34PM +0900, Byung-Hee HWANG via Postfix-users > wrote: > > > And now i added TLSA record for only *outbond* smtp server, > > . > > It is also your secondary MX host: > > https://stats.dnssec-tools.org/explore/?doraji.xyz > > the primary MX host does not yet have TLSA records. The detailed > status is: > > doraji.xyz. IN MX 1871 yw-0919.doraji.xyz. > doraji.xyz. IN MX 1895 yw-1204.doraji.xyz. > _25._tcp.yw-0919.doraji.xyz. IN TLSA ? ; NXDOMAIN > _25._tcp.yw-1204.doraji.xyz. IN TLSA 3 1 1 > b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f > yw-1204.doraji.xyz[185.17.255.72]: pass: TLSA match: depth = 0, name = > yw-1204.doraji.xyz > TLS = TLS13 with AES256GCM-SHA384,X25519,PubKeyALG_RSA > name = yw-1204.doraji.xyz > depth = 0 > Issuer CommonName = R3 > Issuer Organization = Let's Encrypt > notBefore = 2023-03-20T06:03:54Z > notAfter = 2023-06-18T06:03:53Z > Subject CommonName = yw-1204.doraji.xyz > pkey sha256 [matched] <- 3 1 1 > b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f > depth = 1 > Issuer CommonName = ISRG Root X1 > Issuer Organization = Internet Security Research Group > notBefore = 2020-09-04T00:00:00Z > notAfter = 2025-09-15T16:00:00Z > Subject CommonName = R3 > Subject Organization = Let's Encrypt > pkey sha256 [nomatch] <- 2 1 1 > 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d > depth = 2 > Issuer CommonName = DST Root CA X3 > Issuer Organization = Digital Signature Trust Co. > notBefore = 2021-01-20T19:14:03Z > notAfter = 2024-09-30T18:14:03Z > Subject CommonName = ISRG Root X1 > Subject Organization = Internet Security Research Group > pkey sha256 [nomatch] <- 2 1 1 > 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 > yw-1204.doraji.xyz[2a03:ebc0:5000:12::10]: pass: TLSA match: depth = 0, > name = yw-1204.doraji.xyz > TLS = TLS13 with AES256GCM-SHA384,X25519,PubKeyALG_RSA > name = yw-1204.doraji.xyz > depth = 0 > Issuer CommonName = R3 > Issuer Organization = Let's Encrypt > notBefore = 2023-03-20T06:03:54Z > notAfter = 2023-06-18T06:03:53Z > Subject CommonName = yw-1204.doraji.xyz > pkey sha256 [matched] <- 3 1 1 > b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f > depth = 1 > Issuer CommonName = ISRG Root X1 > Issuer Organization = Internet Security Research Group > notBefore = 2020-09-04T00:00:00Z > notAfter = 2025-09-15T16:00:00Z > Subject CommonName = R3 > Subject Organization = Let's Encrypt > pkey sha256 [nomatch] <- 2 1 1 > 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d > depth = 2 > Issuer CommonName = DST Root CA X3 > Issuer Organization = Digital Signature Trust Co. > notBefore = 2021-01-20T19:14:03Z > notAfter = 2024-09-30T18:14:03Z > Subject CommonName = ISRG Root X1 > Subject Organization = Internet Security Research Group > pkey sha256 [nomatch] <- 2 1 1 > 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 > > Since your certificate is from Let's Encrypt, you've probably configured > automatic renewal. If you haven't also implemented *monitoring* of your > DANE TLSA configuration that checks whether the TLSA records match the > certificate chain, you should do that immediately, and ideally before > publishing TLSA records for any servers carrying "non-test" traffic. > > You can publish TLSA records for some test host with a self-signed > cert, and check monitoring detects incorrect TLSA records when > mismatched TLSA records are configured (and is not complaining > when the TLSA records are correct). With my danectl program, TLSA monitoring is a cronjob: danectl check If you have done a key rollover, but you haven't updated the TLSA records yet, it'll report (in zonefile format) that the old "current" TLSA record needs to be removed from the DNS, and that the new "next" TLSA record needs to be published. Also, if your DNSSEC zones are configured to automatically rollover every so often, you need to set up monitoring for that as well, so that you can communicate the new DS record to your registrar. I'm not sure what the best method for that is. I just wrote and cronned a script to report whenever the output of the following changes: host -t dnskey $domain | sort | grep 'DNSKEY record 257'; \ host -t cds $domain | sort | grep -v 'has no'; \ host -t cdnskey $domain | sort | grep -v 'has no' With BIND, that
[pfx] Re: DANE and DNSSEC
On Thu, May 18, 2023 at 08:54:16PM +0200, Joachim Lindenberg via Postfix-users wrote: > For Letsencrypt certificates I´d definitely go with 2 1 1 > 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D and > optionally the R4 derivate and add their successors when these are about to > expire, rather than 3 1 1 and change every two months. > Best Regards, > Joachim The certificate might change every few months, but that doesn't mean that the key has to change at the same time. As Viktor pointed out, with certbot you can configure reuse_key = True which prevents the renewal from creating a new key. That way, the user can decide when they want the key to rollover. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
Benny Pedersen via Postfix-users writes: > Byung-Hee HWANG via Postfix-users skrev den 2023-05-19 04:26: > >> Thanks for advice! >> >>>[renewalparams] >>>reuse_key = True >>>preferred_chain = ISRG Root X1 > >> And >> I can't say anything yet. I need some test for long time. If i am sure >> what DANE is, > > posttls-finger example.org, basic test to test outbound soyeomul@yw-1130:~/git/karma/Gnus/DKIM$ ./ct.py yw-1204.doraji.xyz depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = yw-1204.doraji.xyz verify return:1 250 CHUNKING DONE notBefore=May 19 06:01:23 2023 GMT notAfter=Aug 17 06:01:22 2023 GMT ^^^ posttls-finger: using DANE RR: _25._tcp.yw-1204.doraji.xyz -> _dane.doraji.xyz IN TLSA 2 1 1 8D:02:53:6C:88:74:82:BC:34:FF:54:E4:1D:2B:A6:59:BF:85:B3:41:A0:A2:0A:FA:DB:58:13:DC:FB:CF:28:6D posttls-finger: yw-1204.doraji.xyz[2a03:ebc0:5000:12::10]:25: depth=1 matched trust anchor public-key sha256 digest=8D:02:53:6C:88:74:82:BC:34:FF:54:E4:1D:2B:A6:59:BF:85:B3:41:A0:A2:0A:FA:DB:58:13:DC:FB:CF:28:6D posttls-finger: yw-1204.doraji.xyz[2a03:ebc0:5000:12::10]:25: depth=0 chain is trust-anchor signed posttls-finger: yw-1204.doraji.xyz[2a03:ebc0:5000:12::10]:25: Matched subjectAltName: yw-1204.doraji.xyz posttls-finger: yw-1204.doraji.xyz[2a03:ebc0:5000:12::10]:25 CommonName yw-1204.doraji.xyz posttls-finger: yw-1204.doraji.xyz[2a03:ebc0:5000:12::10]:25: subject_CN=yw-1204.doraji.xyz, issuer_CN=R3, fingerprint=A7:84:A8:5B:69:A4:A2:2A:00:AC:CC:17:AA:EF:C0:D8:C3:BC:B4:CF:FC:D4:F3:19:5D:96:AA:45:19:44:94:BE, pkey_fingerprint=B4:B0:6C:36:72:78:08:CB:3E:27:2F:43:8C:C6:F1:A7:7E:E3:70:C5:0D:FB:24:EB:57:74:A6:11:3E:4C:6C:0F posttls-finger: Verified TLS connection established to yw-1204.doraji.xyz[2a03:ebc0:5000:12::10]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 soyeomul@yw-1130:~/git/karma/Gnus/DKIM$ After read mails of Viktor+Joachim, i moved to "2 1 1" from "3 1 1". Still i am testing... So i can't say anything for a while. >> i will setup inbond server (yw-0919.doraji.xyz) with DANE. > > inbound is STARTTLS only Thank you! Sincerely, Byung-Hee -- ^고맙습니다 _布德天下_ 감사합니다_^))// ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
Byung-Hee HWANG via Postfix-users skrev den 2023-05-19 04:26: Thanks for advice! [renewalparams] reuse_key = True preferred_chain = ISRG Root X1 And I can't say anything yet. I need some test for long time. If i am sure what DANE is, posttls-finger example.org, basic test to test outbound i will setup inbond server (yw-0919.doraji.xyz) with DANE. inbound is STARTTLS only ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
Viktor Dukhovni via Postfix-users writes: > On Thu, May 18, 2023 at 09:22:34PM +0900, Byung-Hee HWANG via Postfix-users > wrote: > >> And now i added TLSA record for only *outbond* smtp server, >> . > > It is also your secondary MX host: > > https://stats.dnssec-tools.org/explore/?doraji.xyz > > the primary MX host does not yet have TLSA records. The detailed > status is: > > doraji.xyz. IN MX 1871 yw-0919.doraji.xyz. > doraji.xyz. IN MX 1895 yw-1204.doraji.xyz. > _25._tcp.yw-0919.doraji.xyz. IN TLSA ? ; NXDOMAIN > _25._tcp.yw-1204.doraji.xyz. IN TLSA 3 1 1 > b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f > yw-1204.doraji.xyz[185.17.255.72]: pass: TLSA match: depth = 0, name = > yw-1204.doraji.xyz > TLS = TLS13 with AES256GCM-SHA384,X25519,PubKeyALG_RSA > name = yw-1204.doraji.xyz > depth = 0 > Issuer CommonName = R3 > Issuer Organization = Let's Encrypt > notBefore = 2023-03-20T06:03:54Z > notAfter = 2023-06-18T06:03:53Z > Subject CommonName = yw-1204.doraji.xyz > pkey sha256 [matched] <- 3 1 1 > b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f > depth = 1 > Issuer CommonName = ISRG Root X1 > Issuer Organization = Internet Security Research Group > notBefore = 2020-09-04T00:00:00Z > notAfter = 2025-09-15T16:00:00Z > Subject CommonName = R3 > Subject Organization = Let's Encrypt > pkey sha256 [nomatch] <- 2 1 1 > 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d > depth = 2 > Issuer CommonName = DST Root CA X3 > Issuer Organization = Digital Signature Trust Co. > notBefore = 2021-01-20T19:14:03Z > notAfter = 2024-09-30T18:14:03Z > Subject CommonName = ISRG Root X1 > Subject Organization = Internet Security Research Group > pkey sha256 [nomatch] <- 2 1 1 > 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 > yw-1204.doraji.xyz[2a03:ebc0:5000:12::10]: pass: TLSA match: depth = 0, > name = yw-1204.doraji.xyz > TLS = TLS13 with AES256GCM-SHA384,X25519,PubKeyALG_RSA > name = yw-1204.doraji.xyz > depth = 0 > Issuer CommonName = R3 > Issuer Organization = Let's Encrypt > notBefore = 2023-03-20T06:03:54Z > notAfter = 2023-06-18T06:03:53Z > Subject CommonName = yw-1204.doraji.xyz > pkey sha256 [matched] <- 3 1 1 > b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f > depth = 1 > Issuer CommonName = ISRG Root X1 > Issuer Organization = Internet Security Research Group > notBefore = 2020-09-04T00:00:00Z > notAfter = 2025-09-15T16:00:00Z > Subject CommonName = R3 > Subject Organization = Let's Encrypt > pkey sha256 [nomatch] <- 2 1 1 > 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d > depth = 2 > Issuer CommonName = DST Root CA X3 > Issuer Organization = Digital Signature Trust Co. > notBefore = 2021-01-20T19:14:03Z > notAfter = 2024-09-30T18:14:03Z > Subject CommonName = ISRG Root X1 > Subject Organization = Internet Security Research Group > pkey sha256 [nomatch] <- 2 1 1 > 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 > > Since your certificate is from Let's Encrypt, you've probably configured > automatic renewal. If you haven't also implemented *monitoring* of your > DANE TLSA configuration that checks whether the TLSA records match the > certificate chain, you should do that immediately, and ideally before > publishing TLSA records for any servers carrying "non-test" traffic. > > You can publish TLSA records for some test host with a self-signed > cert, and check monitoring detects incorrect TLSA records when > mismatched TLSA records are configured (and is not complaining > when the TLSA records are correct). > > You then also need to make sure that your certificate rollover process > is robust, and either keeps the public key unchanged, or you pre-publish > matching TLSA records for future keys alongside current keys. > > Setting up inbound DANE requires operational diligence. Do consider > implemting DANE, but not as a fashion statement, rather only because > you understand how to coordinate certificate management with DANE > TLSA record upkeep. Thanks for advice! >[renewalparams] >reuse_key = True >preferred_chain = ISRG Root X1 >... Thanks again too! I did updated conf file with reuse_key/preferred_chain things. And I can't say anything yet. I need some test for long time. If i am sure what DANE is, i will setup inbond server (yw-0919.doraji.xyz) with DANE. Sincerely, Byung-Hee -- ^고맙습니다 _布德天下_ 감사합니다_^))//
[pfx] Re: DANE and DNSSEC
On Thu, May 18, 2023 at 08:54:16PM +0200, Joachim Lindenberg via Postfix-users wrote: > For Letsencrypt certificates I´d definitely go with 2 1 1 > 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D and > optionally the R4 derivate and add their successors when these are > about to expire, rather than 3 1 1 and change every two months. Best A well thought out "3 1 1 + 3 1 1" setup is IMHO more robust. With "2 1 1", the certificates occasionally expire, despite best intentions, and security is reduced to TOFU, since ACME "proofs" boil down to an initial leap of faith. That said, if you do go with "2 1 1", please look over: https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
Hello Byung-Hee , for testing you may want to try https://blog.lindenberg.one/EmailSecurityTest. Best Regards, Joachim -Ursprüngliche Nachricht- Von: Byung-Hee HWANG via Postfix-users Gesendet: Mittwoch, 17. Mai 2023 10:16 An: Postfix-users Betreff: [pfx] Re: DANE and DNSSEC Now i added DNSSEC. Currently it is being registra job. 10 minutes ago, i did make some DS record at Cloudfalre. Thanks to Joachim, Patrick and raf ^^^ Sincerely, Byung-Hee ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
For Letsencrypt certificates I´d definitely go with 2 1 1 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D and optionally the R4 derivate and add their successors when these are about to expire, rather than 3 1 1 and change every two months. Best Regards, Joachim -Ursprüngliche Nachricht- Von: Viktor Dukhovni via Postfix-users Gesendet: Donnerstag, 18. Mai 2023 15:12 An: postfix-users@postfix.org Betreff: [pfx] Re: DANE and DNSSEC On Thu, May 18, 2023 at 09:22:34PM +0900, Byung-Hee HWANG via Postfix-users wrote: > And now i added TLSA record for only *outbond* smtp server, > . It is also your secondary MX host: https://stats.dnssec-tools.org/explore/?doraji.xyz the primary MX host does not yet have TLSA records. The detailed status is: doraji.xyz. IN MX 1871 yw-0919.doraji.xyz. doraji.xyz. IN MX 1895 yw-1204.doraji.xyz. _25._tcp.yw-0919.doraji.xyz. IN TLSA ? ; NXDOMAIN _25._tcp.yw-1204.doraji.xyz. IN TLSA 3 1 1 b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f yw-1204.doraji.xyz[185.17.255.72]: pass: TLSA match: depth = 0, name = yw-1204.doraji.xyz TLS = TLS13 with AES256GCM-SHA384,X25519,PubKeyALG_RSA name = yw-1204.doraji.xyz depth = 0 Issuer CommonName = R3 Issuer Organization = Let's Encrypt notBefore = 2023-03-20T06:03:54Z notAfter = 2023-06-18T06:03:53Z Subject CommonName = yw-1204.doraji.xyz pkey sha256 [matched] <- 3 1 1 b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f depth = 1 Issuer CommonName = ISRG Root X1 Issuer Organization = Internet Security Research Group notBefore = 2020-09-04T00:00:00Z notAfter = 2025-09-15T16:00:00Z Subject CommonName = R3 Subject Organization = Let's Encrypt pkey sha256 [nomatch] <- 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d depth = 2 Issuer CommonName = DST Root CA X3 Issuer Organization = Digital Signature Trust Co. notBefore = 2021-01-20T19:14:03Z notAfter = 2024-09-30T18:14:03Z Subject CommonName = ISRG Root X1 Subject Organization = Internet Security Research Group pkey sha256 [nomatch] <- 2 1 1 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 yw-1204.doraji.xyz[2a03:ebc0:5000:12::10]: pass: TLSA match: depth = 0, name = yw-1204.doraji.xyz TLS = TLS13 with AES256GCM-SHA384,X25519,PubKeyALG_RSA name = yw-1204.doraji.xyz depth = 0 Issuer CommonName = R3 Issuer Organization = Let's Encrypt notBefore = 2023-03-20T06:03:54Z notAfter = 2023-06-18T06:03:53Z Subject CommonName = yw-1204.doraji.xyz pkey sha256 [matched] <- 3 1 1 b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f depth = 1 Issuer CommonName = ISRG Root X1 Issuer Organization = Internet Security Research Group notBefore = 2020-09-04T00:00:00Z notAfter = 2025-09-15T16:00:00Z Subject CommonName = R3 Subject Organization = Let's Encrypt pkey sha256 [nomatch] <- 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d depth = 2 Issuer CommonName = DST Root CA X3 Issuer Organization = Digital Signature Trust Co. notBefore = 2021-01-20T19:14:03Z notAfter = 2024-09-30T18:14:03Z Subject CommonName = ISRG Root X1 Subject Organization = Internet Security Research Group pkey sha256 [nomatch] <- 2 1 1 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 Since your certificate is from Let's Encrypt, you've probably configured automatic renewal. If you haven't also implemented *monitoring* of your DANE TLSA configuration that checks whether the TLSA records match the certificate chain, you should do that immediately, and ideally before publishing TLSA records for any servers carrying "non-test" traffic. You can publish TLSA records for some test host with a self-signed cert, and check monitoring detects incorrect TLSA records when mismatched TLSA records are configured (and is not complaining when the TLSA records are correct). You then also need to make sure that your certificate rollover process is robust, and either keeps the public key unchanged, or you pre-publish matching TLSA records for future keys alongside current keys. Setting up inbound DANE requires operational diligence. Do consider implemting DANE, but not as a fashion statement, rather only because you understand how to coordinate certificate management with DANE TLSA record upkeep. -- Viktor. P.S. Your certificate chain from Let's Encrypt includes a cross-cert for the ISRG root from the expired DST root. This is obsolete, i
[pfx] Re: DANE and DNSSEC
On Thu, May 18, 2023 at 09:22:34PM +0900, Byung-Hee HWANG via Postfix-users wrote: > And now i added TLSA record for only *outbond* smtp server, > . It is also your secondary MX host: https://stats.dnssec-tools.org/explore/?doraji.xyz the primary MX host does not yet have TLSA records. The detailed status is: doraji.xyz. IN MX 1871 yw-0919.doraji.xyz. doraji.xyz. IN MX 1895 yw-1204.doraji.xyz. _25._tcp.yw-0919.doraji.xyz. IN TLSA ? ; NXDOMAIN _25._tcp.yw-1204.doraji.xyz. IN TLSA 3 1 1 b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f yw-1204.doraji.xyz[185.17.255.72]: pass: TLSA match: depth = 0, name = yw-1204.doraji.xyz TLS = TLS13 with AES256GCM-SHA384,X25519,PubKeyALG_RSA name = yw-1204.doraji.xyz depth = 0 Issuer CommonName = R3 Issuer Organization = Let's Encrypt notBefore = 2023-03-20T06:03:54Z notAfter = 2023-06-18T06:03:53Z Subject CommonName = yw-1204.doraji.xyz pkey sha256 [matched] <- 3 1 1 b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f depth = 1 Issuer CommonName = ISRG Root X1 Issuer Organization = Internet Security Research Group notBefore = 2020-09-04T00:00:00Z notAfter = 2025-09-15T16:00:00Z Subject CommonName = R3 Subject Organization = Let's Encrypt pkey sha256 [nomatch] <- 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d depth = 2 Issuer CommonName = DST Root CA X3 Issuer Organization = Digital Signature Trust Co. notBefore = 2021-01-20T19:14:03Z notAfter = 2024-09-30T18:14:03Z Subject CommonName = ISRG Root X1 Subject Organization = Internet Security Research Group pkey sha256 [nomatch] <- 2 1 1 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 yw-1204.doraji.xyz[2a03:ebc0:5000:12::10]: pass: TLSA match: depth = 0, name = yw-1204.doraji.xyz TLS = TLS13 with AES256GCM-SHA384,X25519,PubKeyALG_RSA name = yw-1204.doraji.xyz depth = 0 Issuer CommonName = R3 Issuer Organization = Let's Encrypt notBefore = 2023-03-20T06:03:54Z notAfter = 2023-06-18T06:03:53Z Subject CommonName = yw-1204.doraji.xyz pkey sha256 [matched] <- 3 1 1 b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f depth = 1 Issuer CommonName = ISRG Root X1 Issuer Organization = Internet Security Research Group notBefore = 2020-09-04T00:00:00Z notAfter = 2025-09-15T16:00:00Z Subject CommonName = R3 Subject Organization = Let's Encrypt pkey sha256 [nomatch] <- 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d depth = 2 Issuer CommonName = DST Root CA X3 Issuer Organization = Digital Signature Trust Co. notBefore = 2021-01-20T19:14:03Z notAfter = 2024-09-30T18:14:03Z Subject CommonName = ISRG Root X1 Subject Organization = Internet Security Research Group pkey sha256 [nomatch] <- 2 1 1 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 Since your certificate is from Let's Encrypt, you've probably configured automatic renewal. If you haven't also implemented *monitoring* of your DANE TLSA configuration that checks whether the TLSA records match the certificate chain, you should do that immediately, and ideally before publishing TLSA records for any servers carrying "non-test" traffic. You can publish TLSA records for some test host with a self-signed cert, and check monitoring detects incorrect TLSA records when mismatched TLSA records are configured (and is not complaining when the TLSA records are correct). You then also need to make sure that your certificate rollover process is robust, and either keeps the public key unchanged, or you pre-publish matching TLSA records for future keys alongside current keys. Setting up inbound DANE requires operational diligence. Do consider implemting DANE, but not as a fashion statement, rather only because you understand how to coordinate certificate management with DANE TLSA record upkeep. -- Viktor. P.S. Your certificate chain from Let's Encrypt includes a cross-cert for the ISRG root from the expired DST root. This is obsolete, if using "certbot", make sure your "renewal.conf" includes the "reuse_key" and "preferred_chain" settings below in the "[renewalparams]" setction. [renewalparams] reuse_key = True preferred_chain = ISRG Root X1 ... adjust accordingly if using some other ACME client. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
On Thu, May 18, 2023 at 09:22:34PM +0900, Byung-Hee HWANG via Postfix-users wrote: > Byung-Hee HWANG via Postfix-users writes: > > > Now i added DNSSEC. Currently it is being registra job. 10 minutes ago, > > i did make some DS record at Cloudfalre. > > > > Thanks to Joachim, Patrick and raf ^^^ > > And now i added TLSA record for only *outbond* smtp server, > <>. I read Patrick's blog[1]. Still i'm not sure my > setting is OK. > > And i did update(add) tls_policy: > > debian.orgdane > .debian.org dane > postfix.org dane-only > sys4.de dane-only > dukhovni.org dane-only > > > > [1] https://blog.sys4.de/blog/outbound-dane/ > Ah now i see log as *OK* signal: yw-1204 postfix/smtp[27985]: Verified TLS connection established to list.sys4.de[188.68.34.52]:25: TLSv1.3 with ... Wow! Now i'm DANE user!! And i added <> at tls_policy as dane-only. Thanks, Byung-Hee from South Korea ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
Byung-Hee HWANG via Postfix-users writes: > Now i added DNSSEC. Currently it is being registra job. 10 minutes ago, > i did make some DS record at Cloudfalre. > > Thanks to Joachim, Patrick and raf ^^^ And now i added TLSA record for only *outbond* smtp server, <>. I read Patrick's blog[1]. Still i'm not sure my setting is OK. And i did update(add) tls_policy: debian.org dane .debian.org dane postfix.org dane-only sys4.de dane-only dukhovni.orgdane-only [1] https://blog.sys4.de/blog/outbound-dane/ Sincerely, Byung-Hee -- ^고맙습니다 _布德天下_ 감사합니다_^))// ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
Now i added DNSSEC. Currently it is being registra job. 10 minutes ago, i did make some DS record at Cloudfalre. Thanks to Joachim, Patrick and raf ^^^ Sincerely, Byung-Hee ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
raf via Postfix-users writes: > On Thu, May 11, 2023 at 03:17:21PM +0900, Byung-Hee HWANG via Postfix-users > wrote: > >> Hellow Postfix hackers, >> >> I have a questions while reading DANE docs. Is DNSSEC mandotary? For >> making DANE mail server. >> >> For now i'm running two postfix servers in public. Actually i'm beginner >> in both DANE and DNSSEC. >> >> Any comments welcome! >> >> Sincerely, Byung-Hee > > Hi Byung-Hee, > > As others have said, if you want incoming DANE, you need DNSSEC. > Bind9 makes it incredibly easy to enable DNSSEC. It's literally > two extra lines in your configuration (unless you get fancy with > automatic expiry and rollover - and that's easy too), plus you > need to supply some information to your domain registrar for them > to put into their servers. If your domain registrar doesn't support > DNSSEC, or doesn't make it easy, find one that does. You'll need > to interact with them every time you rollover your DNSSEC keys > (e.g., maybe annually). Thank you! I'll regard it, step by step. > As for the TLSA records you need to create for your mail servers, > I recommend my "danectl" program which can generate TLSA records > for you to publish in the DNS, and you can use it to monitor that > they have been published. Recent versions include a couple of adapters > to help publish the TLSA records in the DNS, but only if you edit your > own bind9 zone files or use nsupdate for a dynamic zone. A big > prerequisite of danectl is certbot to handle the actual key/certificate > generation. danectl doesn't work with any other ACME client. Yes i did check it danectl by Googling, thanks! > There are technically many ways to do TLSA DANE but only one great > way (TLSA 3 1 1 current + next) which is what danectl supports. > The idea is to always have two keys/certificates and their corresponding > TLSA records available for use all the time: the current one, and the > next one. Whenever you want to rollover your key, you can immediately > switch to the next one which is already published in the DNS and > ready to go while you prepare the new next key/certificate and its > corresponding TLSA record (for the next rollover). This ensures that > every rollover works seamlessly because you never have the situation > where things aren't working while your TLSA records are propagating > around the DNS because they were published well before they were > required. > > Here are some wikis that might help: > > https://github.com/baknu/DANE-for-SMTP/wiki > https://github.com/internetstandards/toolbox-wiki > > cheers, Thanks raf! At above wiki, i found EMSP guide line in Germany. Because my mail server (yw-1204.doraji.xyz) is located in Frankfurt, Germany. All docs and comments are useful for me. Thanks again raf! Sincerely, Byung-Hee -- ^고맙습니다 _布德天下_ 감사합니다_^))// ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
On Thu, May 11, 2023 at 03:17:21PM +0900, Byung-Hee HWANG via Postfix-users wrote: > Hellow Postfix hackers, > > I have a questions while reading DANE docs. Is DNSSEC mandotary? For > making DANE mail server. > > For now i'm running two postfix servers in public. Actually i'm beginner > in both DANE and DNSSEC. > > Any comments welcome! > > Sincerely, Byung-Hee Hi Byung-Hee, As others have said, if you want incoming DANE, you need DNSSEC. Bind9 makes it incredibly easy to enable DNSSEC. It's literally two extra lines in your configuration (unless you get fancy with automatic expiry and rollover - and that's easy too), plus you need to supply some information to your domain registrar for them to put into their servers. If your domain registrar doesn't support DNSSEC, or doesn't make it easy, find one that does. You'll need to interact with them every time you rollover your DNSSEC keys (e.g., maybe annually). As for the TLSA records you need to create for your mail servers, I recommend my "danectl" program which can generate TLSA records for you to publish in the DNS, and you can use it to monitor that they have been published. Recent versions include a couple of adapters to help publish the TLSA records in the DNS, but only if you edit your own bind9 zone files or use nsupdate for a dynamic zone. A big prerequisite of danectl is certbot to handle the actual key/certificate generation. danectl doesn't work with any other ACME client. There are technically many ways to do TLSA DANE but only one great way (TLSA 3 1 1 current + next) which is what danectl supports. The idea is to always have two keys/certificates and their corresponding TLSA records available for use all the time: the current one, and the next one. Whenever you want to rollover your key, you can immediately switch to the next one which is already published in the DNS and ready to go while you prepare the new next key/certificate and its corresponding TLSA record (for the next rollover). This ensures that every rollover works seamlessly because you never have the situation where things aren't working while your TLSA records are propagating around the DNS because they were published well before they were required. Here are some wikis that might help: https://github.com/baknu/DANE-for-SMTP/wiki https://github.com/internetstandards/toolbox-wiki cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
Dear Patrick, Patrick Ben Koetter via Postfix-users writes: > (...) > You don't need DNSSEC for your DNS zone *if* your server should DANE-verify > other DANE enabled receiver platforms. In this case all you need to do is run > a DNSSEC-verifying DNS resolver on your server (not systemd-resolved) and > configure Postfix to use DANE when it sends messages: Wow! Good news ^^^ > smtp_dns_support_level = dnssec > smtp_tls_security_level = dane > smtp_tls_loglevel = 1 Thanks for kind example! > I do recommend to enable at least DANE on the outbound side to let your users > participate from the higher level of security. Thank you! > > P.S. > See also: https://blog.sys4.de/blog/outbound-dane/, which I've written in > German. Don't worry, i can read that docs. Google translator is so good. Sincerely, Byung-Hee -- ^고맙습니다 _布德天下_ 감사합니다_^))// ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
Hey Byung-Hee! * Byung-Hee HWANG via Postfix-users : > Hellow Postfix hackers, > > I have a questions while reading DANE docs. Is DNSSEC mandotary? For > making DANE mail server. > > For now i'm running two postfix servers in public. Actually i'm beginner > in both DANE and DNSSEC. you need DNSSEC enable your DNS zone for DANE *if* you want to offer DANE on your inbound side because those who want to send to your mailserver will need DNSSEC security to ensure their server will communicate with the right server (read: your server). You don't need DNSSEC for your DNS zone *if* your server should DANE-verify other DANE enabled receiver platforms. In this case all you need to do is run a DNSSEC-verifying DNS resolver on your server (not systemd-resolved) and configure Postfix to use DANE when it sends messages: smtp_dns_support_level = dnssec smtp_tls_security_level = dane smtp_tls_loglevel = 1 I do recommend to enable at least DANE on the outbound side to let your users participate from the higher level of security. p@rick P.S. See also: https://blog.sys4.de/blog/outbound-dane/, which I've written in German. -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
Joachim Lindenberg via Postfix-users writes: > DNSSEC is mandatory for DANE. Hellow Joachim! Thanks for kind replying ^^^ Sincerely, Byung-Hee -- ^고맙습니다 _布德天下_ 감사합니다_^))// ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
DNSSEC is mandatory for DANE. Greetings, Joachim -Ursprüngliche Nachricht- Von: Byung-Hee HWANG via Postfix-users Gesendet: Donnerstag, 11. Mai 2023 08:17 An: Postfix Users Betreff: [pfx] DANE and DNSSEC Hellow Postfix hackers, I have a questions while reading DANE docs. Is DNSSEC mandotary? For making DANE mail server. For now i'm running two postfix servers in public. Actually i'm beginner in both DANE and DNSSEC. Any comments welcome! Sincerely, Byung-Hee -- ^고맙습니다 _布德天下_ 감사합니다_^))// ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
