On Wed, May 29, 2013 at 02:16:37AM -0700, Bry8 Star wrote:
> 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),
In which case they'd better make sure that the server's certificate
chain (sent during the TLS handshake) includes the TA certificate,
because the verifier can't be expected to have a copy. Naive
implementations may not even handle 2 0 0 correctly.
> * 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).
This is the most robust use case. The name in the certificate
should not matter, but naive implementations may perform erroneous
name checks here, so if possible include the TLSA RR base domain
as a DNS subjectAltName in the peer certificate.
> 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.
Until browsers support DANE. Browser support for DANE should be
reasonably common before HTTPS servers (serving the public at large)
start employing usage 2/3 certificates that are not valid with
respect to the existing public CA PKI.
> 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.
IMHO the public CA PKI is irreparably broken, and provides little
additional assurance. There is little reason to public 0/1 or even
2 when 3 is substantially more robust.
> 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.
No, all that's required is that during the transition your certificates
are still issued by a public CA that non DANE aware clients can verify.
There is no reason to public 0/1 when 3 matches the same certificate.
I expect that browsers will support all the usages.
> 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 ? !
They should not, and I expect will not, once they support DANE.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
