I've made mistake, on a response to a mistake, sorry :p forgot to use "Usage 4" indicator, the reason i posted this msg :(
According to 1st message, correct records would be:
Received from Bry8 Star, on 2013-06-14 12:59 PM:
> Please consider to add support for Intermediate Authority TLSA RR Type.
>
...<snip/>...
> A.1.2.3. Selector Type 64-74 & 128-138 (Intermediate Certificate)
>
> For an example, if such certificate chain is used for a domain:
>
... if such TLS/SSL certificate ...
> EE <-- IA-B <-- IA-A <-- CA/TA.
>
> It can also be represented in this form:
>
> Level-0 <- Level-1 <- Level-2 <- Level-3.
>
> Then, TLSA RR examples:
>
> EE, end entity, Level-0 certificate:
>
> _443._tcp.www.example.com. IN TLSA (
> 1 0 0 30820307308201efa003020102020... )
>
> IA-B, second intermediate authority certificate, which signed the EE
> certificate, at level-1:
>
> _443._tcp.www.example.com. IN TLSA (
> 64 0 0 30820454308202BC020900AB58D... )
>
_443._tcp.www.example.com. IN TLSA (
4 64 0 30820454308202BC020900AB58D... )
> IA-A, first intermediate authority certificate, at Level-2:
>
> _443._tcp.www.example.com. IN TLSA (
> 127 0 0 8755CDAA8FE24EF16CC0F2C9180... )
>
>
_443._tcp.www.example.com. IN TLSA (
4 65 0 8755CDAA8FE24EF16CC0F2C9180... )
> TA root certificate, at Level-3:
>
> _443._tcp.www.example.com. IN TLSA (
> 2 0 0 D2ABDE240D7CD3EE6B4B28C54DF... )
>
> or, CA root certificate, at Level-3:
>
> _443._tcp.www.example.com. IN TLSA (
> 0 0 0 D2ABDE240D7CD3EE6B4B28C54DF... )
> - - - - - - - - - - - - - - -
>
>
...<snip/>.
_port._proto.[host.]zone.TLD. [TTL] IN TLSA U S M C_A_D
DANE/TLSA's one of the goal/purpose is to increase encryption
security by eliminating confusions, by adding exact identifiable
code for each used TLS public key/cert/component by a server/service
software. So nothing will be done that would increase confusion.
So TLS related components which are used, EACH will be VERY clearly
defined using multiple TLSA dns records, so that there is no
confusion, and so that there is no undefined component/portion.
If DNS traffic need to be reduced (because of such as, older
hardware or narrow bandwidth), zone-operator(s) can use different
matching-Type other than 0. In such case, my own preference will be
to use : server SSL cert's public-key portion's full DER (S is 0, M
is 0) in EE (U is 1 or 3) TLSA dns rr, and for other SSL cert in
chain, i would specify M as 1 or 2 and use relevant 256-bit or
512-bit hash in C_A_D.
If "Usage 4" (for declaring Intermediate SSL cert) is not required,
then, What current DANE (TLSA) related records can be
declared/published for declaring the entire mentioned TLS / SSL cert
chain ? where, more than one Intermediate TLS/SSL cert already
exist in a SSL cert chain. Please show exact example based on SSL
cert chain mentioned here : EE <-- IA-B <-- IA-A <-- CA/TA.
How to very clearly & very definitively specify in DNS, each
component of an entire cert chain ? including clear indication of
what SSL cert is after what in a TLS chain ?
One of the main objective for adding all these TLSA related DNS
records in early, is to reduce, future frequent steps of adding
various TLSA related dns records. Another one of the main reason,
to declare every approved SSL cert very clearly, which is after
what, ... so that, there is no chance of confusion, so that,
every/each component of an entire TLS cert chain used by a TLS
service software, can be completely 100% authenticated against
pre-declared TLSA DNS records.
As a zone/DNS/domain-name(s) owner/holder/operator/administrator, I
mostly want to carry out DNSSEC KSK/ZSK re-signing & rollover
related operations, and spend lesser time on adding/removing
various TLSA DNS records too frequently, and also want to reduce
consequential steps/operations after such changes, doing again &
again too frequently. Based on existing used SSL certs for a
specific port for a specific server software, related multiple TLSA
dns entries will be decided & added, (and server will be tested if
it can withstand for certain numbers of clients & traffic), and then
a stable & optimized solution would be applied and it will not be
touched/changed until a SSL/TLS cert or component of a chain is
changed. TLSA dns record for EE/Server SSL/TLS cert for a specific
port & service, should not be required to change before
approximately either every 9 months (or 1 yr), or, 18 months (or 2
yrs). Unless, SSL / TLS cert (server's private_keys) compromise
occurred or a fault/attack/exploit is/are found, then, obviously
new EE/Server TLS cert will need to be created, and older ones
revoked, and then, newer EE/Server TLSA DNS records are needed to
be added into zone's/domain-name's DNS, and re-sign zone with new
KSK/ZSK, ... My logic behind mentioned 9 or 18 months, is, since
every (approximately around) 18 months, computational FLOPS/power
significantly changes/increases, so should EE/Server TLS/SSL cert's
strength.
-- Bright Star.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
