Subject: [dane] Few questions

From: oneofthem <[email-masked]>
Date: Sat, 25 May 2013 20:30:52 +1000

1. Is DANE finished? Ready to go, rock and roll?
2. Is it possible for DANE to replace the CA system currently in place?

Thanks.

---

From: Leif Johansson <[email-masked]>
Date: Sat, 25 May 2013 14:14:10 +0200

> 1. Is DANE finished? Ready to go, rock and roll?

yes

> 2. Is it possible for DANE to replace the CA system currently in place?

depends on what you need to do

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 25 May 2013 14:42:14 +0000

> 1. Is DANE finished? Ready to go, rock and roll?

The TLSA RR has been standardized.  What remains to do is to define
how TLSA records are to be used in various application protocols.

For application protocols that use SRV records there is a draft in progress.
There is another draft for SMTP based on the SRV draft since MX records
are similar to SRV records.

I have proposed two recent drafts (see the list archives) that address in
more detail how applications that can't use the existing public CA PKI
should interact with DANE (in particular SMTP) and also some implications
for various corner cases.

I have also proposed that applications "follow CNAMEs" to derive
the base domain for TLSA records.  It remains to be seen whether
this will gain any traction.

OpenSSL does not yet provide ready-to-use DANE verification code,
so applications based on OpenSSL have to roll their own.  This will
change at some point, though I hope in not too soon, since the
required changes are invasive, and need some time for the design
and implementation to be validated.

> 2. Is it possible for DANE to replace the CA system currently in place?

For server domains that have deployed DNSSEC, and applications
where clients have DNSSEC validating caching resolvers (or have
chosen to embed DNSSEC capable stub-resolvers directly in application
code) it is possible to bypass the existing public CA PKI.

Just publish TLSA records with usage "3" or perhaps "2", and with
usage "2" make sure to include the TA cert in the server's TLS
handshake certificate chain.

-- 
	Viktor.

---

From: oneofthem <[email-masked]>
Date: Sun, 26 May 2013 00:53:35 +1000

> handshake certificate chain.

Thank you for your in depth response!

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 28 May 2013 07:20:15 -0700

> how TLSA records are to be used in various application protocols.

It's worth noting, since Viktor unintentionally glossed over it, that
the base TLSA definition does include definitions for how to use it over
TLS and targeted toward HTTPS specifically, so another document isn't
needed for that case.  The other protocols he mentioned still need some
definition and binding, however.

> so applications based on OpenSSL have to roll their own.

Or use another library that provides DANE validation hooks to use for
OpenSSL verification links.

(eg: https://www.dnssec-tools.org/svn/dnssec-tools/trunk/htdocs/docs/tool-description/val_getdaneinfo.html )

It shouldn't be hard to get up and running today, and many applications
and examples exist for you to glance at and study:

https://www.dnssec-tools.org/svn/dnssec-tools/trunk/dnssec-tools/apps/curl/curl-7.29.0.patch

> code) it is possible to bypass the existing public CA PKI.

Different people have different security needs and beliefs.  So can DANE
be used to bootstrap your security needs?  Absolutely, if it meets your
security requirements (and I think it meets the needs of most people
quite well).

-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 28 May 2013 15:51:11 +0000

> definition and binding, however.

Yes, my response was perhaps too brief.  For HTTPS, RFC 6698 is
largely sufficient.  There is a corner case with "2 1 [12]" TLSA RRs
and an unstated requirement for servers to include the TA certificate
in their chain.  Many verifier implementations don't correctly handle
"2 1 0" TLSA RRs.

> (eg: https://www.dnssec-tools.org/svn/dnssec-tools/trunk/htdocs/docs/tool-description/val_getdaneinfo.html )

This library's (latest 2.0 release) implementation of certificate
usage 2 is rather broken none of the "2 x y" cases are implemented
correctly.

More fundamentally, this library is (as evidenced by the curl patch)
intended to be used after a permissive SSL verification callback
which ignores all errors (or equivalently with any callback and
SSL_VERIFY_NONE set).  This will ignore parent-child signature
errors and expiration problems in the certificate chain.

Since applications generally expect PKIX validation to performed
during the handshake, application code that runs post-handshake
rarely if ever performs a complete set of PKIX checks.

Thus also with certificate usage 0 and 1 the patched curl will not
in fact validate the PKIX certificate chain.  So only certificate
usage 3 may work (at first glance), the others are definitely
broken.

> https://www.dnssec-tools.org/svn/dnssec-tools/trunk/dnssec-tools/apps/curl/curl-7.29.0.patch

Which in turn breaks the patched curl.  Support for DANE in this
library needs to be fixed or withdrawn.

-- 
	Viktor.

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Tue, 28 May 2013 15:29:20 -0400

Hi Viktor,

> usage 2 is rather broken none of the "2 x y" cases are implemented

Yep, the implementation of usage 2 in the 2.0 release is quite broken. However, the svn version should be better (https://www.dnssec-tools.org/svn/dnssec-tools/trunk/dnssec-tools/validator/libval/val_dane.c). Feedback is always welcome. 

You're also welcome to try out the DANE-capable Bloodhound browser (http://www.dnssec-tools.org/download/#gotoBloodhound), which links against a more recent (post-2.0) version of libval primarily for this reason.

> rarely if ever performs a complete set of PKIX checks.

I agree with you that we'd normally want the DANE checks to occur during the SSL hand-shake itself for all the reasons you've given above. In the case of libcurl, though, it appears that the application performs its own set of certificate checks in ossl_connect_step3(). Now, I'm by no means an expert in the libcurl code-base and could still be way wrong, but a quick test seemed to confirm that expired TLS certs are in fact caught even with the patch applied. 

Thanks!
Suresh

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 28 May 2013 19:59:19 +0000

On Tue, May 28, 2013 at 03:29:20PM -0400, Suresh Krishnaswamy wrote:

> Yep, the implementation of usage 2 in the 2.0 release is quite
> broken. However, the svn version should be better
> (https://www.dnssec-tools.org/svn/dnssec-tools/trunk/dnssec-tools/validator/libval/val_dane.c).
>
> Feedback is always welcome.

This version is much better, it does not handle "IN TLSA 2 1 0",
where only the public key is in DNS, and the chain omits the
corresponding TA certificate (it starts with a certificate signed
by the TLSA public key).  It is also somewhat inefficient, since
it repeats the checks in X509_verify_cert() performed during the
handshake.  Doing this via a verify callback rather than via a
post-handshake function is more natural.

Also the result of val_dane_check() does not distinguish between
usage 2 (which requires name checks on the leaf cert) and usage 3
(which does not!).  Neither require PKIX checks, so usage 2 is still
insecure since applications will likely skip all further checks.
This interface likely needs to take of name checks.

> I agree with you that we'd normally want the DANE checks to occur
> during the SSL hand-shake itself for all the reasons you've given
> above. In the case of libcurl, though, it appears that the application
> performs its own set of certificate checks in ossl_connect_step3().
> Now, I'm by no means an expert in the libcurl code-base and could
> still be way wrong, but a quick test seemed to confirm that expired
> TLS certs are in fact caught even with the patch applied.

Curl only looks at the expiration times of the leaf certificate,
not the intermediate certificates, much more importantly it does
not check that any of the certificates in the chain are actually
signed by the certificate one layer deeper in the chain.  Therefore,
with the 2.0 release, certificate usage 0 is trivially forged by
a MITM attack.  With usage 1, the PKIX checks are not correctly
applied, and it is no stronger than 3.

The version 2.0 code is unsafe for most certificate usages and
should be withdrawn.

Designing a robust library extension to OpenSSL that handles the
needs of multiple applications is non-trivial.  Since And Polyakov
of OpenSSL has started this work, perhaps the dnsval features for
this should be withdrawn rather than extended/improved further.

I know that some of the issues I'm reporting here apply equally to
the OpenSSL git version, but with luck those will be fixed, and in
time should obviate the need for add-on libraries.  Though it may
take some time, my view is that in the interim "no code" is better
than "some code", when "some" means incomplete and likely insecure.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 28 May 2013 22:37:24 +0000

> post-handshake function is more natural.

In fact X509_verify_cert() is called for each usage 0/2 TLSA record,
until one matches, each time re-verifying chain properties unrelated
to PKI trust (PKIX or DANE) and calling the application verify
callback multiple times with the same certificates, sometimes reporting
failure, sometimes not.

Another substantial problem is that X509_verify_cert() only checks
the trust store against the top of the peer's certificate chain,
so with usage 0 or 2 if the TLSA record trust anchor is in the
middle of the chain DANE verification incorrectly fails.

To fix this, the chain needs to be copied to a new chain that is
truncated at the top to ensure that the matching TA certificate is
its first element.  Full support for "IN TLSA 2 1 0" requires
further non-trivial code (until a future RFC updates 6698 and spells
out a requirement for usage 2 servers to include the TA cert in
their TLS handshake chain in all usage "2 x y" cases except "2 0 0").

My view is that applications should not use this library for DANE
support except on an experimental basis.

-- 
	Viktor.

---

From: Bry8 Star <[email-masked]>
Date: Tue, 28 May 2013 17:56:02 -0700

on windows side, users (including me) are using, two firefox addons:
"Extended DNSSSEC Validator" (www.os3sec.org), "DNSSEC Validator"
(www.dnssec-validator.cz), and these two are able to use a local or
remote DNSSEC validation supported DNS-Resolver/Server, and seems to
be able to handle at-least "2 s m" and "3 s m" TLSA cases.

- -- Bright Star. (Bry8Star).

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 May 2013 01:29:50 +0000

On Tue, May 28, 2013 at 05:56:02PM -0700, Bry8 Star wrote:

> -----BEGIN PGP SIGNED MESSAGE-----

http://xkcd.com/1181

> "Extended DNSSSEC Validator" (www.os3sec.org),

The code I found for this on github does not support certificate
usage 0 or 1 and ignores the TLSA RR selector, always matching the
certificate and not the public key.  It appears to hardcode port
443 for TLSA RR lookups, rather than use the port from the URI.
It is far from clear how it handles name checks.  Likely many more
problems.

At first glance it is a toy not suitable for serious use.

> "DNSSEC Validator"

I have not had a chance to look at this in detail and I don't know
much about writing browser plugins, so it is not clear how one
robustly hooks into the browser's HTTPS connection establishment
process.  I would recommend using browsers that support DANE natively,
via a properly reviewed implementation in the browser itself.  I'd be
suspicious of the safety of addons.

Perhaps someone else can take a stab at it.  My impression is that
a non-trivial fraction of the early implementations are substantively
flawed.  Caveat emptor.

-- 
	Viktor.

---

From: Bry8 Star <[email-masked]>
Date: Tue, 28 May 2013 21:11:13 -0700

unfortunately, Bloodhound web-browser (which is tweaked for native
support of DNSSEC & TLSA/DANE) does not yet have a windows
port/release :(

I would agree completely, these addons have many more bugs and far
from perfect. Even in "3 s m" or "2 s m" detection & verification,
not very consistent yet.

For example, even by using last release of these addons, when such
sites/zones are visited : "mozilla.org" or on "addons.mozilla.org" ,
both are DNSSEC signed zones/sites (though, no TLSA rr yet). Addons
showed those are not signed or secured by DNSSEC !

But for other major or more publicly known dnssec signed + TLSA
based sites/zones, these addons do seem to show DNSSEC+DANE
info/icon correctly, specially when "3 s m" based (aka: end-entity
cert, domain-issued cert) TLSA exists for _443._tcp (HTTPS).

In an attempt to create and test a TLSA "2 s m" implementation for
HTTPS, apparently these addons did not show correct info. But it
could also be that, our test RR implementation were wrong, or, TA
cert and other cert were not in chain properly.

So very likely internal source-codes are tuned for limited TLSA
cases only.

BTW, "Cipherfox" firefox-addon can visually show PKI cert chain, it
appears inside (early mentioned) DNSSEC addon's popup/info window
(when icon is clicked on), but afaiu this addon does not do any
DNSSEC or DANE.

It would have been great, if those two addons could show cert chain
or debug info on which exact certs or chain of certs these addons
have checked/verified.

And even when configured in firefox to show debug info, those two
addons do not actually show detail debug info.

And if those two addons are further improved for using with
Thunderbird for _993 , _995 , _25 , _465 based services then that
would have been very helpful. Currently those two addons do not
understand those DNS RR.

-- Bright Star.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 May 2013 05:00:08 +0000

> from perfect. Even in "3 s m" or "2 s m" detection & verification,

You are much more charitable to major design and implementation
flaws than I am willing to be.

> So very likely internal source-codes are tuned for limited TLSA

Why promote the use implementations that don't even correctly
implement the subset of parameters they set out to support?

> or debug info on which exact certs or chain of certs these addons

IMHO it would have been even better if at least the one I read was
never released to the public.  Don't confuse the feature set with
the implementation.

How do you know they do what they claim to do?  Be skeptical of
new implementations of security mechanisms (including mine).  They
need to be thoroughly vetted before they are fit for use by the
public.

> would have been very helpful. Currently those two addons do not

More flawed security code used more broadly is not progress.

Yes, there should be multiple implementations, but not very many.
Security libraries and plugins need to be written with above average
attention to detail and must stand the test of time.  The design
should be feature complete and generally correct, before any code is
written.

-- 
	Viktor.

---

From: Bry8 Star <[email-masked]>
Date: Tue, 28 May 2013 22:52:27 -0700

i mentioned, because, in windows side, these are the only choices so
far for firefox which at-least can be used easily.

So it seems, for windows users, best (and probably only one,
current) alternative is : using a VirtualBox or using your own
choice of Virtualization software based Linux/Unix VM instance, with
a minimal X / GUI / Desktop (LXDE, XFCE, etc), and then doing tests
using the Bloodhound web-browser from such VM.

- -- Bright Star.

---

From: Bry8 Star <[email-masked]>
Date: Tue, 28 May 2013 23:32:41 -0700

In which exact IETF mailing-list or which exact group are doing
discussion on SRV rr draft, and on SMTP rr draft ?

I think i have seen SMTP rr draft here (in [email-masked]), am i wrong ?

-- Bright Star.

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Wed, 29 May 2013 09:06:57 -0400

On May 28, 2013, at 3:59 PM, Viktor Dukhovni wrote:

- a number of very useful comments.- 

Hi Victor,

I believe that having multiple independent implementations of TLSA validation code is "a good thing" in that it allows us to flag and fix issues early and build more confidence in the code we use down the line. So your comments in that respect are particularly useful.

For the purpose of this list I'll try and summarize the broad problems that you're flagging with the libval DANE implementation and will attempt to move the gory details of the implementation to our project mailing list. Feel free to suggest corrections if I've not captured all the points you were trying to bring up.

1. There are issues with the usage 2 implementation. Specifically (paraphrasing what you've said earlier):
	a) The code is inefficient
	b) It does not handle "IN TLSA 2 1 0" where only the public key is in DNS, and the chain omits the corresponding TA certificate.
	c) if the TLSA record trust anchor is in the middle of the chain, DANE verification incorrectly fails.
	d) There needs to be additional name checks on the leaf cert

2. The curl patch is broken with respect to DANE usage 2.

I wasn't able to tell if you were pointing out any specific issues with the implementation for the other usage types, but if there are any I'd be happy to add them to my list.

Thanks!
Suresh

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 May 2013 14:21:35 +0000

On Wed, May 29, 2013 at 09:06:57AM -0400, Suresh Krishnaswamy wrote:

> For the purpose of this list I'll try and summarize the broad
> problems that you're flagging with the libval DANE implementation
> and will attempt to move the gory details of the implementation to
> our project mailing list. Feel free to suggest corrections if I've
> not captured all the points you were trying to bring up.
> 
>       b) It does not handle "IN TLSA 2 1 0" where only the public key
>          is in DNS, and the chain omits the corresponding TA certificate.

a). The inefficiency increases the number of public-key signature
    verification operations performed on the peer's chain.  Not
    generally a big deal, but can be a problem.  More importantly
    the application callback is now invoked multiple times for the
    same chain, and we don't know what state it accumulates, whether
    it logs errors, ...  so the "contract" between the OpenSSL
    library and the application changes.

    Another inefficiency is that the matching routine is passed a
    DER encoded cert even when the TLSA selector is for a public
    key, it then decodes the DER cert, extracts a key and DER
    encodes that.  This should be handled "upstairs", with the
    match routine given the right DER object to (optionally digest)
    and compare.

b). Also "2 0 0" fails, because the provided certificate may only
    be in DNS and not in the peer's chain.  The "0 1 0" and "0 0 0"
    cases work only because OpenSSL's verification check during
    the handshake (see inefficiency above) augments that chain to
    include any missing root CA.

c). Here also all usage 0 cases fail when the TLSA RR specifies
    a non-root certificate (see above about augmented chain).

d). Yes, it is best to perform name checks on the leaf cert
    with 0/2 comparing against at least the base TLSA domain,
    but applications should be able to provide a list of names
    (see the Tony Finch SRV draft which specifies two names).
    This does not punt name checks to the application and
    simplifies the return logic.

> 2. The curl patch is broken with respect to DANE usage 2.

Because the application skips name checks, and for the complex
case of "2 1 0".  And usage 0 with a non-root CA TLSA RR.

You could choose to not support "2 1 0" without the matching
certificate in the peer's chain.  There is no clear language covering
this in RFC 6698.  In Postfix I chose to implement "2 1 0" support
because I expect some servers to get this wrong, and I did not want
to punish them for their ignorance.  Since it is possible to make
it work, I did.

If my operational guidance draft gets adopted, perhaps this and
similar issues will be more clear to server operators.  It is not
yet clear whether client implementations are obligated to deal with
"2 1 0" without a matching certificate on the wire in the server's
TLS handshake.

> I wasn't able to tell if you were pointing out any specific issues
> with the implementation for the other usage types, but if there
> are any I'd be happy to add them to my list.

I may have missed some, your design review (see below) should
uncover these.

> I believe that having multiple independent implementations of
> TLSA validation code is "a good thing" in that it allows us to flag
> and fix issues early and build more confidence in the code we use
> down the line. So your comments in that respect are particularly
> useful.

It is good to have early implementations, that are not yet mature
with respect to field testing, ...  I do however believe that design
errors should not be present even at this stage.  Field testing
should not be needed to shake out design errors.  I found the issues
I reported by reading the code, not by running it.  Were the code
in production there would need to be a security advisory.  This is
not necessary.

While my comment about more implementations not being progress was
inspired much more by the clearly incomplete design of the Firefox
plugin, which was a college project.  I do encourage you do go
through all the use-cases, write down the verification requirements,
then read the source code of OpenSSL's X509_verify_cert() in
crypto/x509/x509_vfy.c.

Having understood how the legacy verification process works, what
errors it detects and reports to the application callback and in
what order, you are ready to design an extension that implements
DANE verification.

    - Consider the "2 0 0" and "2 1 0" edge cases, where the full
    certificate or public key is provided via DNS and may not appear
    on the wire in TLS.

    - Consider the "2 [01] [12]" edge cases where the full cert or
    key is not in DNS, and also may not be in TLS, document that
    server operators must provide the TA key or else verification
    fails.

    - Consider the "2 1 1" use cases where after trust chain
    verification completes, though PKIX verifiction relative
    to the existing public CA PKI is not required, name checks
    are still required to make the peer has the right certificate
    issued by the trust anchor.  Compare with "3 1 1" where a TLSA
    record match is definitive, and no name checks apply (in fact
    the certificate may have an empty sequence for its subject DN).

    This has implications for API design. Either the DANE verification
    API takes care of name checks (and perhaps also PKIX checks
    for 0/1), or it needs to report multiple success states:

	- with/without name checks required
	- with/without PKIX ckecks with public CA PKI required

    Failure with all TLSA RRs unusable is different from failure
    with some usable, but none matched (see the SRV draft).

    The existing public CA PKI is not compatible with some application
    protocols (see my drafts recently posted to this list).  A library
    implementing DANE should likely support these, in which case it
    may need to provide controls (flags, ...) to treat some types of
    TLSA RRs as unusable and/or to ignore PKIX requirements by treating
    0/1 as 2/3 respectively.

These are all design issues that must be considered before code is
first released to the public.  Some early code may be written to
explore the space in aid of fleshing out the design, but code should
not be released until the design is complete.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 May 2013 19:28:31 +0000

> what order, you are ready to design an extension that implements

One more design consideration is a choice of where DNSSEC validation
takes place.  The application should be free to use any DNSSEC
validating library of its choice, and then provide validated TLSA
records to the library.

The library may provide a mechanism to find and validate TLSA
records, but this should be optional, and should try to avoid
compatibility constraints on the application (DLL hell) caused by
linking to additional third-party (not bundled with the base
platform) libraries.

The proposed OpenSSL implementation attempts to deal with this by
dynamically loading (rather than linking with) libunbound, but this
brings in its own issues since libunbound links to OpenSSL 1.0.x,
which makes it difficult to test with OpenSSL 1.1.0-dev.

By far the simplest choice is to rely on the system libresolv and
delegate DNSSEC validation to the local (ideally 127.0.0.1)
nameserver.  This is what Postfix does, and I believe OpenSSL should
do.  Applications that want to validate each time they make a DNS
request via their own trust anchor, can link to a suitable library
of their choice and pass their own TLSA RRs for DANE verification.

Thus OpenSSL should only (directly) support DNSSEC via libresolv,
and should encourage applications that use untrusted remote DNS
caches to link to whatever validating DNS library they see fit.

-- 
	Viktor.

---

From: Guido Witmond <[email-masked]>
Date: Fri, 31 May 2013 00:46:52 +0200

> a non-trivial fraction of the early implementations are substantively

I've updated the Extended DNSSEC Validator up to 0.8 in the past and got 
its maintainer Danny to incorporate my changes. Is has all the flaws 
mentioned before but I consider it a good start.
And no, not ready for production, yet.

I've got some more updates. It validates TLSA 2 0 0 correctly. Just 
check out https://dating.wtmnd.nl:10443/ with it. It has a valid 2 0 0 
certificate. It should validate.

You can find my toy at: 
https://github.com/gwitmond/Extended-DNSSEC-Validator.git

Cheers, Guido Witmond.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 31 May 2013 03:10:56 +0000

On Fri, May 31, 2013 at 12:46:52AM +0200, Guido Witmond wrote:

> I've updated the Extended DNSSEC Validator up to 0.8 in the past and
> got its maintainer Danny to incorporate my changes. Is has all the
> flaws mentioned before but I consider it a good start.

More than "not ready for production" it is deeply flawed.  It fails
to check that the certificates in the "chain" are actually linked
to each other with each issuer at depth n+1 verified as the signer
of an unexpired subject certificate at depth n.  It also does not
check basic constraints or key usage bits.  It is trivial to concoct
bogus chains that pass validation via this extension.

Testing that it validates correct chains is the easy part, it MUST
fail to validate invalid chains, and here it bombs spectularly.

Programmers inexperienced in writing security code (thinking like
an attacker and handling not only the expected but also malicious
input) should not attempt DANE implementations.

Users should steer clear of amateur DANE implementations.

--
	Viktor.

---

From: Guido Witmond <[email-masked]>
Date: Fri, 31 May 2013 11:55:58 +0200

On 31-05-13 05:10, Viktor Dukhovni wrote:
>>> Perhaps someone else can take a stab at it.  My impression is
>>> that a non-trivial fraction of the early implementations are
>>> substantively flawed.  Caveat emptor.
>>>
>>
>> I've updated the Extended DNSSEC Validator up to 0.8 in the past
>> and got its maintainer Danny to incorporate my changes. Is has all
>> the flaws mentioned before but I consider it a good start. And no,
>> not ready for production, yet.
>
> to check that the certificates in the "chain" are actually linked to
> each other with each issuer at depth n+1 verified as the signer of an
> unexpired subject certificate at depth n.  It also does not check
> basic constraints or key usage bits.  It is trivial to concoct bogus
> chains that pass validation via this extension.
>

You are completely right. Thank you for pointing those out, it helps me
on my journey to become an expert. One has to start somewhere... :-)

For me, this plug in is what got me interested in DNSSEC and DANE. I'm 
very grateful of all the hard work that the real experts have done on 
it. Without it we cannot leave the current PKI(X) mess of having other 
people to decide which Certificate Authorities I have to trust.

With DANE usage 2 0 0, we can do even more than just authenticate a web 
site to a browser. We can bootstrap secure, private, anonymous client 
certificates for the web. [1]

> Users should steer clear of amateur DANE implementations.

Flamebait: I hope that users, developers, journalists, politicians, all 
start to use this flawed plug in to see what can be done and demand a 
more safe and secure internet without global CA's violating our trust by 
selling root certificates for MitM-spydevices.

Respectfully, Guido Witmond.

[1]: http://eccentric-authentication.org/

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 31 May 2013 16:12:32 +0200

On 29. 5. 2013, at 3:29, Viktor Dukhovni <[email-masked]> wrote:
> process.

Generally it's a post-connection hook.  (Same as Cert Patrol, etc.)

DNSSEC-Validator (we are the authors) doesn't have DANE support yet, it's planned to be in 2.1.0 version of the add-on.

> I would recommend using browsers that support DANE natively,

I do agree with you, but there are none usable native-DANE-support browsers.

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