Subject: Re: [dane] How to use TLSA "2 s m", "3 s m"

From: Bry8 Star <[email-masked]>
Date: Tue, 11 Jun 2013 01:52:38 -0700

Can someone kindly give some PRACTICAL pointers ?
which can used command by command to create these TLSA dns entries ?
for mentioned PKIX structure.

-- Bright Star.

Received from Bry8 Star, on 2013-05-29 2:16 AM:
> How to use TLSA "2 s m" , "3 s m" ?
> 
> Please correct me anytime, my understanding is:
> 
> zone/domain-owners/holders can use simple tools like openssl/gnutls,
> to create their own various types of self-signed private (aka:
> non-public) CA cert or server certs, and then combine such with
> DNSSEC + DANE based implementation in DNS records, when basic/simple
> level of HTTPS/TLS secured web solution/service is expected.
> 
> For those (above) approaches to work:
> 
> * domain-owners/holders can, either use TLSA "2 s m" when they want
> to use their own CA cert and other certs based on that CA cert
> (these approach is aka : TA, non-public CA cert, self-signed private
> CA cert, etc),
> 
> * or, domain-owners/holders can use TLSA "3 s m" when they want to
> provide a secure service by using a very specific & single server
> cert from a very specific server (these approach is aka :
> domain-issued cert, domain cert, EE cert, server cert, no cert
> chain, etc).
> 
> Since domain-owner's/holder's self created certificate is not
> included in any web-browser software, when any visitor/user will try
> to visit such site/zone securely using HTTPS/TLS encrypted
> connections, then web-browser will ask/prompt visitors/users with 1
> or more questions/messages that if visitor/user wants to
> load+trust+use that unknown cert from that site or not.
> 
> cert = certificate , aka = also known as , CA = Certificate
> Authority , TA = Trust Anchor, EE = end entity.
> 
> And, when higher level of secured solution is expected AND when
> extra info are needed to be shown to visitors/users verified by a
> mutually/known Trusted notarizing/vouching type of party, then TLSA
> "u s m" would be "0 s m" or "1 s m". These type of cert comes from
> public CA cert based company, such CA cert are usually pre-included
> in web-browsers or in client software, and usually these companies
> charge a fee/money to issue such domain cert or intermediate CA cert.
> 
> Both of these ("0 s m" , "1 s m") solutions are favored by
> web-browser developing groups, so they kept it in such a condition
> that : it will not create any extra warning and it will not
> ask/prompt visitors/users with a question/message, when a HTTPS/TLS
> based secured site is visited or web service is used.
> 
> Since, domain-owner/holder has publicly declared what exact cert
> he/she/they trusts using TLSA "2 s m" or "3 s m" based dns rr, then
> why web-browser will ask question/prompt visitor/user ? !
> it is not unknown anymore, it is already+clearly declared+known+shown.
> 
> More practical use cases, guidance are needed to be shown publicly
> for both "3 s m" and "2 s m" cases, specially for "2 s m" as it
> involves extra configurations.
> 
> - - - - - - - - - - - - - - - - - - - - - - - - -
> 
> For example, I own 3  domain-names which are related, and want to
> use a common root CA cert for all these 3 domains/zones, so i did
> these, as i have 3 set of server computers tuned for 3 different
> type of tasks, and located in 3 different network locations :
> 
> Self-signed private non-public root CA cert (My_root_CA_cert) -->
> intermediate high-strength CA cert (My_i_CA_1_cert) -->
> dom1.tld_cert --> { www.dom1.tld_cert , m.dom1.tld_cert ,
> mail.dom1.tld_cert , mail2.dom1.tld_cert , ns.dom1.tld_cert ,
> ns2.dom1.tld_cert , livemsg.dom1.tld_cert }
> 
> and then i created for dom2.tld :
> 
> intermediate high-strength CA cert (My_i_CA_1_cert) -->
> dom2.tld_cert --> { www.dom2.tld_cert , m.dom2.tld_cert ,
> mail.dom2.tld_cert , mail2.dom2.tld_cert , ns.dom2.tld_cert ,
> ns2.dom2.tld_cert , livemsg.dom2.tld_cert }
> 
> and so on.
> 
> Physical_Server_1 has:
> * 'www', 'ns' and 'mail' hosts of "dom1.tld" in 3 separate VM instance.
> * above hosts of "dom2.tld".
> * above hosts of "dom3.tld".
> 
> Physical_Server_2 has:
> * 'm', 'ns2' and 'mail2' hosts of "dom1.tld" in 3 separate VM instance.
> * above hosts of "dom2.tld".
> * above hosts of "dom3.tld".
> 
> Physical_Server_3 has:
> * 'livemsg' host of "dom1.tld" in a VM instance, * 'livemsg' host of
> "dom2.tld", * 'livemsg' host of "dom3.tld"
> 
> "dom1.tld" is for providing certain set of tasks/services/projects
> 01. "dom2.tld" is for providing another set of
> tasks/services/projects 02. "dom3.tld" is for providing images,
> videos, etc and may be placed in another server location.
> 
> If Physical_Server_01 is restarted or updated or downed or
> disconnected for some reason, all essential services will be
> delivered to visitors/users from redundant services from
> Physical_Server_02.
> 
> So how many & what DNS RR will "www" host/server for "dom1.tld" will
> exactly need/have for providing DANE based HTTPS service ?
> 
> In apache/nginx server software (HTTPS service daemon), in what
> order it will have to provide those tls/ssl certs ?
> 
> What else need to be configured ?
> 
> Thanks in advance,
> 
> -- Bright Star.
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>