THANKS for all the help as always, and for very very helpful suggestions toward improving this "specific" (not regular purpose) configuration.
Reconfiguring based on Viktor's last post's suggestion (suggestion
which are suitable and correct for this specific, (not a regular,)
configuration, and suitable with its objectives), and also
extending/improving my own previous configuration, and so, here is
another reduced edition:
This system now (still) using 4 servers: S-1, S-2, IM-1, IM-2. If
anyone wants to, can transfer IM-1 server's all services inside S-1
server, and transfer IM-2 services inside S-2, if they have enough
resources for providing all services. Then various DNS RRs can be
reduced even further.
A zone file:
; Lines that starts with ";" symbol are inactive.
domA.tld. 3600 IN SOA s1.domA.tld. hostmaster.domA.tld. 2013052910
18000 3600 864000 3600
; Below two lines are actually active in actual zone file.
;domA.tld. 3000 IN DNSKEY 256 3 8 HEX_CODE_KEY
;domA.tld. 3000 IN DNSKEY 257 3 8 HEX_CODE_KEY
; Since it is targeted+geared for "more secured"
; and "higher strength" encrypted services, above will
; be changed: dnskey's strength will be increased.
; Skipping NSEC3. As DNSSEC management software,
; can handle it automatically.
domA.tld. 3000 IN NS s1.domA.tld.
domA.tld. 3000 IN NS s2.domA.tld.
domA.tld. 300 IN A IP.ADRS_S-1_IPv4
domA.tld. 300 IN A IP.ADRS_S-2_IPv4
domA.tld. 300 IN AAAA IP::ADRS_S-1_IPv6
domA.tld. 300 IN AAAA IP::ADRS_S-2_IPv6
; IP-address of "s" will be "round-robin" based:
s.domA.tld. 300 IN A IP.ADRS_S-1_IPv4
s.domA.tld. 300 IN A IP.ADRS_S-2_IPv4
s.domA.tld. 300 IN AAAA IP::ADRS_S-1_IPv6
s.domA.tld. 300 IN AAAA IP::ADRS_S-2_IPv6
s1.domA.tld. 900 IN A IP.ADRS_S-1_IPv4
s2.domA.tld. 900 IN A IP.ADRS_S-2_IPv4
s1.domA.tld. 900 IN AAAA IP::ADRS_S-1_IPv6
s2.domA.tld. 900 IN AAAA IP::ADRS_S-2_IPv6
; IP-address of "im" will be "round-robin" based:
im.domA.tld. 300 IN A IP.ADRS_S-IM-1_IPv4
im.domA.tld. 300 IN A IP.ADRS_S-IM-2_IPv4
im.domA.tld. 300 IN AAAA IP::ADRS_S-IM-1_IPv6
im.domA.tld. 300 IN AAAA IP::ADRS_S-IM-2_IPv6
im1.domA.tld. 900 IN A IP.ADRS_S-IM-1_IPv4
im2.domA.tld. 900 IN A IP.ADRS_S-IM-2_IPv4
im1.domA.tld. 900 IN AAAA IP::ADRS_S-IM-1_IPv6
im2.domA.tld. 900 IN AAAA IP::ADRS_S-IM-2_IPv6
; IP-address of "s" will be "round-robin" based:
www.domA.tld. 300 IN CNAME s.domA.tld.
m.domA.tld. 300 IN CNAME s.domA.tld.
_http._tcp.domA.tld. 300 IN SRV 0 0 80 www.domA.tld.
_https._tcp.domA.tld. 300 IN SRV 0 0 443 www.domA.tld.
_http._tcp.www.domA.tld. 300 IN SRV 0 0 80 www.domA.tld.
_https._tcp.www.domA.tld. 300 IN SRV 0 0 443 www.domA.tld.
_http._tcp.m.domA.tld. 300 IN SRV 0 0 80 m.domA.tld.
_https._tcp.m.domA.tld. 300 IN SRV 0 0 443 m.domA.tld.
domA.tld. 300 IN MX 10 s.domA.tld.
domA.tld. 1800 IN MX 20 s1.domA.tld.
domA.tld. 1800 IN MX 20 s2.domA.tld.
_smtp._tcp.domA.tld. 300 IN SRV 10 0 25 s.domA.tld.
_smtp._tcp.s.domA.tld. 300 IN SRV 10 0 25 s.domA.tld.
_smtp._tcp.s.domA.tld. 1800 IN SRV 20 0 25 s1.domA.tld.
_smtp._tcp.s.domA.tld. 1800 IN SRV 30 0 25 s2.domA.tld.
_submission._tcp.domA.tld. 300 IN SRV 10 0 587 s.domA.tld.
_submission._tcp.s.domA.tld. 1800 IN SRV 10 0 587 s.domA.tld.
_submission._tcp.s.domA.tld. 1800 IN SRV 20 0 587 s1.domA.tld.
_submission._tcp.s.domA.tld. 1800 IN SRV 30 0 587 s2.domA.tld.
_imaps._tcp.domA.tld. 300 IN SRV 0 0 993 s.domA.tld.
_imaps._tcp.s.domA.tld. 300 IN SRV 0 0 993 s.domA.tld.
_imaps._tcp.s.domA.tld. 900 IN SRV 1 0 993 s1.domA.tld.
_imaps._tcp.s.domA.tld. 900 IN SRV 2 0 993 s2.domA.tld.
_pops._tcp.domA.tld. 300 IN SRV 0 0 995 s.domA.tld.
_pops._tcp.s.domA.tld. 300 IN SRV 1 0 995 s.domA.tld.
_pops._tcp.s.domA.tld. 900 IN SRV 2 0 995 s1.domA.tld.
_pops._tcp.s.domA.tld. 900 IN SRV 3 0 995 s2.domA.tld.
; Skipping SMTP (Port 26) based 3rd email-server.
_sip._tcp.domA.tld. 360 IN SRV 0 0 5060 im.domA.tld.
_sip._tcp.domA.tld. 360 IN SRV 1 0 15060 im.domA.tld.
_sip._tcp.im.domA.tld. 360 IN SRV 0 0 5060 im.domA.tld.
_sip._tcp.im.domA.tld. 360 IN SRV 1 0 15060 im.domA.tld.
; Once encrypted Port (5061, 15061) SIP services are working
; completely, then non-encrypted ports will be removed.
_sips._tcp.domA.tld. 360 IN SRV 0 0 5061 im.domA.tld.
_sips._tcp.domA.tld. 360 IN SRV 1 0 15061 im.domA.tld.
_sips._tcp.im.domA.tld. 360 IN SRV 0 0 5061 im.domA.tld.
_sips._tcp.im.domA.tld. 360 IN SRV 1 0 15061 im.domA.tld.
; And multiple XMPP services are configured
; similar to above SIP services:
_xmpp-client._tcp.domA.tld. 360 IN SRV 0 0 5222 im.domA.tld.
_xmpp-client._tcp.domA.tld. 360 IN SRV 1 0 15222 im.domA.tld.
_xmpp-client._tcp.im.domA.tld. 360 IN SRV 0 0 5222 im.domA.tld.
_xmpp-client._tcp.im.domA.tld. 360 IN SRV 1 0 15222 im.domA.tld.
; Skipping 4 lines (secured sip client port 5223, 15223).
; Once encrypted Port (5223, 15223) XMPP services are working
; completely, then non-encrypted ports will be removed.
_xmpp-server._tcp.domA.tld. 360 IN SRV 0 0 5269 im.domA.tld.
_xmpp-server._tcp.domA.tld. 360 IN SRV 1 0 5269 im.domA.tld.
_xmpp-server._tcp.im.domA.tld. 360 IN SRV 0 0 5269 im.domA.tld.
_xmpp-server._tcp.im.domA.tld. 360 IN SRV 1 0 15269 im.domA.tld.
; Skipping rest of XMPP related SRV declarations.
; And multiple IRC services are configured
; similar to above SIP/XMPP services.
_irc._tcp.domA.tld. 360 IN SRV 0 0 6667 im.domA.tld.
_irc._tcp.domA.tld. 360 IN SRV 1 0 6669 im.domA.tld.
_irc._tcp.im.domA.tld. 360 IN SRV 0 0 6667 im.domA.tld.
_irc._tcp.im.domA.tld. 360 IN SRV 1 0 6669 im.domA.tld.
; Skipping 4 lines (secured IRC port 6697, 6699).
; Once encrypted Port (6697, 6699) IRC services are working
; completely, then non-encrypted ports will be removed.
; Skipped/omitted other DNS RRs.
; RRSIGs are not mentioned, but they exist when DNSSEC signed.
= 70 lines of common DNS RRs.
In previous config there were 113 lines of common DNS RRs.
What is the common service name for the secure port (5223) of
xmpp-client ?
What is the common service name for the secure port of (6697) od IRC ?
And TLS / SSL cert full chain components:
EE/Server {s, im, www, m}
\ <-- IA {domA.tld}
\ <-- CA/TA {Root-CA}.
Higher strength TLS/SSL cert.
And here are TLSA/DANE related DNS RRs:
_443._tcp.www.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
_443._tcp.www.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_www-domA-crt
_443._tcp.m.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
_443._tcp.m.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_m-domA-crt
; Port 60 is Unassigned. Not used by any real service.
; And, using such form of TLSA makes more sense:
; _port._proto.zone. [TTL] IN TLSA u s m C_A_D
_60._tcp.s.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
_60._tcp.s.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s-domA-crt
_25._tcp.s.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
_25._tcp.s1.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
_25._tcp.s2.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
_587._tcp.s.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
_587._tcp.s1.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
_587._tcp.s2.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
_993._tcp.s.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
_993._tcp.s1.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
_993._tcp.s2.domA.tld. 360 IN CNAME _60._tcp.s.domA.tld.
; Skipping SMTP (Port 26) based 3rd email-server.
_60._tcp.im.domA.tld. 300 IN TLSA 2 0 1 C_A_D_of_TA-crt
_60._tcp.im.domA.tld. 300 IN TLSA 1 0 0 C_A_D_of_im-domA-crt
_5061._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld.
_15061._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld.
_5223._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld.
_15223._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld.
_5269._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld.
_15269._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld.
_6697._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld.
_6699._tcp.im.domA.tld. 300 IN CNAME _60._tcp.im.domA.tld.
= 8 TLSA lines/rr, and 17 related CNAME lines/rr.
= 25 total TLSA related lines/rr.
In previous configuration, there were 12 TLSA lines/rr, and 22
related CNAME lines/rr, so in total 34 total TLSA related lines/rr.
May be i should use "*" instead of "_60". Should carry more correct
meaning & intention.
C_A_D = Certificate Association Data.
Now showing few other declared components:
gpg --export [email protected] > \
domA-signing_GPG_KEY-ID.pubkey.bin
make-dns-cert -n domA-signing.domA.tld. \
-k domA-signing_GPG_KEY-ID.pubkey.bin > \
domA-signing_GPG_KEY-ID.pub.big.cert
Then codes from "domA-signing_GPG_KEY-ID.pub.big.cert" file can be
placed in zone file, such as below DNS RR, in place of <full_GPG-KEY>.
Publish/Declare public-side portion of GPG-KEY. Do not share
private key side. Here "full_GPG-KEY" = "Entire GPG/PGP-KEY's
binary code", used in zone file, with it's equivalent hexadecimal
code form (RFC 3548).
FPR = fpr = Fingerprint.
When files, software are signed with GPG/PGP-KEY, which is
associated with "[email protected]" and "[email protected]"
email-addresses, then, (based on RFC 4398) :
domA-signing.domA.tld. 1800 IN CERT PGP 0 0 <full_GPG-KEY>
file-signing.domA.tld. 1800 IN CNAME domA-signing.domA.tld.
HEX-CODE-of-FULL-GPG-KEY-FINGERPRINT 1800 IN CERT PGP 0 0 <full_GPG-KEY>
HEX-CODE-of-SHORT-GPG-KEY-FINGERPRINT 1800 IN CERT PGP 0 0
<full_GPG-KEY>
; Declaring a developer's GPG-KEY:
developer.name.domA.tld. 1800 IN CERT PGP 0 0 <full_GPG-KEY>
If GPG-KEY associated with this above "[email protected]"
email-adrs has this HEX-CODE-of-FULL-GPG-KEY-FINGERPRINT, then add
another DNS RR:
HEX-CODE-of-FULL-GPG-KEY-FINGERPRINT 1800 IN CERT PGP 0 0 <full_GPG-KEY>
Objective is to allow client-side users to get authentic &
pre-declared (public-key portion of) signing GPG-KEY from DNSSEC
based response, and verify downloaded files with it. Many websites
still do not share their GPG-KEY in their DNS, and GPG-KEY text
files are either on a non-encrypted HTTP (port 80) based web-page !
or, on an encrypted HTTPS (port 443) based webpage, but SSL cert is
not declared in TLSA DNS RR !
Caution on CERT, TLSA and other DNS records which have slightly
larger data : Each single active line in DNS, (or, The RDATA field
in EACH dns RR (resource record) in DNS protocol) may hold upto
65535 octets (64kb) or less data/payload size. So do not exceed
that, in any/one line.
; SSHFP: RFC 6594, 4255, 5656, 4716:
; do not use SHA-1 based SSH-keys:
s1.domA.tld. 900 IN SSHFP 3 2 Hex_SHA-256_of_SSH-Key
s2.domA.tld. 900 IN SSHFP 3 2 Hex_SHA-256_of_SSH-Key
im1.domA.tld. 900 IN SSHFP 3 2 Hex_SHA-256_of_SSH-Key
im2.domA.tld. 900 IN SSHFP 3 2 Hex_SHA-256_of_SSH-Key
Received from Viktor Dukhovni, on 2013-06-27 3:14 PM:> On Thu, Jun
27, 2013 at 01:08:53PM -0700, Bry8 Star wrote:
>
>> ; Port 60 is Unassigned. Not used by any real service.
>> _60._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
>> _60._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s1-domA-crt
>> _60._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
>> _60._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s2-domA-crt
>
> Publishing "1 0 0" is unwise, full certificates are too big for
> publishing via DNS. Also publishing both a TA and and EE association
> is unwise. Pick one of "0 0 1", "1 0 1", "2 0 1" or "3 0 1":
>
> 2.0.1.tlsa.example.com. IN TLSA 2 0 1 <TA-certificate-SHA256-digest>
>
I think, What you are suggesting is not accurate for this specific
configuration. In below is my "own" explanation of why:
ZO = Zone Operator . D-O = Domain-Owner.
A ZO/D-O type of users must choose what is right for their own
configuration & system, not what i or someone else would suggest
them suddenly without understanding the purpose/objectives & more
details of a configuration and system.
I think, for general configuration and when used for general
purpose, then what you have suggested is best solution.
I think, it will be correct for short time.
When more software and devices will incorporate full DNSSEC and full
DANE support, then combination of two or more TLSA RRs like, "TLSA 2
0 1" and "TLSA 1 0 0", most likely be one of the wise choice. Usage
of multiple TLSAs, where EE TLSA clearly telling to look for a TA/CA
TLSA, should have clearly indicated that sense to a ZO/D-O and to
client(s) and to others. Data bandwidth rate will increase day by
day, it will not go down day by day. Newer software and devices
will incorporate/adopt the next version of DNS, which is DNSSEC, and
will incorporate next version of TLS/SSL solution, which is
DANE/CERT etc, all these entities have no choice, and no reason, for
always and ONLY support only the old-DNS or only support the older
SSL cert technologies, new features must be included and supported,
or else they will be less useful and "old".
A ZO/D-O type of user, for general case/purpose, can remove either
all "TLSA 2 0 1" DNS RRs lines, or, remove all "TLSA 1 0 0" RRs or
change them, and transform or adapt the configuration into what you
are suggesting. I think, I've already mentioned this previously.
And again now one more time here.
And for this specific configuration/case, neither my server side,
and nor my client-side have any such problem of pulling "big" data
and using it.
Is there a chart/list which shows different TLS cert key-sizes, and
it's respective full TLSA actual binary bytes, that is used in wire ?
But this configuration is (targeted / geared-toward / tuned /
will-be-used) for such users who must use necessary high-quality and
latest components which supports full DNSSEC and supports full DANE.
Client-side's TLSA/DANE-preference or TLSA/DANE-settings will
forcefully authenticate entire TLS/SSL cert chain's each component
using multiple TLSAs from DNSSEC based response, for creating
"higher" security. And that is why multiple TLSAs, SSHFP, CERT PGP,
etc and finally, DNSSEC signed zone, are used. Or else, this
configuration would have used mostly or just regular non-encrypted
ports and may be some encrypted ports, and no DNSSEC, no DANE.
If someone cannot do or have what is required to use these services
(for "whatever" number of reasons and factors), then, i will not
stop or down-grade services just for them ! If someone does not
have a good router and fair amount of Internet bandwidth and a
powerful enough computer, then encrypted IP-Phone service will not
work properly, or not work at all, then go somewhere else.
For email services, non-encrypted ports (_143, _110, etc) are not
even used, and not mentioned in this specific configuration. Same
will be done for other ports/services, once encrypted services are
working completely, non-encrypted ports will be completely removed
(unless an encrypted service requires it, and even then, any
non-encrypted service will not be allowed to even initiated/started,
as those can loose password and have other vulnerabilities or
weaknesses, not welcome in this system). This specific
configuration will be used for providing only encrypted connection
based services. That is why the emphasis on using more and more
TLSA/DANE, and DNSSEC, and other DNS & TLS related technologies.
When a full TLS cert is pulled/received from TLS server, and a full
TLSA (1 0 0) is pulled from DNS, and then comparing full TLS cert
code against the full TLSA (1 0 0) C_A_D, is faster ? or slower ?
than such : a TLS cert is pulled from TLS server, and SHA-256 hash
checksum is calculated, and then TLSA (1 0 1) is pulled from DNS and
checked against TLS cert's hash checksum. How many computational
total steps are used in a 64-bits multi-core, multi-threaded
computer for these two scenarios ? Most client-side have such, and,
servers are usually much more powerful. Bandwidth is not a big
factor for now, (for this configuration's system/server-side, and in
its targeted client-side, both side have very high-speed and
high-bandwidth connections).
So PLEASE instruct and HELP to achieve that "higher" or "more
secured" solution, (slightly slow or slow speed of operations will
be tolerated and ok, but lower security will not be tolerated
at-all), that is what i'm asking for, from the 1st post, so please
help related to that, then that will be the CORRECT help for this
specific configuration. Other suggestion not achieving goal, are
not right suggestion for this specific configuration. Someone might
say : i asked for a "more secured" solution where each component is
DNSSEC and DANE authenticated, and using higher encryption strength
TLS certs, then why are you even suggesting wrong things or which is
going to create lower security level or will use un-authenticated or
will use un-declared components !
>
> A trust anchor can be shared across multiple hosts, and multiple services:
>
> _25._tcp.mx1.example.com. IN CNAME 2.0.1.tlsa.example.com.
> _25._tcp.mx2.example.com. IN CNAME 2.0.1.tlsa.example.com.
> _143._tcp.imap.example.com. IN CNAME 2.0.1.tlsa.example.com.
>
THANKS, i've now tried to use the idea from this very very helpful
suggestion & help, in topside configuration. I can definitely apply
the logic on correct ports for this specific configuration : like
_993, _995, _5223 etc.
I should've provided same/one type of service, from a
same/common/shared one service name and provide from all servers,
instead of what i was doing mostly : i used actual (two) server's
hostnames, and used them in/for service hostname for different types
of services.
I was already doing it correctly, but for "www" & "m" services only,
(i was using common service name "www" and a common TLSA for that,
and provide service from both "s1" & "s2" servers using
"round-robin"), and i should have done that for all other services
as well.
Thanks for pointing it out even those remaining mistakes.
>
>> Client-software which is trying to connect with server's secure port
>> 5223, they should still be bale to obtain both TLSA: "TLSA 2 0 1"
>> and "TLSA 1 0 0" and use it for TLS /SSL cert verification for port
>> 5223, and on success, establish encrypted and authenticated
>> communication, right ?
>
> The "2 0 1" is enough, no need for "1 0 0". Each service chain file
> needs to also include the TA certificate and any intermediate
> certificates betweent the TA and the server leaf cert.
>
I think, your this response is also not accurate for this specific
configuration, I'm Not going for and not targeting what is "enough",
objective is/are to reach a more "higher" level of security or "much
more than enough" level of security or close to 100%
authentications. Client side is/will be configured and forced to
check entire TLS/SSL cert chain's each component, (in regex term)
greedily. That is why at-least two TLSA RRs are used. DANE-aware
clients 1st pulls & checks Level-0 / EE / Server TLS/SSL cert,
against the EE TLSA, and here EE TLSA (1 0 0) is clearly indicating
to check EE TLS/SSL cert and it's full TLS/SSL chain (level after
level), and so, eventually, TA TLSA (2 0 1) dns record will be
pulled and checked against Root-CA SSL/TLS cert, and then on
success, the EE SSL/TLS cert will be used for creating encrypted
communication.
IA = Intermediate Authority.
One of the best solution would have been, to have all/100%
component(s) of a TLS chain can be authenticated (for this specific
configuration based solution, there are currently 3/three TLS
components and they are defined or pre-declared in multiple (2 or
more) TLSA RRs for each service/port : (1) "www.domA.tld.",
"m.domA.tld.", "s.domA.tld.", "im.domA.tld." etc server SSL/TLS
certs, checked against their respective EE TLSA ("TLSA 1 0 0") DNS
RRs, (2) "domA.tld." IA SSL /TLS cert, checked against it's
respective (1st) IA TLSA (either via "TLSA 4 64 1" or "TLSA 4 64 2")
DNS RRs, (3) Root-CA SSL cert, checked against it's respective TA
TLSA ("TLSA 2 0 1" or "TLSA 2 0 2") DNS RRs. But now shown &
proposed IA type of TLSA usage is not supported, so now, cannot be
defined, with its exact position, to indicate the IA cert's level
position in a full TLS chain. And another better feature would have
been, when, Server-side and client-side both could/will pull
all/full Keys/Certs from various DNS records and after successful
authentication, use EE cert for encrypted connection or
communication. Only server-side will have a priv_key in their
configuration.
for any user, please avoid suggesting which will leave more
components undeclared, or please avoid wrong suggestion for this
specific configuration, where "more secured" level is expected.
>
>> Any other way to improve this configuration further ? How to make
>> it more secured and encrypted?
>
> The data in DNS is public-key data. There is nothing to encrypt.
>
I made one word mistake here, should have used "system" instead of
"it". Sorry to create confusion and for using wrong word "it". I
meant, system which will use this specific DNS/zone configuration,
how can that system's each component be further more DNSSEC (and
DANE, where applicable) authenticated/secured, and how to make or
configure this system's connection & communication encryption more
higher-strength. DNS/zone records are public and open and
non-encrypted as always. Unless two zones are used, one for
public/outside/external/dmz view, and one for
inside/non-public/private view.
For such "more secured" configuration & system, should i use all 8
kbits server TLS certs, instead of current 4 kbits server TLS certs,
or, should i switch to ECDSA ? for SIP (audio-stream) what type of
TLS cert would be better ? for xmpp, irc what type cert would better
? i think, various TLS cert need to be applied & load-tested to get
a chart. I have some basic ideas on type of certs, what should be
used in which cases, but may be a discussion or a new discussion can
reveal further and better guidance for different cases/scenarios.
>
>
>> How to add more declarations to
>> clearly define all components that are used in the system.
>
> Add fewer declarations to publish just the current and (when rotating
> keys) upcoming certificate association for a single carefully chosen
> (usage, selector, matching-type), and generally use matching type
> 1, with selector 1 as most likely to be stable and compact.
>
>> Need to understand more on NSEC.
>
> You shouldn't need to, the NSEC or NSEC3 records are generated
> automatically by the software that signs your zone file.
>
> If NSEC3 support is not yet universal, you may need to tell this
> software to use NSEC in preference to NSEC3 until NSEC3 support is
> (effectively) universal.
>
That is a big relief, THANKS. Yes, the NSEC3. My very limited
understanding is NSEC is suffice, but it have some exploits, so
NSEC3 is better. If name-servers have enough bandwidth &
computation power, then client-side's full DNSSEC-Resolver will be
burdened a lot when NSEC3 is used ? or NSEC is suffice ?
Thanks for your help,
-- Bright Star.
Received from Mark Andrews, on 2013-06-27 5:29 PM:
>
> In message <[email protected]>, Viktor Dukhovni
> writ
> es:
>> On Thu, Jun 27, 2013 at 01:08:53PM -0700, Bry8 Star wrote:
>>
>>> ; Port 60 is Unassigned. Not used by any real service.
>>> _60._tcp.s1.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
>>> _60._tcp.s1.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s1-domA-crt
>>> _60._tcp.s2.domA.tld. 360 IN TLSA 2 0 1 C_A_D_of_TA-crt
>>> _60._tcp.s2.domA.tld. 360 IN TLSA 1 0 0 C_A_D_of_s2-domA-crt
>>
>> Publishing "1 0 0" is unwise, full certificates are too big for
>> publishing via DNS. Also publishing both a TA and and EE association
>> is unwise. Pick one of "0 0 1", "1 0 1", "2 0 1" or "3 0 1":
>>
>> 2.0.1.tlsa.example.com. IN TLSA 2 0 1 <TA-certificate-SHA256-digest>
>>
>> A trust anchor can be shared across multiple hosts, and multiple services:
>>
>> _25._tcp.mx1.example.com. IN CNAME 2.0.1.tlsa.example.com.
>> _25._tcp.mx2.example.com. IN CNAME 2.0.1.tlsa.example.com.
>> _143._tcp.imap.example.com. IN CNAME 2.0.1.tlsa.example.com.
>>
>>> Client-software which is trying to connect with server's secure port
>>> 5223, they should still be bale to obtain both TLSA: "TLSA 2 0 1"
>>> and "TLSA 1 0 0" and use it for TLS /SSL cert verification for port
>>> 5223, and on success, establish encrypted and authenticated
>>> communication, right ?
>>
>> The "2 0 1" is enough, no need for "1 0 0". Each service chain file
>> needs to also include the TA certificate and any intermediate
>> certificates betweent the TA and the server leaf cert.
>>
>>> Any other way to improve this configuration further ? How to make
>>> it more secured and encrypted?
>>
>> The data in DNS is public-key data. There is nothing to encrypt.
>>
>>
>>> How to add more declarations to
>>> clearly define all components that are used in the system.
>>
>> Add fewer declarations to publish just the current and (when rotating
>> keys) upcoming certificate association for a single carefully chosen
>> (usage, selector, matching-type), and generally use matching type
>> 1, with selector 1 as most likely to be stable and compact.
>>
>>> Need to understand more on NSEC.
>>
>> You shouldn't need to, the NSEC or NSEC3 records are generated
>> automatically by the software that signs your zone file.
>>
>> If NSEC3 support is not yet universal, you may need to tell this
>> software to use NSEC in preference to NSEC3 until NSEC3 support is
>> (effectively) universal.
>
> Truly, one shouldn't use NSEC3 unless one has a need to use NSEC3.
> It is much more expensive on servers and clients. For most zones
> NSEC is all that is needed. For some zones NSEC is the only thing
> that will work.
>
> Mark
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
