Subject: [dane] Pls Consider Supporting Intermediate TLS Certificate, TLSA Usage 4

From: Bry8 Star <[email-masked]>
Date: Fri, 14 Jun 2013 12:59:37 -0700

Please consider to add support for Intermediate Authority TLSA RR Type.

Please correct & improve below paragraphs. Thanks in advance.

In RFC 6698 https://tools.ietf.org/html/rfc6698 Section 7.2 is
showing list of TLSA Certificate Usages, 4-254 Unassigned. And
showing "Applications to the registry can request specific values
that have yet to be assigned."

- - - - - - - - - - - - - - -
2.1.1.  The Certificate Usage Field :
TLSA Usage 4: Certificate usage 4 is used to specify one or more
Intermediate Authority certificate, or the public key of such
certificates, which MUST be used as intermediate trust anchor when
validating the end entity certificate given by the server in TLS.
This certificate usage is sometimes referred to as "intermediate
trust anchors" (ITA) or "intermediate authority anchors" (IA).  When
TLSA Usage 2 is used for the domain, then TLSA Usage 4 allows domain
name administrator to specify new, one or more intermediate trust
anchors (ITA / IA).  When TLSA Usage 0 is used, then TLSA Usage 4
allows to specify one or more pre-existing intermediate or
subordinate CA.  For example, TLSA Usage 4 is used when the domain
issues its own one or more intermediate certificate under a CA or
under a new Trust Anchor (TA) that may or may not exist in end user'
collection of trust anchors.  The target certificate MUST pass PKIX
certification path validation, with any certificate matching the
TLSA record considered to be a intermediate trust anchor for this
certification path validation.
- - - - - - - - - - - - - - -

In RFC 6698 https://tools.ietf.org/html/rfc6698 Section 7.3 is
showing list of TLSA Selectors, 2-254 Unassigned. And showing
"Applications to the registry can request specific values that have
yet to be assigned."

- - - - - - - - - - - - - - -
2.1.2.  The Selector Field:

64 -- Full Intermediate certificate: the (full) intermediate
authority (IA) certificate, at level-1, which issued the End Entity
certificate, MUST have selector value 64.  The IA certificate at
level-2 will use selector value 65 and third full IA will use
selector value 66, and so on, upto 74.  The Certificate binary
structure as defined in [RFC5280]

128 -- SubjectPublicKeyInfo: the intermediate authority (IA)
certificate, at level-1, which issued the End Entity certificate,
MUST have selector value 128.  The IA certificate at level-2 will
use selector value 129 and third IA will use selector value 130, and
so on, upto 138.  DER-encoded binary structure as defined in [RFC5280]
- - - - - - - - - - - - - - -

So this will allow ( 74 - 64 = ) upto 10 intermediate trust anchors
or intermediate CA.  Selector values 64 - 74 are for FULL TLS
certificates. And selector values 128 - 138 are for specifying
intermediate certificate's SubjectPublicKeyInfo data portion.

And quoting from Section A.1.2.2. : "Using the SubjectPublicKeyInfo
selector for association with a certificate in a chain above I1
needs to be decided on a case-by-case basis: there are too many
possibilities based on the issuing CA's practices.  Unless the full
implications of such an association are understood by the
administrator, using selector type 0 is a better option from a
security perspective."

- - - - - - - - - - - - - - -
And, using selector type from 64 to 74 for intermediate
certificates, is a better option for declaring intermediate
certificates.
- - - - - - - - - - - - - - -

And pls also consider to create such a section:

- - - - - - - - - - - - - - -
A.1.2.3.  Selector Type 64-74 & 128-138 (Intermediate Certificate)

For an example, if such certificate chain is used for a domain:

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... )

IA-A, first intermediate authority certificate, at Level-2:

_443._tcp.www.example.com. IN TLSA (
      127 0 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... )
- - - - - - - - - - - - - - -

why such options were not added ?  What pros and cons ?

-- Bright Star.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 14 Jun 2013 20:15:41 +0000

> Please consider to add support for Intermediate Authority TLSA RR Type.

No such support is needed or forthcoming.  DANE already supports
intermediate CAs in usage 0 and usage 2 certificate associations.

Perhaps the chairs can clarify whether this list is really for
naive questions from the public at large or for working-group
discussion and serious questions from implementors.  If my view of
the list charter is misguided, apologies to the OP.

-- 
	Viktor.

---

From: Bry8 Star <[email-masked]>
Date: Fri, 14 Jun 2013 13:41:37 -0700

Just spotted one obvious mistake,
see below in example area.

> Please consider to add support for Intermediate Authority TLSA RR Type.
...<snip/>...
>       127 0 0 8755CDAA8FE24EF16CC0F2C9180... )

TLSA for Level-2 IA-A intermediate cert will be:
... TLSA 65 0 0 ...

>       0 0 0 D2ABDE240D7CD3EE6B4B28C54DF... )
...<snip/>

---

From: Bry8 Star <[email-masked]>
Date: Mon, 24 Jun 2013 06:54:27 -0700

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:

...<snip/>...
> For an example, if such certificate chain is used for a domain:

... if such TLS/SSL certificate ...

_443._tcp.www.example.com. IN TLSA (
     4 64 0 30820454308202BC020900AB58D... )

_443._tcp.www.example.com. IN TLSA (
     4 65 0 8755CDAA8FE24EF16CC0F2C9180... )

>       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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 24 Jun 2013 14:27:14 +0000

> forgot to use "Usage 4" indicator, the reason i posted this msg :(

This is a non-problem, so no solution is required.  Once you've
explicitly associated the leaf certificate via DNSSEC (an EE
association), no further certificates are required to authenticate
the peer.  Any additional chain elements are just wasted bandwidth,
and increase the risk of exceeding DNS payload limits.

One of the key reasons that TA usages (0 and 2) are defined is that
some operators will not want to have to update DNS records every
time an EE certificate changes, so they publish a more stable
issuing TA.  If the DNS is to be updated anyway, simply publishing
the EE certificate with usage 3 is sufficient, the rest of the
chain can simply be omitted from DNS.

With usage 3, DANE-aware clients don't need any additional certificates
in the peer's chain.  Clients that don't support DANE obviously
can't benefit from a hypothentical usage 4.  If your is to simplify
server deployment, just create a self-signed certificate and publish
"IN TLSA 3 1 1 ...".

I think I can safely predict that the proposed usage 4 is not going
to get any support in this working group.

-- 
	Viktor.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 24 Jun 2013 17:55:13 -0400

> to get any support in this working group.

<no hat>
I do not support the proposed usage 4. The utility seems marginal at best, and IMO not worth changing anything over.
</no hat>

<chair hat>
Unless a large number of DANE participants speak up in support of this, I'm asking that we drop this subject.

I'd also like to point back at the pseudonym discussion.
</chair hat>

W

> -- 
> 	Viktor.
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
> 

-- 
Outside of a dog, a book is your best friend, and inside of a dog, it's too dark to read

---

From: DANE <[email-masked]>
Date: Tue, 25 Jun 2013 19:34:06 +0200

On Mon, Jun 24, 2013, Warren Kumari wrote:
...
> <chair hat>
...
> I'd also like to point back at the pseudonym discussion.

Can you please explain what exactly you mean by that
(if you're not just getting bonus points for trying)

n>