Subject: [dane] On the PKIX-TA / PKIX-CA question… [ One week WGLC ]

From: Warren Kumari <[email-masked]>
Date: Mon, 2 Dec 2013 13:44:49 -0500

Hi all,

So, it seems that I judged consensus without enough data. I should know by now that naming things is always a fun topic :-)

So, lets try and get this "what to call it" question nailed down once and for all.

Please express a preference for:

PKIX-TA
PKIX-CA
DANE-<something>

I don't think that anyone really *loves* any of the above, so an even better outcome is that someone proposes a better acronym that everyone likes...

We are keeping this to 1 week -- please get a response in before Monday, Dec 9th.

W

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 Dec 2013 20:32:41 +0000

On Mon, Dec 02, 2013 at 01:44:49PM -0500, Warren Kumari wrote:

> I don't think that anyone really *loves* any of the above, so an
> even better outcome is that someone proposes a better acronym that
> everyone likes...

We should attempt to capture something of the flavour of (be at
least as clear as) the short names in RFC 6698:

	0 - "CA constraint"
	1 - "service certificate constraint"
	2 - "trust anchor assertion"
	3 - "domain-issued certificate"

Of these 0 and 2 are reasonably clear, while 1 and especially 3
are a bit oblique.  Thus the shorter acronyms I would propose are:

	0	CA-CHECK
	1	EE-CHECK
	2	DANE-TA
	3	DANE-EE

The word "check" is one of the shorter synonyms for "constraint"
when used to mean "restriction".  If brevity is not a major priority,
we could use "CONSTRAINT" rather than "CHECK".

The above has the advantage of not using "PKIX" as a contrast to
DANE in 0/1, which was problematic, because 2 is also PKIX, just
with a dynamically established X.509 trust anchor.  The only non
PKIX usage was 3.

A similar alternative is:

	0	LIMIT-CA
	1	LIMIT-EE
	2	DANE-TA
	3	DANE-EE

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Mon, 02 Dec 2013 16:34:37 -0500

My pref is that the suffices be the same for each of the prefices,
therefore PKIX-TA vs DANE-TA vs PKIX-EE vs DANE-EE.

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 Dec 2013 22:15:25 +0000

> therefore PKIX-TA vs DANE-TA vs PKIX-EE vs DANE-EE.

I'm all for neatly aligned text, and I appreciate the increased
cosmetic appeal, but surely the fact that this masks semantic
differences is more important.

    The CA in usage 0 is not a trust anchor, but it is in usage 2.

    The chain in usage 2 still requires PKIX validation, be it with
    a dynamically obtained trust anchor.

So PKIX-TA and DANE-TA are each misleading, the first is not a TA,
the second is still PKIX.  Are the acronyms just supposed to be
more memorable than the numbers, or are they supposed to concisely
convey the associated meaning?

-- 
	Viktor.

---

From: "Dickson, Brian" <[email-masked]>
Date: Mon, 2 Dec 2013 22:47:04 +0000

The asymmetry between 0/1 and 2/3 can be confusing - I had to read 6698
several times to sort it out.
(I am glad I did, though.)

IMHO the acronym should clarify things, or at least suggest which angle to
hold 6698 while squinting.

How about these:
0 - CERT-CA
1 - CERT-EE
2 - ROOT-TA
3 - JUST-EE

0 can be either a root CA, or intermediate CA. If the latter, this cert
itself must PKIX-validate.
2 can be either a root CA, or another trust anchor - but must be the root
of the validation chain either way.
1 requires PKIX validation, 3 does not, hence "just" an End Entity.

Thus, a ROOT-CA cert, can be used as either type 0 or type 2 - but that is
the only likely place where there is likely confusion.
(Of course, if your EE is a root CA, it could be type 1 - but then you are
clearly insane. :-))

Brian

On 12/2/13 5:15 PM, "Viktor Dukhovni" <[email-masked]> wrote:

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

---

From: John Gilmore <[email-masked]>
Date: Mon, 02 Dec 2013 15:05:39 -0800

I propose that we reject the draft entirely and stick with numbers.
If we can't agree on the acronyms, can we stop rearranging the deck
chairs?  A focus on making "running code" for the current DANE RFC
would produce far more deployment than replacing numbers with words.

	John

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 Dec 2013 23:19:30 +0000

On Mon, Dec 02, 2013 at 10:47:04PM +0000, Dickson, Brian wrote:

> IMHO the acronym should clarify things, or at least suggest which
> angle to hold 6698 while squinting.
> 
> How about these:
> 0 - CERT-CA
> 1 - CERT-EE
> 2 - ROOT-TA
> 3 - JUST-EE

What is the "CERT" prefix intended to suggest?

> itself must PKIX-validate.

A simpler view of 0 is that one constructs a chain to a trusted
root as usual, but it is only valid if it also contains the DANE
specified CA (CA constraint).  Thus there is only one case not two.

PKIX validation of two separate half-chains, from the root down to
the intermediate CA, and from the intermediate CA down the leaf,
is *not* equivalent to PKIX validation of a complete chain.  It
can fail to enforce pathlength limits and name constraints.

> 2 can be either a root CA, or another trust anchor - but must be
> the root of the validation chain either way.

This conflicts with the usual meaning of "root" (meaning self-signed).
You're using "root" to mean top of validation chain which is what
the "TA" part means so "ROOT-TA" is redundant.

> Thus, a ROOT-CA cert, can be used as either type 0 or type 2 -
> but that is the only likely place where there is likely confusion.

Any CA (root or not) can be used with either 0 or 2.  Since root
already means something else (self-issued a.k.a. self-signed) we
should avoid using it here, since DANE does not treat root CAs
differently from other CAs.

> (Of course, if your EE is a root CA, it could be type 1 - but
> then you are clearly insane. :-))

PKIX chains don't include the trust anchor, and may not be empty,
so any TLS peer that presents a leaf self-signed certificate should
fail PKIX (and can only be validated by some other mechanism).

In usage 3, self-signed certificates will often be root CAs that
nobody trusts to sign any other certificates.  The "basicConstraints:
CA:true" bit is harmless noise in this context.  Some users will
carefully generate self-signed certs with "CA:false", but this
makes little to no difference.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 Dec 2013 23:47:47 +0000

> would produce far more deployment than replacing numbers with words.

I never found the numbers to be an obstacle, and my focus is as
you suggest implementation.  I am looking at (really) adding DANE
support to OpenSSL (the experimental code in 1.0.2 is IMHO not
satisfactory).

There is also an optional DANE interface in GnuTLS, it too is not
a production-quality DANE implementation.  If any GnuTLS maintainers
are on the list, they should get in touch.

As for the acronyms, I took the draft introduction at its word,
which is to say that for this discussion I assumed that indeed some
implementors or server operators who need to generate TLSA records
do find the numbers confusing.  Perhaps as John suggests numbers
are better than misleading acronyms, at least then people will read
the RFC, rather than guess incorrectly from the acronym.

So in the end acronyms would only be useful if they make operator
mistakes less likely:

	0 - REQUIRED-CA
	1 - REQUIRED-LEAF
	2 - TRUSTED-CA
	3 - MATCHING-LEAF

or perhaps :-)

	0 - CA-LOVER
	1 - CA-SLAVE
	2 - CA-OWNER
	3 - CA-HATER

-- 
	Viktor.

---

From: Bry8 Star <[email-masked]>
Date: Tue, 03 Dec 2013 21:35:14 -0800

U = Usage
DANE = TLSA
PKIX = PKIX certification path validation (CPV)
EE = End entity.

That <something> can be DOI or ZOI (Domain/Zone Owner Issued) ? ?
or DI / ZI  (Domain/Zone Issued).

This 4 U categories are not enough, as "The Certificate Usage Field"
(Section 2.1.1 of RFC 6698).

*Please add* at least few more appropriate category for declaring
very accurately & correctly, so that no confusion exists, for
publicly declaring to others: (A) INTERMEDIATE CA or TA certs (under
U=0 & U=2), (B) a category for EE certs with PKIX *AND* DANE check
under TA (U=2) certs (if U=1 is not for that purpose).

Joining suggestion from this thread:
0 - "CA constraint" = CA-CHECK = PKIX-CA = LIMIT-CA = REQUIRED-CA
    = CA-LOVER
1 - "service certificate constraint" = EE-CHECK = LIMIT-EE
    = REQUIRED-LEAF = CA-SLAVE
2 - "trust anchor assertion" = DANE-TA = PKIX-TA = TRUSTED-CA = CA-OWNER
3 - "domain-issued certificate" = DANE-EE = MATCHING-LEAF = CA-HATER

U = 0 can be used for either a TA or CA cert declaration.
U = 2 is for Domain-issued TA cert declaration.
U = 3 is for Domain-issued EE cert declaration.

TLSA = DANE

So these seems to be appropriate from my point of view for now:
0 = 3PI-CA:TLSA+PKIX  (for 3rd Party Issued CA or TA cert)
  or 3PI-TA
1 = EE:TLSA+PKIX  (for End entity cert)
2 = DOI-TA:TLSA+PKIX  (for Domain Owner Issued TA cert)
  or ZOI-TA  (for Zone Owner Issued TA cert)
3 = DOI-EE:TLSA+NO-PKIX (for Domain Owner Issued EE cert)
  or ZOI-EE

TLSA = DANE

U = 1 type of SSL cert declaration, (are PKIX+TLSA *checked*),
and 1 can be:
either under the U = 0 (are also PKIX+DANE *checked*) cert,
or can be under the U = 2 (are PKIX+DANE *checked*) cert.

Since U = 3 DO *NOT* REQUIRE a PKIX CPV check,
then, *WHERE* is the EE-DANE+PKIX-CHECKED category !? for declaring
certs that are under U=2 ?

So, can U = 1 type cert TLSA(DANE) declaration, be used for such
certs, which can be either under a CA (U=0) or under a TA (U=2), to
me this seems to make sense.
Then U=1 can serve EE_DANE+PKIX_CHECKED, for both U=0 & U=2.

BrS

> We are keeping this to 1 week -- please get a response in before Monday, Dec 9th.

Reference, from RFC 6698:

Hoffman & Schlyter           Standards Track                    [Page 7]
RFC 6698            DNS-Based Authentication for TLS         August 2012

0 -- Certificate usage 0 is used to specify a CA certificate, or
  the public key of such a certificate, that MUST be found in any of
  the PKIX certification paths for the end entity certificate given
  by the server in TLS.  This certificate usage is sometimes
  referred to as "CA constraint" because it limits which CA can be
  used to issue certificates for a given service on a host.  The
  presented certificate MUST pass PKIX certification path
  validation, and a CA certificate that matches the TLSA record MUST
  be included as part of a valid certification path.  Because this
  certificate usage allows both trust anchors and CA certificates,
  the certificate might or might not have the basicConstraints
  extension present.

1 -- Certificate usage 1 is used to specify an end entity
  certificate, or the public key of such a certificate, that MUST be
  matched with the end entity certificate given by the server in
  TLS.  This certificate usage is sometimes referred to as "service
  certificate constraint" because it limits which end entity
  certificate can be used by a given service on a host.  The target
  certificate MUST pass PKIX certification path validation and MUST
  match the TLSA record.

2 -- Certificate usage 2 is used to specify a certificate, or the
  public key of such a certificate, that MUST be used as the trust
  anchor when validating the end entity certificate given by the
  server in TLS.  This certificate usage is sometimes referred to as
  "trust anchor assertion" and allows a domain name administrator to
  specify a new trust anchor -- for example, if the domain issues
  its own certificates under its own CA that is not expected to be
  in the end users' collection of trust anchors.  The target
  certificate MUST pass PKIX certification path validation, with any
  certificate matching the TLSA record considered to be a trust
  anchor for this certification path validation.

3 -- Certificate usage 3 is used to specify a certificate, or the
  public key of such a certificate, that MUST match the end entity
  certificate given by the server in TLS.  This certificate usage is
  sometimes referred to as "domain-issued certificate" because it
  allows for a domain name administrator to issue certificates for a
  domain without involving a third-party CA.  The target certificate
  MUST match the TLSA record.  The difference between certificate
  usage 1 and certificate usage 3 is that certificate usage 1
  requires that the certificate pass PKIX validation, but PKIX
  validation is not tested for certificate usage 3.

Note: Pls make sure to reply only into one email
      address: [email-masked] , when you reply, Thanks in advance.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Dec 2013 17:53:14 +0000

The sample size of responses seems too small to reach a meaningful
consensus.

Perhaps posting something a bit more controversial will get the
silent majority to speak up. :-)  To wit:

    - Assign explanatory names only to usages 2 and 3:

	2 - TRUST-ANCHOR
	3 - END-ENTITY

    - Since usages 0/1 merely complicate DANE implementation without[*]
      enhancing security, they can remain anonymous, or be given names
      that clearly indicate that these are discouraged/deprecated.

	0 - SECURITY-THEATRE-0
	1 - SECURITY-THEATRE-1

This would remove all confusion about the DANE usages.  If someone
can justify the existence of 0 and 1 in a pair of pithy acronyms
then those are the names.  Otherwise, out they go!

[ I have begun design/implementation of general-purpose DANE support
  for OpenSSL.  Supporting all four usages is rather more complex
  than one might imagine, and is largely wasted effort, but the
  protocol requires 0/1 for now, so I have no choice.  I would be
  thrilled to bits were the above to be taken seriously, and usages
  0/1 dropped from DANE TLSA in a future revision of the protocol. ]

-- 
	Viktor.

*  If DNSSEC *is not* compromised, 2/3 are sufficient.

   If DNSSEC *is* compromised, the attacker will publish 2/3, thus
   a domain owner's use of 0/1 offers no protection against DNS attacks.

   There will be no measurable deployment of out-of-band mechanisms
   that harden 0/1 or application protocols that implement DANE, with
   just usages 0 and 1.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 6 Dec 2013 15:00:17 -0500

> The sample size of responses seems too small to reach a meaningful

Unfortunately both to small, and not all in agreement.

I’m going to extend this LC to Wednesday and suggest that, if we don’t get consensus on this we simply stick with what is in the current (draft-ietf-dane-registry-acronyms-02) document.

We don’t need these names / acronyms to be perfect, simply clearer / easier to remember than the ordinals.

Any (strong) objections?
W

-- 
Eagles soar but a weasel will never get sucked into a jet engine

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Dec 2013 20:51:40 +0000

On Fri, Dec 06, 2013 at 03:00:17PM -0500, Warren Kumari wrote:

> Unfortunately both too small, and not all in agreement.
> 
> I'm going to extend this LC to Wednesday and suggest that, if we
> don't get consensus on this we simply stick with what is in the
> current (draft-ietf-dane-registry-acronyms-02) document.

I think the main audience for the short names is server administrators
too busy to read RFCs.  Until I joined this group, I'd never seen
the terms "EE" and "TA" and had only a vague notion of what "PKIX"
was about.  Rather, I had a decent working knowledge of root,
intermediate and leaf certificates and public keys.

So if I rewind the clock back 8 months, to where I knew nothing
about DANE and was not steeped in related IETF TLS slang, I would
note that none of the components of the proposed acronyms will
connect to concepts familar to system administrators deploying
DANE.

To make the acronyms less confusing than the numbers, we need to
use words people already understand:

	0 - LIMIT-ISSUER
	1 - LIMIT-LEAF
	2 - TRUST-CA
	3 - FIXED-LEAF

These are I think not only more clear, but use more familiar terms.
The first two limit (or constrain) the chain to have an acceptable
issuer or leaf certificate.  The last two specify a trusted CA or
a fixed leaf certificate that are sufficient to verify the chain.

> We don't need these names / acronyms to be perfect, simply clearer
> / easier to remember than the ordinals.
> 
> Any (strong) objections?

Returning to the origin acronyms, I for one still prefer PKIX-CA
to PKIX-TA, but I won't change my code to do the wrong thing should
the final name be misleading.  I can't make a similar assurance
about server administrators provisioning TLSA recrods.

-- 
	Viktor.

---

From: John Gilmore <[email-masked]>
Date: Sat, 07 Dec 2013 18:34:40 -0800

> I’m going to extend this LC to Wednesday and suggest that, if we don’t get consensus on this we simply stick with what is in the current (draft-ietf-dane-registry-acronyms-02) document.  ...
> Any (strong) objections?

Yes, I object.  If there is no consensus on acronyms, we should stick
with what is in the current RFC 6698, rather than forwarding an
acronym proposal for adoption as a standard, even though we can't
agree on what it should say.  It's unnecessary, which probably
explains the paucity of responses, and divisive among those who did
respond.  It should be abandoned.

	John

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 8 Dec 2013 23:53:15 +0000

> respond.  It should be abandoned.

Perhaps the author is willing to take a look at the history of the
thread, and propose one final set of names for the 4 usages that
makes most sense to him.  We can then object or concur with those
without (yet again) proposing changes.

I am not fundamentally opposed to human-readable TLSA RRs:

    ; _25._tcp.mx.example.com. IN TLSA 3 1 2
    _25._tcp.mx.example.com. IN TLSA TRUSTED-LEAF PUBLIC-KEY SHA2-512 {blob}[

    ; _25._tcp.mx.example.com. IN TLSA 2 0 2
    _25._tcp.mx.example.com. IN TLSA TRUSTED-CA CERTIFICATE SHA2-512 {blob}

    ; _25._tcp.mx.example.com. IN TLSA 1 0 1
    _25._tcp.mx.example.com. IN TLSA VALID-LEAF PUBLIC-KEY SHA2-256 {blob}

    ; _25._tcp.mx.example.com. IN TLSA 0 1 0
    _25._tcp.mx.example.com. IN TLSA VALID-CA PUBLIC-KEY VALUE {blob}

As much possible, the acronyms should avoid jargon unfamiliar to
their intended audience and in a full TLSA record should ideally
read like a complete sentence, as above.

The dichotomy between "TRUSTED" (sufficient on its own) and "VALID"
(not sufficient without external trust) is I think one reasonable
way to communicate the usage values.

Anyway, I think it is up to the author to propose a final revision,
or as John suggests, give up.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 09 Dec 2013 12:09:44 +1100

In message <[email-masked]>, Viktor Dukhovni writes
>     _25._tcp.mx.example.com. IN TLSA TRUSTED-LEAF PUBLIC-KEY SHA2-512 {blob}[

If anything other than numeric values appear in the records you
will break existing TLSA record parsers.  Names are useful when
describing thing.  They are no useful for portability and definitely
break the future proofing in the original presentation format.

For DNSKEY we display them as comments after the record.  The record
itself purely numeric and future proof.

e.g.

; <<>> DiG 9.10.0a1 <<>> dnskey . +rrcomments
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7742
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	DNSKEY

;; ANSWER SECTION:
.			4753	IN	DNSKEY	257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=  ; KSK; alg = RSASHA256; key id = 19036
.			4753	IN	DNSKEY	256 3 8 AwEAAYRU41/8smgAvuSojEP4jaj5Yll7WPaUKpYvnz2pnX2VIvRn4jsy Jns80bloenG6X9ebJVy2CFtZQLKHP8DcKmIFotdgs2HolyocY1am/+33 4RtzusM2ojkhjn1FRGtuSE9s2TSz1ISv0yVnFyu+EP/ZkiWnDfWeVrJI SEWBEr4V  ; ZSK; alg = RSASHA256; key id = 59085

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 09 11:52:43 EST 2013
;; MSG SIZE  rcvd: 450

TLSA, like DNSKEY, will need tools to take certs etc. and generate
TLSA records.  Those tools can use names but they emit records in
numeric form.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 9 Dec 2013 01:32:21 +0000

On Mon, Dec 09, 2013 at 12:09:44PM +1100, Mark Andrews wrote:

> describing things.  ...

Thanks, finally I said something wrong enough, to elicit a follow-up!
:-) Yes, tools that emit records in canonical form should use
numbers.  Users may elect to enter mnemonic forms when supported
by the target application.

Now that you're here, any suggestions for good names, or thoughts
on what to do with the draft?

> TLSA records.  Those tools can use names but they emit records in

A humble example below.

-- 
	Viktor.

#! /bin/sh

extract() {
  case "$(echo $4 | tr '[A-Z]' '[a-z]')" in
  0|cert*)
	openssl x509 -in "$1" -outform DER;;
  1|spki|public*)
	openssl x509 -in "$1" -noout -pubkey |
	    openssl pkey -pubin -outform DER;;
  *) error "Invalid selector: $4";;
  esac
}
digest() {
  case "$(echo $5 | tr '[A-Z]' '[a-z]')" in
  0|full*) cat;;
  1|sha2-256|sha256|sha-256) openssl dgst -sha256 -binary;;
  2|sha2-512|sha512|sha-512) openssl dgst -sha512 -binary;;
  *) error "Invalid matching type: $5";;
  esac
}
encode() {
  perl -e '
    ($cert, $hostport, $u, $s, $m) = @ARGV;
    ($host, $port) = split(":", $hostport); $port ||= 443;
    $/=undef;
    ($a=<STDIN>) =~ s/(.)/sprintf("%02X", ord($1))/egs;
    printf "_%d._tcp.%s. IN TLSA %d %d %d %s\n",
	  $port, $host, $u, $s, $m, $a;
  ' "$@"
}

error() { echo "$1" 1>&2; exit 1; }
usage() { error "Usage: $0 cert.pem host[:port] usage selector mtype"; }
if [ $# -ne 5 ]; then usage; fi

case "$(echo $3 | tr '[A-Z]' '[a-z]')" in
0|PKIX-CA|PKIX-TA|VALID-CA)	usage=0;;
1|PKIX-EE|VALID-LEAF)		usage=1;;
2|DANE-TA|TRUSTED-CA)		usage=2;;
3|DANE-EE|TRUSTED-LEAF)		usage=3;;
*) error "Invalid certificate usage: $3";;
esac

extract "$@" | digest "$@" | encode "$@"

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 9 Dec 2013 08:42:37 +0100

> or as John suggests, give up.

+1

	jakob

---

From: James Cloos <[email-masked]>
Date: Mon, 09 Dec 2013 16:50:43 -0500

Since I've posted wrt this draft, I feel compelled to add that I
encouraged symmetry, iff names are used, because I do not expect
that anyone will remember them otherwise.

With emphasis on "iff".

There is no value in names if one has to look them up; in that
case numbers are at least as useful.

-JimC

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 9 Dec 2013 23:19:19 +0000

> that anyone will remember them otherwise.

What do you mean by symmetry?  If you mean that the names for 0/1
should each differ in the same way from 2/3 respectively, then this
requires names that fail to distinguish between a vanilla CA (in
usage 0) and a trust-anchor (in usage 2).  Is such "symmetry" more
important than semantic fidelity?

[ Usages 0/1 are a blunder, we're continuing to pay the cost of
  this blunder. ]

> case numbers are at least as useful.

Are the names in your view primary intended as alternative input
forms, or (perhaps as comments) in display forms of RRs?

-- 
	Viktor.

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 10 Dec 2013 08:12:42 +0100

> [ Usages 0/1 are a blunder, we're continuing to pay the cost of

As the author of 6698, I don't agree and believe 0/1 are still useful as an additional layer of security for traditional PKIX. The world is not always black and white.

	jakob

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 Dec 2013 07:34:03 +0000

On Tue, Dec 10, 2013 at 08:12:42AM +0100, Jakob Schlyter wrote:

> As the author of 6698, I don't agree and believe 0/1 are still
> useful as an additional layer of security for traditional PKIX.

You left out the word "theatre" after "security". :-)  I guess time
will tell whether the definition of 0/1 in 6698 is in fact pointless
complexity.  The critical thing now is to drive DNSSEC adoption,
so that DANE becomes viable (or perhaps adoption of both in parallel,
if DANE is the carrot for DNSSEC adoption).

In the mean-time, I have a working, and plausibly correct, be it
not yet extensively tested, general purpose DANE interface for
OpenSSL.  It fully supports all the DANE usages (including the
theatrical ones).  It even supports out-of-band "2 x 0" certificates
and keys and certificates even when these are not in the peer's
TLS chain.

Let's hope that support for DANE verification with OpenSSL will
encourage broader application support for DANE.  With a bit of
luck, someone from the OpenSSL team will volunteer to work with me
to integrate the code into the development tree.

This took just over 1200 lines of commented code.  It should work
with OpenSSL 0.9.8 or newer.  A very recent insight made it possible
to remove the need for signing operations and generation of internal
private keys in the verifier, so it is now about as simple as it
can get.

The usage 2 implementation is radically different from all the
other cases, and accounts for the bulk of the code.  This is why
I am not comfortable with language that suggests that the difference
between 0 and 2 is just like that between 1 and 3.  This is very
far from the truth.
 
-- 
	Viktor.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 10 Dec 2013 11:21:17 +0000

> to integrate the code into the development tree.

I'm willing to consider it. But I'm still concerned that without something
akin to CT, DANE is more dangerous than the existing PKI.

> private keys in the verifier, so it is now about as simple as it

0.9.8 is closed to new functionality, as are some of the more recent
branches.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Dec 2013 10:17:08 -0500

Ben,
> ...
>
> I'm willing to consider it. But I'm still concerned that without 
> something akin to CT, DANE is more dangerous than the existing PKI.
>
Can you elaborate, without reference to CY :-)? DANE seems preferable 
because the DNS hierarchy constrains the range of names that a node may 
assert (validly), unlike the WebPKI model.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Tue, 10 Dec 2013 15:22:13 +0000

> assert (validly), unlike the WebPKI model.

I agree that there is this additional constraint. It doesn't really address
the core problem, though, which is that registries and registrars, like
CAs, are vulnerable to error, coercion and getting pwned. Registries are
also in a great position to mount targeted attacks, unlike CAs.

Experience suggests that their record, on the whole, is less good than CAs.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Dec 2013 11:23:43 -0500

Ben,

Thanks for the clarification. I disagree with the relative merit of the
two approaches, but I don't dispute your observations.

Steve

---

From: Warren Kumari <[email-masked]>
Date: Tue, 10 Dec 2013 11:23:53 -0500

[ No hats] 
[ Changed the subject to hopefully more correctly identify the discussion ] 

On Dec 10, 2013, at 10:22 AM, Ben Laurie <[email-masked]> wrote:
>>> I'm willing to consider it. But I'm still concerned that without something akin to CT, DANE is more dangerous than the existing PKI.
>>> 
>> Can you elaborate, without reference to CY :-)? DANE seems preferable because the DNS hierarchy constrains the range of names that a node may assert (validly), unlike the WebPKI model.
>> 
> I agree that there is this additional constraint. It doesn't really address the core problem, though, which is that registries and registrars, like CAs, are vulnerable to error, coercion and getting pwned. Registries are also in a great position to mount targeted attacks, unlike CAs.
> 
So, we had numerous discussions on this topic back at the beginning.

At the core of the discussion was the fact that an attacker who is able to manipulate the DNS can get a CA signed cert (the attacker points the MX to a box under their control, applies for a DV cert at www.certs-r-us.com, receives the authentication cookie mail and sends it back to the CA). This attack doesn’t allow the attacker to get a cert that requires special validation, and also doesn’t work for the special golden names)…

When we were having these discussions I think that a number of us had a somewhat different (and some would say naive) view of the threat landscape. I personally was more focused on the lone attacker scenario, and not the "nation state who doesn’t mind being noticed” attack.

In many / most cases the ccTLD operator is in country (I believe that ICANN now requires the cc Admin contact to be in county) and could be compelled to publish fake DS and NS records for a specific domain and serve a parallel DNS tree[0]. This would be technically tricky (what with caching and the difficulty of correctly doing key rolls even which all parties co-operating), but not impossible. It would (probably) be fairly noticeable, but this might be acceptable to the attacker.

The above is conceptually similar to just seizing the domain (like the ICE / DHS counterfeit seizures), but with DANE could allow the attacker to also get a lock icon.

Having something like CT but for DANE / DNSSEC would (IMO) be very useful — I believe that there was some activity on this front, any updates?

> Experience suggests that their record, on the whole, is less good than CAs.

[0]: I’m using cc’s as an example here, but the same applies to gTLDs in the attacking country.

P.S: Apologies — for some reason my MUA refused to understand Ben’s quoting level. I tried to requote correctly but may be misattributing.

--
It's a mistake trying to cheer up camels. You might as well drop meringues into a black hole. -- Terry Prachett

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 Dec 2013 18:27:09 +0000

On Tue, Dec 10, 2013 at 11:21:17AM +0000, Ben Laurie wrote:

> I'm willing to consider it.

Thanks.  Please drop me a note off list, I'd like to find some
mutually convenient time to chat about the design over a voice
Google hangout.  If you want to look at the code first:

	https://github.com/vdukhovni/ssl_dane

The work-flow is basically:

	SSL_library_init()
	SSL_dane_library_init()
	SSL_CTX_new()
	SSL_CTX_dane_init()	/* DANE connections get a dedicated context */
	SSL_new()
	SSL_dane_init()		/* allocate dane state, set SNI, ... */
	SSL_dane_add_tlsa()	/* Once per record */
	SSL_connect()		/* off to the races... */
	SSL_get_verify_result()	/* Learn the outcome */
	SSL_dane_cleanup()	/* Dispose of DANE state */

You can see this at work in ssl_dane_test.c.  It verifies
imap.gmail.com, with all the various usages, selectors, digests
and relevant certificate depths (and out-of-band TLSA records
constructed by pointing the code at a PEM file).

> But I'm still concerned that without something

[ There is (for various reasons described in the draft) in practice
no *existing PKI* for SMTP, so there is at least one use case where
we're comparing DANE to *nothing* rather than DANE to existing PKI. ]

In any case, the question of the relative merits of DANE in any
particular use-case is rather orthogonal to implementation of the
requisite library support.  The decision to use or not use DANE
will happen above the library layer.  I should note that my code
does not enable DANE by default for any connections, it does not
even do any DNS lookups.  Rather, I provide an API for the application
to explicitly turn on DANE support for a given connection by providing
appropriate parameters (including any TLSA RRs the application
obtained by other means).

> 0.9.8 is closed to new functionality, as are some of the more recent

I am not changing any existing OpenSSL code, my work is essentially
an add-on library, though tighter integration would be appropriate
in the future and would allow me to simplify the DANE side.

-- 
	Viktor.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 11 Dec 2013 12:54:33 +0000

> two approaches, but I don't dispute your observations.

I'm not particularly interested in which is more defective: they both
need fixing.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 11 Dec 2013 09:50:31 -0800

> DANE-<something>

That's exactly the order I'd prefer.  Types 0/1 require PKIX, so the
prefix makes sense and I like the alignment that allows:

  |---------+---------|
  | PKIX-TA | PKIX-EE |
  |---------+---------|
  | DANE-TA | DANE-EE |
  |---------+---------|

(even though a future type 5 may not align well, those four still can
and probably should)

That being said, I'm fine with PKIX-CA as well.  I disagree(ish) that
a type 0 reference is not a trust-anchor and thus shouldn't be called
that.  And the reason I disagree is that though in-itself it isn't one
because the true trust anchor must also be pre-programmed, it still is
very much restricting use to a single TA and pointed to as a reference.
Thus it truly is being used as a form of trust, because both the
internally recorded TA and the DANE TLSA record must match or all bets
are off.  Thus they're both equally as important when DANE is in play.

-- 
Wes Hardaker
Parsons

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 11 Dec 2013 09:55:08 -0800

John Gilmore <[email-masked]> writes:

> It's unnecessary, which probably explains the paucity of responses,
> and divisive among those who did respond.  It should be abandoned.

I disagree because of the huge number of conversations I've had with
people where they just couldn't get the three-tuple numbers in their
head.

A consensus call on "which acronyms do you state are absolutely abysmal"
might end up with a better set of "ok, most people don't out-right-hate
those" than a voting competition where only the favorite should win.
EG, I'd be happier with both PKIX-CA or PKIX-TA over "0" and "1" even
though my preferred choice is still PKIX-TA.
-- 
Wes Hardaker
Parsons