Received from Viktor Dukhovni, on 2013-06-13 12:15 PM: > On Thu, Jun 13, 2013 at 06:20:46AM -0700, Bry8 Star wrote: > >> % _443._tcp.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA > > The "2 0 0" TLSA record is unwise, this will give too many naive > DNS implementations in firewalls and the like indigestion with > overly large records and dramatically increases the payload size > in DNS amplification attacks. Avoid "2 0 0" and use "2 1 1" instead, > then make sure to include the corresponding TA certificate in the > server's TLS handshake. > >> C_A_D = Certificate Association Data. Either a Raw/Binary Data, >> DER-encoded full cert, when s=0 & m=0. Or, it can be a hash-code >> (Base64-encoded) of raw-data, when s=1, and m=1 or m=2. In Hex. > > There is no Base64 encoding of any data in TLSA RRs. For matching > type 0, the certificate association data is binary DER, which DNS > query tools display in hex, and hex is also what you put into your > zone file, but the actual record value and wire-format is binary DER. > > The selector has no effect on the value encoding, it chooses between > an X.509 certificate and its SubjectPublicKeyInfo public key. > >> $ openssl x509 -in dom1_tld_IA.crt \ >> -outform der -out C_A_D_of_TA.der >> $ openssl x509 -in My_i-CA.crt \ >> -outform der -out My_i-CA.der >> $ cat My_i-CA.der >> C_A_D_of_TA.der > > Do NOT concatenate DER X.509 certificates. Each DER value encodes > exactly ONE certificate or public key. > >> I (as Domain-owner) want my side NS/DNS-servers to serve FULL DER >> TLS certs. Both TA/Root-CA and EE/Server-Cert. > > You should strongly consider the possibility that this choice is > misguided. > >> and after verifying TLSA EE cert and TLSA cert chain and >> authenticity, then use EE/Server-Cert for creating authentic & >> encrypted secured HTTPS connection. > > In the DANE TLSA model a server certificate is valid if it matches > ANY ONE of the associated TLSA records, you may publish both TA > and EE associations, but clients will not require multiple matches, > if either the TA or the EE TLSA RR passes, the client is done. > >> I basically want both HTTPS-client and HTTPS-server, to retrieve, >> domain-owner declared/published, both TA and EE full certificate >> from DNS, and then after cert chain validation succeeds, use the EE >> cert to create encrypted connection. Without depending on any .crt >> files specified or loaded in/from server or client software. >> Server-side software will only need cert's private_key file portion >> for creating encrypted traffic. > > You won't get what you want. The server will need to configure a > complete chain file including the "2 s m" TA. > >> So based on above expectation, i also want to add these: > > You can stop there, the "above expectation" is unrealistic. >
Thanks for correction and lesson.
My understanding is, current model is designed to depend on TLS
certs (or TLS chain certs), either be delivered via server software,
or, TLS certs (or TLS chain certs) are pre-loaded into clients
software, for creating secured connection. And then check those TLS
certs against TLSA/DANE records to make sure those are indeed
declared & approved by that domain-name's owner/holder. And then on
success, initiate HTTPS (encrypted and) secured communication, and
if TLS certs do not match against TLSA, then fallback to HTTP
(non-encrypted & non-secured) communication. (I suggested in
another post, to show some indicator in client side for these
outcomes, and server-side can also add some type of
meta-record/meta-indicator in a communication, to indicate if
communication is DANE authenticated or not).
What i am expecting, is that, in future, (may be only some, not all)
clients and servers may want to use only DNS (DNSSEC) channel
authenticated TLS cert based encryption, if domain-owner/server-side
and visitors/users/client-side wants to do that specifically. These
will not work now, as i've learned from you, multiple TLS DER cannot
be concatenated in TA TLSA :( *sad*
For a DNS channel Based TLS cert sharing System (PDKIX or DPKIX or
DPKI) to work : only two type of TLSA, as TA and EE, will not be
suffice. Most public CA, and TA PKIX includes, (and self-signed new
TA based TLS cert chain should include) at-least 3 certs in a full
chain : (1) Root-CA/TA, (2) Intermediate CA Cert (IA, ICA), (3) EE :
Server or Domain cert. TLS cert type 1/TA can goto TA TLSA ("2 S
M", "0 S M") dns record, TLS cert type 3/EE can goto EE TLSA ("1 S
M" or "3 S M") dns record, so for the middle, IA type of TLS cert,
or, multiple middle cert, another TLSA indicator dns record is
needed, and that also need to have multiple cert support. Or,
existing TA standard is modified further to allow specifying
multiple certs as cert chain.
So if, addition of a new support, for including multiple cert or
cert chain in existing TA TLSA ("2 S M" or "0 S M") dns records, ...
is not preferred, ... then, ... another new TLSA can be defined &
may be it can be called IA (Intermediate Authority) TLSA. May be it
can have "5 s m". Usage type 5 ?
If declaration/publication of multiple TLS certs for a cert-chain,
is added/adopted into TA TLSA or into IA TLSA ("5 S M"), then, can
each DER encoded cert be kept separated with a LF or other special
binary character ?
I'm sure there are some users who will want to take it one step further.
Encountering DNS amplification : Improvement and New possibilities
cannot be and should not stopped just for this attack ! That would
not be smart solution. Something smart & advanced (that is staying
one step ahead) need to be done. Since DANE DNS (port 53) channel,
and HTTPS (port 443) channel are becoming related and integrated, so
apps in server side will need to understand, after a TLSA query if
HTTPS is not initiated by the same IP, then may be some type of
further limitation/restriction is needed, on both domain server, and
in https server.
-- Bright Star.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
