Is the following assumption reasonable?
if there are multiple TLSA dane-ee (type 3) records for a particular service, none of which match the current generated record, they can (maybe should) be deleted.
The same "rule" can be could be applied to dane type 2 records.
On Thu, Apr 20, 2017 at 09:27:49AM -0400, John Allen wrote: On Thu, Apr 20, 2017 at 09:34:27AM -0400, John Allen wrote: On Thu, Apr 20, 2017 at 09:36:34AM -0400, John Allen wrote:
Is the following assumption reasonable?
if there are multiple TLSA dane-ee (type 3) records for a particular service, none of which match the current generated record, they can (maybe should) be deleted.
The same "rule" can be could be applied to dane type 2 records.
At all times, TLSA *RRsets* whose TTL has not yet expired (vended by either the primary or a secondary nameserver) need to contain at least one RR which matches the *current* certificate chain of the SMTP server.
To achieve this, the TLSA RRset stored in the master database needs the both the *current* certificate chain and any *new* certificate chain planned for deployment within the cache lifetime of recently served DNS responses.
There is no logical or de jure requirement to serve TLSA records that match *old* no longer deployed certificate chains. As soon as the certificate chain is replaced the old records should go.
In other words, the TLSA records reflect current and near-future certificate chain state, they need not and should not retain past state.
Thanks for speedy reply. I am assuming that past threads on TLSA records still hold. Therefore 3/1/1, with optional 2/1/1 depending upon root cert provenance.
On April 20, 2017 10:52:38 AM Viktor Dukhovni ietf-dane@dukhovni.org wrote:
On Thu, Apr 20, 2017 at 09:27:49AM -0400, John Allen wrote: On Thu, Apr 20, 2017 at 09:34:27AM -0400, John Allen wrote: On Thu, Apr 20, 2017 at 09:36:34AM -0400, John Allen wrote:
Is the following assumption reasonable?
if there are multiple TLSA dane-ee (type 3) records for a particular service, none of which match the current generated record, they can (maybe should) be deleted.
The same "rule" can be could be applied to dane type 2 records.
At all times, TLSA *RRsets* whose TTL has not yet expired (vended by either the primary or a secondary nameserver) need to contain at least one RR which matches the *current* certificate chain of the SMTP server.
To achieve this, the TLSA RRset stored in the master database needs the both the *current* certificate chain and any *new* certificate chain planned for deployment within the cache lifetime of recently served DNS responses.
There is no logical or de jure requirement to serve TLSA records that match *old* no longer deployed certificate chains. As soon as the certificate chain is replaced the old records should go.
In other words, the TLSA records reflect current and near-future certificate chain state, they need not and should not retain past state.
-- Viktor.
P.S. I deliberately said nothing about the certificate usage value, it should be clear why.
On Thu, Apr 20, 2017 at 11:40:20AM -0400, John wrote:
I am assuming that past threads on TLSA records still hold. Therefore 3/1/1, with optional 2/1/1 depending upon root cert provenance.
The provenance of the root cert is irrelevant. From a public CA (let's face it "everyone" is using Let's Encrypt lately) you'd typically use an intermediate CA as your DANE trust anchor.
For a private issuing CA it is more typical to see leaf certs issued directly by a root CA, but still use whatever CA is the direct issuer as the DANE trust-anchor.
I recommend using a private issuer CA for port 25. It is much too easy for backbone operators to mess with BGP routes, MiTM CA "domain validation" challenges and walk away with a fraudulent certificate. Perhaps some day "Certificate Transparency" will help detect the fraud after-the-fact, but "DV" certificates don't provide much more security value than the $0 you pay form them.
You can think of "Let's Encrypt" as opportunistic security for the World-Wide Web. The party doing the unauthenticated leap of faith key pinning is the CA, and then everyone else piggy-backs on the CA's success or failure (of course there are many CAs).
Now certainly not having a cert at all and doing HTTP in the clear is less secure than using a "DV" certificate, and "DV" certificates do protect against passive monitoring. So the "DV" ecosystem is doing some good. But "DV" cannot protect against targetted active attack, and "EV" does not scale.
So, for DANE, though use of "Let's Encrypt" with a combination of "3 1 1" + "2 1 1" TLSA records is a good place to start, a private CA is better. We just need to make using a private CA much easier than it currently is. I'd like to enhance the "postfix tls" CLI to support an issuing trust-anchor some time this year.
If you're wealthy enough to afford "EV" certs, you can of course use an EV-only intermediate for your "2 1 1" (or perhaps in that case "2 0 1") TLSA record. One might hope that "EV" certificate issuance is much more resistant to MiTM or other attempts to obtain fraudulent certificates.
participants (3)
-
John -
John Allen
-
Viktor Dukhovni