Subject: [dane] Combined TLSA TA (2 S M) and TLSA EE (1 S M) Usage

From: Bry8 Star <[email-masked]>
Date: Thu, 13 Jun 2013 06:20:46 -0700

Please explain/comment more on these:

Conventions, used in this email msg:
* The Beginning "%" symbol (and a space after it), is not used in
any real zone file. ( I have used this symbol used here for this
email post only, just to indicate a begin of a configuration line,
as, multiple time email reply can/may change position or remove
Line-Feed(LF/EOL) indicator ).
* Command-line will start with "$" symbol (and a space after it). Do
not use shown '$' when using in real command.
* When a command-line ("$ ") will show "\" symbol at-end, then bring
below one line after it, and remove the \ symbol.  Here "\" symbol
is indicating "Next-Line is part of This Line".

I'm using such TLS / SSL Chain:

SSL / TLS Certificate Pyramid & Levels :

01 = Level-01 = is TA/Root-CA cert. (My_Root_CA.crt). Self-signed
new my own CA/TA cert.
02 = Level-02 = is an Intermediate CA cert. (My_i-CA.crt). under L-1.
03 = Level-03 = is an Intermediate Authority cert for dom1.tld.
(dom1_tld_IA.crt).  It can only be used to create certs, only under
dom1.tld.
04 = Level-04 = is Server/EE-Certs : { s1.dom1.tld.crt,
s2.dom1.tld.crt, im.dom1.tld.crt, im2.dom1.tld.crt,
www.dom1.tld.crt, m.dom1.tld.crt }

TA = Trust Anchor . CA = Certificate Authority.
IA = Intermediate Authority.
cert = certificate. cert keypair. Both public key portion and
private key portion.
crt = cert's public (key) portion. can be shared.
key / prv.pem = private key portion of cert. do not share.

As a domain-owner, and an operator, etc ... i will be using my own
new self-signed TA (Trust Anchor) cert/bundle (aka, self-signed CA),
so i will need to do these, i understand this part:

% _443._tcp.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.www.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.m.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _25._tcp.s1.dom1.tld.  180 IN TLSA 2 0 0 C_A_D_of_TA
% _993._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _995._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _587._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _25._tcp.s2.dom1.tld.  180 IN TLSA 2 0 0 C_A_D_of_TA
% _993._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _995._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _587._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA

But when only TLSA TA "2 S M" is used, it is indicating, clients and
servers need to use multiple channels (port 80, port 443, port 53)
for related various purpose. :(

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.

Here, to create "C_A_D_of_TA" code-portion :
i will 1st create a DER file (C_A_D_of_TA.der), based on Level-3
dom1_tld_IA.crt file, and then in 2nd step i will append DER code
based on Level-2 My_i-CA.crt file, and then in 3rd step i will
append DER code based on Level-1 My_Root_CA.crt file. (Similar to
what we do for creating TLS chain cert for httpd server software) :

$ 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
$ openssl x509 -in My_Root_CA.crt \
	-outform der -out My_Root_CA.der
$ cat My_Root_CA.der >> C_A_D_of_TA.der

I (as Domain-owner) want my side NS/DNS-servers to serve FULL DER
TLS certs. Both TA/Root-CA and EE/Server-Cert.

Let us assume, i have such dns entries : Here 's1' is server
hostname. So is 's2'.  Visitors & users will access 's1' srvr via
'www' srvc, and access 's2' srvr via 'm' service (service
sub-domain-name) normally.  When/if 's1' srvr is down, then user
will goto 's2' srvr for 'www' srvc, and when 's2' srvr is down then
user will goto 's1' srvr for 'm' srvc:

% dom1.tld. 3600 IN SOA s1.dom1.tld. hostmaster.dom1.tld. 2013052910
18000 3600 864000 3600
% dom1.tld. 3000 IN NS s1.dom1.tld.
% dom1.tld. 3000 IN NS s2.dom1.tld.
% dom1.tld. 300 IN A    IP.ADRS_S-1_IPv4
% dom1.tld. 300 IN A    IP.ADRS_S-2_IPv4
% dom1.tld. 300 IN AAAA IP::ADRS_S-1_IPv6
% dom1.tld. 300 IN AAAA IP::ADRS_S-2_IPv6
% s1.dom1.tld. 900 IN A    IP.ADRS_S-1_IPv4
% s2.dom1.tld. 900 IN A    IP.ADRS_S-2_IPv4
% s1.dom1.tld. 900 IN AAAA IP::ADRS_S-1_IPv6
% s2.dom1.tld. 900 IN AAAA IP::ADRS_S-2_IPv6
% www.dom1.tld. 300 IN CNAME dom1.tld.
% m.dom1.tld. 300 IN CNAME dom1.tld.
% _http._tcp.dom1.tld. 3600 IN SRV 0 0 80 www.dom1.tld.
% _https._tcp.dom1.tld. 3600 IN SRV 0 0 443 www.dom1.tld.
% _http._tcp.www.dom1.tld. 3600 IN SRV 0 0 80 www.dom1.tld.
% _https._tcp.www.dom1.tld. 3600 IN SRV 0 0 443 www.dom1.tld.
% _http._tcp.m.dom1.tld. 3600 IN SRV 0 0 80 m.dom1.tld.
% _https._tcp.m.dom1.tld. 3600 IN SRV 0 0 443 m.dom1.tld.
% dom1.tld. 3600 IN MX 10 s1.dom1.tld.
% dom1.tld. 3600 IN MX 20 s2.dom1.tld.
% _smtp._tcp.dom1.tld. 3600 IN SRV 10 0 25 s1.dom1.tld.
% _smtp._tcp.dom1.tld. 3600 IN SRV 20 0 25 s2.dom1.tld.
% _smtp._tcp.s1.dom1.tld. 3600 IN SRV 10 0 25 s1.dom1.tld.
% _smtp._tcp.s1.dom1.tld. 3600 IN SRV 20 0 25 s2.dom1.tld.
% _smtp._tcp.s2.dom1.tld. 3600 IN SRV 10 0 25 s2.dom1.tld.
% _smtp._tcp.s2.dom1.tld. 3600 IN SRV 20 0 25 s1.dom1.tld.
% _submission._tcp.dom1.tld. 3600 IN SRV 10 0 587 s1.dom1.tld.
% _submission._tcp.dom1.tld. 3600 IN SRV 20 0 587 s2.dom1.tld.
% _submission._tcp.s1.dom1.tld. 3600 IN SRV 10 0 587 s1.dom1.tld.
% _submission._tcp.s1.dom1.tld. 3600 IN SRV 20 0 587 s2.dom1.tld.
% _submission._tcp.s2.dom1.tld. 3600 IN SRV 10 0 587 s2.dom1.tld.
% _submission._tcp.s2.dom1.tld. 3600 IN SRV 20 0 587 s1.dom1.tld.
% _imaps._tcp.dom1.tld. 3600 IN SRV 0 0 993 s1.dom1.tld.
% _imaps._tcp.dom1.tld. 3600 IN SRV 5 0 993 s2.dom1.tld.
% _imaps._tcp.s1.dom1.tld. 3600 IN SRV 0 0 993 s1.dom1.tld.
% _imaps._tcp.s1.dom1.tld. 3600 IN SRV 5 0 993 s2.dom1.tld.
% _imaps._tcp.s2.dom1.tld. 3600 IN SRV 0 0 993 s2.dom1.tld.
% _imaps._tcp.s2.dom1.tld. 3600 IN SRV 5 0 993 s1.dom1.tld.
% _pop3s._tcp.dom1.tld. 3600 IN SRV 0 0 995 s1.dom1.tld.
% _pop3s._tcp.dom1.tld. 3600 IN SRV 5 0 995 s2.dom1.tld.
% _pop3s._tcp.s1.dom1.tld. 3600 IN SRV 0 0 995 s1.dom1.tld.
% _pop3s._tcp.s1.dom1.tld. 3600 IN SRV 5 0 995 s2.dom1.tld.
% _pop3s._tcp.s2.dom1.tld. 3600 IN SRV 0 0 995 s2.dom1.tld.
% _pop3s._tcp.s2.dom1.tld. 3600 IN SRV 5 0 995 s1.dom1.tld.

I want, FUTURE FULL DANE & DNSSEC supported
web-browsers/HTTPS-clients (and httpd (HTTP, HTTPS) servers) to
pull/retrieve BOTH TA & EE type of certs from DNS, like : 1st
pull/retrieve FULL authentic EE/server-cert from TLSA dns ("1 S M" &
"3 S M" cases), and (in 2nd step), also pull/retrieve new
self-signed TA ("TLSA 2 S M"), or public CA ("TLSA 0 S M") from DNS
record (if it exist there and if required for TLS chain validation),
and after verifying TLSA EE cert and TLSA cert chain and
authenticity, then use EE/Server-Cert for creating authentic &
encrypted secured HTTPS connection.

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.

So based on above expectation, i also want to add these:

% _443._tcp.www.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_www_Srvr-Cert
% _443._tcp.m.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_m_Srvr-Cert

Or, am i suppose to add these ?

% _443._tcp.www.dom1.tld. 180 IN TLSA 3 0 0 C_A_D_of_www_Srvr-Cert
% _443._tcp.m.dom1.tld. 180 IN TLSA 3 0 0 C_A_D_of_m_Srvr-Cert

I will create C_A_D_of_www_Srvr-Cert.der like this:
$ openssl x509 -in www_dom1_tld.crt \
	-outform der \
	-out C_A_D_of_www_Srvr-Cert.der

And for other certs:
$ openssl x509 -in m_dom1_tld.crt \
	-outform der \
	-out C_A_D_of_m_Srvr-Cert.der
$ openssl x509 -in s1_dom1_tld.crt \
	-outform der \
	-out C_A_D_of_s1_Srvr-Cert.der
$ openssl x509 -in s2_dom1_tld.crt \
	-outform der \
	-out C_A_D_of_s2_Srvr-Cert.der

So for my case, i will be adding both "TLSA 1 0 0" and "TLSA 2 0 0",
full certificates.  To me, adding both TLSA "2 0 0" and "1 0 0" with
full certs, makes more sense, specially when domain-owner will be
using their own new self-signed/TA cert based solution.  Then client
and server both can retrieve the TA and EE type cert using only one
channel, DNS-channel, port 53.  I want to call it or treat it, as, a
Complete TLSA declaration, as it eliminates any chance of confusion,
and reduces TLS obtain & validation related steps, as it can easily
obtain all necessary full TLS certs from DNS records, authenticated
by DNSSEC.

I'm trying to say via DNS ... here (TLSA 1 0 0) is my server's
self-signed full EE/server-cert, and here (TLSA 2 0 0) is my own &
new self-signed full Root-CA/TA cert bundle, ... ( so, you(client)
must use these (TA & EE certs) to validate the cert chain. and then
on success, use the EE cert for creating HTTPS secured connection).

I want to support various & mixed channel based solutions, so i will
also do these : I will add both TLSA TA "2 0 0" and TLSA EE "1 0 0"
as mentioned in above.  So that, clients & servers both side can
still obtain both TA & EE type of TLSA records via DNS channel (port
53).  And i will also serve/share full TLS cert chain/bundle-file
from HTTPS-server (apache/httpd) service software.  So that, clients
& servers both side can still obtain (1) server/EE-cert and rest of
the TLS cert chain's linked certs (if server/EE-cert requires), via
HTTPS channel (port 443) and/or using OCSP channel (port 80) for TLS
cert's PKIX validity).

I want, client & server software able to obtain & use entire EE cert
(from TLSA "1 S M" or TLSA "3 S M"), and i want them able to obtain
& use entire TA cert chain (from TLSA "2 S M" or TLSA "0 S M").

So for my case i will and want-to, use TLSA like this:

% _443._tcp.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld
% _443._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld
% _443._tcp.www.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.www.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_www_dom1_tld
% _443._tcp.m.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.m.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_m_dom1_tld
% _25._tcp.s1.dom1.tld.  180 IN TLSA 2 0 0 C_A_D_of_TA
% _25._tcp.s1.dom1.tld.  180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld
% _993._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _993._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld
% _995._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _995._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld
% _587._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _587._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld
% _25._tcp.s2.dom1.tld.  180 IN TLSA 2 0 0 C_A_D_of_TA
% _25._tcp.s2.dom1.tld.  180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld
% _993._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _993._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld
% _995._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _995._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld
% _587._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _587._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld

Does DANE currently allow TWO combined TLSA record usage ? i want to
use both TLSA TA ("TLSA 2 0 0") and TLSA EE ("TLSA 1 0 0")
dns-record, for verifying EE cert created under a self-signed new TA
cert, and force both client & server side to validate both type of
certs, and after validation succeeds, the EE cert will be used for
HTTPS encryption, by both client & server.
If such/above is not supported, then please add support for it.

Since i will not use partial cert portion or hash, in TLSA EE "1 S
M" or "3 S M" cases, so you may avoid referencing on that, and
please focus on full EE cert based practice/guidance/example.  But
if (non-Full) partial cert is appropriate or adequate for TLSA TA "2
S M" or "0 S M" cases without invoking/using extra channel usage,
then pls do mention on that.

Please point out my errors, and help us/me/domain-owners with
better/improved configuration, thanks in advance.

-- Bright Star.
Jun 13, 2013.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 13 Jun 2013 10:02:47 -0400

<http://tools.ietf.org/html/rfc6698#section-4.1>
"""

   If an application
   receives one or more usable certificate associations, it attempts to
   match each certificate association with the TLS server's end entity
   certificate until a successful match is found.  During the TLS
   handshake, if none of the certificate associations matches the
   certificate given by the TLS server, the TLS client MUST abort the
   handshake.

"""

Contrapositively, if the TLS client finds one or more associations that
match the certificate, then it MAY proceed with the handshake.

On Thu, Jun 13, 2013 at 9:20 AM, Bry8 Star <[email-masked]> wrote:

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 13 Jun 2013 19:15:36 +0000

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

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

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

> TLS certs. Both TA/Root-CA and EE/Server-Cert.

You should strongly consider the possibility that this choice is
misguided.

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

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

-- 
	Viktor.

---

From: Bry8 Star <[email-masked]>
Date: Fri, 14 Jun 2013 00:29:11 -0700

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 14 Jun 2013 14:36:03 +0000

> Thanks for correction and lesson.

Considering your recent posts to this list, I'd like to suggest
that you consider spending a decade or so coming up to speed on
the state of the art before posting to an IETF working group mailing
list, i.e. an audience consisting largely of domain experts.

I hate to be the bearer of bad news, nothing personal, but your
posts are quite naive, and I would suggest that it is not a good
use of the group's time to disabuse you of all misconceptions about
TLS and DANE.

Once this technology becomes mainstream, there will be user support
forums for various products incorporating DANE, and you'll be able
to ask your questions there.  Good luck.

-- 
	Viktor.

---

From: Bry8 Star <[email-masked]>
Date: Fri, 14 Jun 2013 10:17:29 -0700

I know, i'm not DNS expert at all.

Mailing list is for DANE WG to communicate with other side. It is a
public list. All type of users will come here to post their
questions or problems or queries or suggestions or discussion or
with other motives, when those not answered at other areas.  Once
mainstream, then there will be more helpful guides in other areas,
then posting here will not be necessary.

-- Bright Star.

---

From: Warren Kumari <[email-masked]>
Date: Sat, 15 Jun 2013 10:05:25 -0400

Ondrej wrote the below, and asked me to post if I agreed. As I'm posting it…

-----------------------------------------------------

Hi,

> I know, i'm not DNS expert at all.

And you are welcome to become one.

> Mailing list is for DANE WG to communicate with other side

Not exactly, the primary purpose of any IETF mailing is to be able to work collectively on our charter contents:

https://datatracker.ietf.org/wg/dane/charter/

That might include communication between people who create standards, the people who implement the standard.  We also welcome a feedback on existing standards and new drafts where things are not clear for implementors and educated users.  Still this is list is not an user support forum.

> It is a public list. All type of users will come here to post their

We welcome all kinds of contributors in the WG and their opinions, but the IETF is standards body and you are required to have a little bit of insight into used technologies.  I might suggest any contributor should spend some time reading the working group RFCs, drafts and the little bit of the history of the mailing list.

Also since your WG is related to DNS, TLS and PKI, you should at least go read and understand the Normative References from our WG Documents, e.g. Normative References from RFC 6394 and 6698, going recursive down (e.g. doing the same with Normative References of Normative References...).

On the other hand any mailing lists subscriber has a right to ignore any other subscriber's mails.  The chairs will step-in only when the contents of the emails will go off charter.

Ondrej
--
Ondřej Surý -- Chief Science Officer
-------------------------------------------
CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
Americka 23, 120 00 Praha 2, Czech Republic
mailto:[email-masked]    http://nic.cz/
tel:+420.222745110       fax:+420.222745112
-------------------------------------------

---------------------------------

--
Credo quia absurdum est.

---

From: Melinda Shore <[email-masked]>
Date: Sat, 15 Jun 2013 11:16:09 -0800

On 6/15/13 6:05 AM, Warren Kumari wrote:
> Not exactly, the primary purpose of any IETF mailing is to be able to
> work collectively on our charter contents:

I agree completely with the substance of your post (IETF
mailing lists are for progressing the work of the IETF),
although I think it's certainly possible that what looks
like a dumb question might actually be raising usability
concerns.

HOWEVER, the ad hominem nature of some of the comments
here have been absolutely unacceptable.  Those need to
stop, and stop now.

Melinda

---

From: Bry8 Star <[email-masked]>
Date: Sun, 16 Jun 2013 23:03:48 -0700

Thanks again for very valuable helpful directions.
That is what i partially expected, thanks.
I expected you will outline your guidance far more clearly with
clear reference readings to reach solve/solution.  That you
understand user's condition/state/nature and GUIDE them to correct path.

I would like to request to think, think about:

[1] What is the percentage of users who are building the standard
for DANE ? and the percent who are standardizing DNSSEC ? for whom ?

[2] Whats the percentage of users who are software developers who
are implementing DANE in software ? and percent who are implementing
DNSSEC in software ?

[3] Whats the percentage, of users who are domain-name owners, who
are dns-operators/domain-operators/system-administrators/etc ?

The last one in above, clearly & obviously have far more numbers,
than any others.

So, please ALSO focus on them ... how you can make direction easy
for such vast groups of users.  Standards have already described
directions for software developers.

I'm in every major project (in various forum, mailing-list,
irc-channels), i asked them and i have seen others asking as well,
how can this/that DANE related settings or DNSSEC related, etc in
software can be implemented ? ... most have no clue, or partial &
old knowledge !

I asked in other related forums/list/etc areas : as domain-name
owner, as dns/domain operator which steps can be done & taken to
assist in adoption of DNSSEC & DANE ? the answer is again, and far
more negative & ignorant than even some developers or
developers-related groups !

Since I've started post here in this WG mailing-list, if anyone
noticed, they should find, i tried to ask some of the SAME question
what others (including me) already asked in other channels, forums,
list.   So that those users can read to find at-least some helpful
solution.

Which I'm observing, no one responding properly or incomplete, or
with other un-helpful additions & discouragement ! What is the
purpose ?  Not that my own posting are without errors, i have lot of
mistakes, and I'm requesting others to correct the mistakes/errors.

So, what am i to conclude ? that this mailing-list members have far
more important things to do, than helping out or guiding, majority
of users who are domain-name owners, dns-operators /
dns-administrators / system-administrators etc ? ! ! !   Those
important things have resulted into what help or what type of help
for DNS-Administrators ? ?  Why DNS-administrators are saying the do
not have enough correct example or information yet to do DANE ! ?
And, I'm beginning to think, many here will continue to ignore these
questions, and/or, continue to say/response something else other
than a real solution !

-- Bright Star.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Jun 2013 08:16:09 +0000

On Sun, Jun 16, 2013 at 11:03:48PM -0700, Bry8 Star wrote:

> how you can make direction easy for such vast groups of users.

A fair question.

I won't attempt to explain how to operate a DNSSEC signed zone
here, sadly this is still rather complex, since DNSSEC signed zones
need to be frequently and automatically resigned, and rotating the
KSK DS records in registries is harder still.  If that's part of
your question, perhaps someone else is willing to tackle this rather
weighty topic, maybe on a DNSSEC list, if not here.

So let's assume that you've somehow crossed the hurdle of implementing
DNSSEC.

Let's also assume that you have some TLS-enabled service on TCP
port 12345 of host mumble.example.com and you want to publish DANE
TLSA records for this host.

The certificate association portion of a TLSA record contains binary
data that is usually presented in hexadecimal form for ease of
entry into zone files.  The underlying binary data is either:

    - A complete X.509 certificate in DER form 		(IN TLSA X 0 0 ...)
    - A complete SPKI public-key in DER form 		(IN TLSA X 1 0 ...)
    - A binary SHA-256 digest of one of the above	(IN TLSA X Y 1 ...)
    - A binary SHA-512 digest of one of the above	(IN TLSA X Y 2 ...)

where "X" is the certificate usage.

When X is 0 or 2, the certificate association publishes a property
of a root or intermediate CA that (possibly through a chain of
intermediate CAs) ultimately issued the certificate of mumble.example.com.

When X is 1 or 3, the certificate association publishes a property
of the actual certificate whose public key is the public key of
mumble.example.com.

Whether you choose X = 0, 1, 2 or 3 is

  - part operational considerations (who updates the DNS in your
    organization, how often are server keys rotated, ...).  Do
    you optimize for robustness in the face of buggy client
    implementations (simpler is better, and nothing is simpler
    than X=3) or robustness in the face of lazy operators who
    neglect to coordinate key rollover with DNS updates (X=0 or
    2 requires less work for the DNS operator).

  - part application considerations, is the client pre-configured with
    a suitable list of trusted CAs?  Does the client have a secure way
    to determine the service hostname (mumble.example.com), ...

  - part security considerations?  Which risks do you want to mitigate?
    DNSSEC zone signingkey compromises? Rogue public CAs? Server
    key compromises?  Do your clients consult CA revocation lists?
    How often are these lists updated?  How quickly can you publish
    a revocation? ...

  - part PKI politics. Does your organization fervently believe in either
    of the two PKI models (public CAs or DANE) and distance itself from the
    other?

Keep in mind that when keys change some clients will have older DNSSEC
records in their caches, so you may need to publish both the old and the
new association values when transitioning between and old and a new
certificate (be it a CA or a server certificate).  DANE validation will
work provided at least association matches.

All that remains is to generate the association data.  If using
OpenSSL (1.0.0 or later) with the relevant certificate in a pem
format file any given TLSA record is obtained by running something
like the attached shell script.

$ ./tlsagen cert.pem mumble.example.com:12345 3 1 1
_12345._tcp.mumble.example.com. IN TLSA 3 1 1 7602662AD394EE1C74D5926454199D3F02C352BA4073E8C87942802277C6D4AA

The shell script can be improved to detect more error conditions,
so should only be used interactively with the user paying attention
to any error messages that may indicate that the output is not
usable.

The corresponding certificate from which the above output was obtained is:

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

You should be able to reproduce all the combinations (the choice
of usage has no effect on the rest of the record, but must match
the role of the selected certificate file).

$ for m in 1 2 0; do for s in 1 0; do
    ./tlsagen cert.pem mumble.example.com:12345 3 $s $m
    done; done
_12345._tcp.mumble.example.com. IN TLSA 3 1 1 7602662AD394EE1C74D5926454199D3F02C352BA4073E8C87942802277C6D4AA
_12345._tcp.mumble.example.com. IN TLSA 3 0 1 1C9621235642558FE24EF79A154617FB134D1E0F4549DECD2FF7168463E27AB4
_12345._tcp.mumble.example.com. IN TLSA 3 1 2 D578D8B9970A0CDEE928CE306BDCBC115CBB4B36FACD370C85F1F6036FE56F44B4CCEA3FC232B3BD840A719410F4D50F33D96A2A11CBE2BE05F8846A6ECA3715
_12345._tcp.mumble.example.com. IN TLSA 3 0 2 1CD33094C61030BAD34FCAB6EBA37B225F82694A3097E2DF01E179B14079B4BD54B64B5CC8A5482037EB4A6CD9EC7173157E7F2E37896BE0414D650D3BFFA2BE
_12345._tcp.mumble.example.com. IN TLSA 3 1 0 3059301306072A8648CE3D020106082A8648CE3D0301070342000466BF8D0C958582AEF2211806EC1EFB7BB283B89660D5DA004697ED32EA012556A8262D5D4AC534F54514741DD856F5ACB1B75B3215278455BC5342C9B948DE74
_12345._tcp.mumble.example.com. IN TLSA 3 0 0 3082017C30820122A003020102020101300A06082A8648CE3D0403023000301E170D3133303631373038303332365A170D3133303731373038303332365A30003059301306072A8648CE3D020106082A8648CE3D0301070342000466BF8D0C958582AEF2211806EC1EFB7BB283B89660D5DA004697ED32EA012556A8262D5D4AC534F54514741DD856F5ACB1B75B3215278455BC5342C9B948DE74A3818C30818930090603551D1304023000301D0603551D250416301406082B0601050507030106082B06010505070302301D0603551D0E04160414A180D67674329AE20999531846A9D021A516E05C301F0603551D23041830168014A180D67674329AE20999531846A9D021A516E05C301D0603551D110416301482126D756D626C652E6578616D706C652E636F6D300A06082A8648CE3D0403020348003045022100D8F47E24B3B9D45E44860E98411B492426A5C84029DCCEB2E6081125313E65B4022059452586A73A4894453AEA6D8C2C4BF907909E236DF16F63E2BDE940D565C5E1

-- 
	Viktor.